Two npm advisories: fast-jwt HMAC confusion and decompress symlink traversal need dependency bumps

Two advisories, one operational lesson

Two npm security advisories published this month target ordinary libraries rather than exotic components. According to a dev.to write-up, the first is a severe flaw in the fast-jwt signature-verification library that can make it accept an RSA public key as though it were a symmetric HMAC secret. The second is a path traversal in the decompress archive-extraction family that lets an archive place files outside its destination directory. The two share nothing at the code level, but operationally they are the same problem: each is resolved by changing a dependency, and neither is touched by upgrading Node.js itself.

fast-jwt treats a public key as an HMAC secret

CVE-2026-107722, scored CVSS 9.8, affects fast-jwt versions 6.2.0 through 6.3.0 as listed in the write-up. The failure sits in how the library recognises key material. When it receives an RSA public key, it checks whether the input resembles a PEM block. If any non-whitespace content appears ahead of the PEM header — comments, control characters, zero-width characters or wrapper text all qualify — the check fails and the library treats the entire value as a shared HMAC secret.

That gives an attacker who can influence key material a path in: a key endpoint, a configuration file, or a JWKS response they are able to shape. They present the RSA public key as if it were an HMAC secret, sign a token using that same string as the HMAC key, and verification succeeds. The signature check still executes; it simply runs against the wrong algorithm family.

The write-up describes 6.3.0 or later as the fixed release, which sits awkwardly beside its own affected range ending at 6.3.0, and it also notes that a third-party Chinese-language brief calls the patch incomplete. Teams should confirm the exact fixed version against the vendor advisory and test the key-injection path themselves before closing a finding.

decompress escapes the target directory through a symlink chain

CVE-2026-101894, scored CVSS 9.1, is a path traversal in the decompress package family. An archive containing a symlink, followed by a file write that travels through that symlink, allows content to land outside the destination directory. Where unpacked content is later executed or required, the write-up notes, that is enough for remote code execution.

The more consequential detail is the ecosystem split. The original decompress package is unmaintained and remains unfixed at version 4.2.1. The maintained fork @xmhikosr/decompress is fixed in 10.2.2 and 11.1.4. A dependency tree that resolves to the original package will surface a scanner finding alongside a fix version that does not apply to the package actually installed.

Why a Node.js upgrade changes nothing here

Node.js 22.23.4, 24.22.1 and 26.12.1 shipped on 21 October 2026 with their own batch of security fixes. Applying one swaps the engine. It does not rewrite the contents of node_modules, and it does not change what a transitive dependency resolved to when the lockfile was last generated.

The two flaws also model the two classic ways a dependency audit goes wrong, the write-up argues. fast-jwt is a version-range problem: the affected window of 6.2.0 to 6.3.0 is exactly the kind of narrow range that gets skimmed, so a scanner that does not evaluate the resolved version will either miss the flaw or flag every install. decompress is an identity problem: a single advisory covers two packages with different fates, and automated remediation keyed on package name alone will keep proposing a fix that does not exist.

Practical steps from the write-up

• Resolve rather than guess. Print the actual resolved versions from the lockfile, including nested copies, with npm ls fast-jwt and npm ls decompress; the output is a tree, not a yes-or-no answer.
• Treat the JWT library as security-critical and pin it explicitly. Falling behind on a signature-verification library is a different order of risk from falling behind on a formatting helper.
• For decompress, establish which of the two packages you actually depend on before accepting any remediation ticket. If it is the unmaintained original, the fix is a dependency swap — a code change with review attached — not a version bump.
• Test the bypass directly. Construct a key string prefixed with a comment line, sign a token using it as the HMAC secret, and confirm the patched version rejects it. Negative tests are the only real evidence that a parser fix landed.
• Re-verify both after every runtime upgrade, because the runtime upgrade will not move them and it is easy to believe the whole stack moved.

Why it matters

Neither bug is unusual; what makes the pairing instructive is that together they cover the two recurring shapes of dependency risk that organisations handle badly — a narrow affected range that scanners under-report, and a package-identity fork that scanners over-report. The Node.js security releases from the same week do nothing for either. The practical consequence for engineering teams is that runtime patching and dependency patching are separate workstreams: the first swaps an engine, the second requires reading lockfile resolutions, distinguishing maintained forks from abandoned originals, and verifying parser fixes with tests that prove the vulnerability is gone rather than trusting a version string.