Two advisories published this month describe failures in ordinary libraries. One is a JWT verification bug that turns a public key into a shared secret. The other is a path traversal that walks out of a target directory through a symlink chain. At the code level they share nothing; operationally they are the same problem, because both are fixed by a dependency bump and neither is fixed by upgrading the runtime.

fast-jwt: when a public key becomes a shared secret

CVE-2026-107722, CVSS 9.8, affects npm package fast-jwt versions 6.2.0 through 6.3.0.

The mechanism deserves attention because the fix is a version number while the failure is a parsing assumption. Handed an RSA public key, the library checks whether the material looks like a PEM block. If anything non-whitespace appears before the PEM header, the check does not recognise the input as a public key and treats the value as a symmetric HMAC secret instead. Comments, control characters, zero-width characters and wrapper text all count as that preceding noise.

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

The fixed release is 6.3.0 or later. One Chinese-language brief describes the patch as incomplete, which should be resolved against the vendor advisory before you record the finding as closed. Until then, upgrade and then test the key-injection path yourself rather than trusting a version string.

decompress: the symlink chain that ends outside the folder

CVE-2026-101894, CVSS 9.1, is a path traversal in the decompress package family. An archive containing a symlink, followed by a file write through that symlink, lets an attacker place content outside the destination directory. In the common pattern where an archive is unpacked and something inside it is later executed or required, that is enough for remote code execution.

The ecosystem split matters more than the bug. The unmaintained decompress package is unfixed at version 4.2.1. The maintained fork @xhmikosr/decompress is fixed in 10.2.2 and 11.1.4. If your dependency tree resolves to the original package, a scanner will show the finding together with a fix version that does not apply to the package you actually have.

Why the runtime upgrade does not help

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

Both failures also illustrate the two ways a dependency audit goes wrong.

  • The fast-jwt case is a version-range problem. The affected window, 6.2.0 to 6.3.0, is exactly the kind of narrow range that gets skimmed. A scanner that reports the package as present without evaluating the resolved version will either miss it or flag every install.

  • The decompress case is an identity problem. The same advisory language covers two packages with different fates, and only one will ever receive a patch. Automated remediation keyed on package name alone will keep proposing a fix that does not exist.

What to do that has a chance of working

  1. 1.

    Resolve rather than guess. Print the actual resolved versions from the lockfile for both packages and their forks, including nested copies. npm ls fast-jwt and npm ls decompress give a tree, not a yes-or-no answer.

  2. 2.

    Treat the JWT library as security-critical and pin it explicitly. Being several minor versions behind on a signature verification library is a different order of risk from being behind on a formatting helper.

  3. 3.

    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 rather than a version bump, which makes it a code change with review attached.

  4. 4.

    Test the bypass directly. For fast-jwt, build a key string with a leading comment line, sign a token with that string as the HMAC secret, and confirm the patched version rejects it. Negative tests are the only evidence that a parser fix landed.

  5. 5.

    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.

The general shape

Neither bug is unusual. What earns them a joint write-up is that they are the two archetypes 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 runtime patch from the same week does nothing for either.

References

  • fast-jwt advisory: https://github.com/advisories/GHSA-73g8-9x4v-2m6c

  • decompress advisory: https://github.com/advisories/GHSA-8g7v-9x2c-4h3p

  • Node.js, October 2026 security releases: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases