Supply chain compromise via malicious @cap-js/openapi

published 2026-06-04 5mo ago modified 2026-09-10 2mo ago

cvss: 9.6; version 3.1, GitHub
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

### Impact

On May 19, 2026, a compromised version of @cap-js/openapi@1.4.1 was published. The malicious packages harvested credentials and attempted self-propagation. If a compromised version was installed, all credentials accessible on that machine (npm tokens, cloud provider credentials, SSH keys, GitHub PATs) should be considered compromised.

### Patches

Upgrade to @cap-js/openapi >= 1.4.2 If the compromised version was ever installed, rotate all affected credentials.

### Workarounds No workarounds.

### References

- [SAP Note 3747787](https://me.sap.com/notes/3747787) - [Developer FAQ](https://www.sap.com/documents/2026/05/8203a8b9-4d7f-0010-bca6-c68f7e60039b.html)

Patch / fix

fixed in 1

npm @cap-js/openapi 1.4.2

Is GHSA-jpvj-wpmj-h7rv in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by	version	score	vector
GitHub	3.1	9.6	CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Affected packages

ecosystem	package	affected	fixed in
npm	@cap-js/openapi	>=1.4.1, <1.4.2	1.4.2

Classification

Weakness

CWE-506 Embedded Malicious Code

References

Sources

GitHub Advisory GHSA-jpvj-wpmj-h7rv

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.