CVE-2026-53486

### Impact When extracting an archive to a directory, a crafted archive can read or write files outside that directory. The flaw is in the code that writes the parsed entries, so it affects every format decompress handles: tar, tar.gz, tar.bz2, and zip by default, plus any others added through the plugins option. A link (hardlink) or symlink entry is created without checking where its target points. A hardlink can be aimed at any file the running process can read; that file then appears inside the output directory and its contents are exposed. A symlink can point outside the output directory and redirect a later write. The path containment check used a string prefix comparison (`realPath.indexOf(outputPath) !== 0`). Output `/srv/out` does not contain `/srv/out-old`, but the prefix comparison treats it as inside, so an entry can escape into a sibling directory whose name starts with the output directory name. File modes were applied as `mode & ~umask`, which does not remove the setuid, setgid, or sticky bits. A crafted entry can create a setuid or setgid file. This matters when extraction runs as root, for example in CI, containers, or install scripts. Any code that extracts archives from an untrusted or attacker-influenced source is affected. Archives are commonly downloaded before extraction, so this is reachable over the network in many setups. ### Patches Fixed in `@xhmikosr/decompress` 10.2.1 and 11.1.3. Link targets are now resolved and checked against the output directory, containment uses `path.relative`, and setuid, setgid, and sticky bits are removed. The upstream `decompress` package is unmaintained, and all versions through its last release (4.2.1) have the same flaws. There is no upstream fix. Migrate to `@xhmikosr/decompress` 11.1.3 or later. ### Workarounds Extract only archives you trust. Run extraction as a non-root user so the mode issue cannot create a privileged file. After extracting, reject any symlink or hardlink that points outside t