GHSA-9mgv-25w8-jwhf: Malicious code in paychex-pdftron (npm)
--- -= Per source details. Do not edit below this line.=-
Source: amazon-inspector (d32ec8b2ca67156d94943a27b9b7c98f1888d530d7a6f947e49b40f52ec054b3) paychex-pdftron@99.9.1 ships an empty stub (module.exports = {}) and declares its sole dependency ltidisafe as a bare HTTPS tarball URL (https://ltidi.storage.googleapis.com/depenconf/ltidisafe-4.0.5.tgz) rather than a registry version range. On npm install, npm fetches whatever bytes that URL returns and installs the resulting package, executing any lifecycle scripts it contains — with no version pin, no integrity hash, and no signature verification. The package name resembles an internal Paychex scope, the version is an implausibly high 99.9.1 (a dependency-confusion resolution tactic), the URL path segment is depenconf, and the host is unrelated to any legitimate Paychex or pdftron domain. The manifest alone is the attack surface: resolving this dependency pulls attacker-controlled code into the installer's build environment.
Source: ghsa-malware (f176a5672301d76d7c08b93a46b074c23cdf0d36d46324d30dc8aceaa55ed707) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Remove
Remove
npm/paychex-pdftronfrom your environment.Remove the paychex-pdftron package; removing it may not remove all malicious software resulting from its installation.
- Operational
Rotate all secrets and keys stored on any affected computer immediately, using a different computer.
Event History
Frequently Asked Questions
Which environments should be treated as exposed?
Any computer where this package is installed or running should be considered fully compromised. The installer's build environment is also exposed when npm resolves the package dependency.
Does exploitation require any configuration beyond installing the package?
No. The manifest declares a dependency as a direct HTTPS tarball URL, so npm fetches and installs it during npm install; lifecycle scripts in the retrieved package can then execute.
What makes the downloaded dependency difficult to verify?
The dependency is not pinned to a registry version and has no integrity hash or signature verification. npm installs whatever content is returned by the referenced URL.