Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove GHSA-9cf5-3q4m-6qh3 as we believe it was created in error #5342

Open
jamesp-mendeley opened this issue Mar 5, 2025 · 0 comments
Open

Comments

@jamesp-mendeley
Copy link

At the Mendeley organisation internally we use an @mendeley-internal namespace for NPM packages which should not be released to the public (internal tooling, packages which use internal-only APIs, etc).

A couple of years ago we employed a pen-testing organisation called SynAck to pen-test our systems, and they identified that we had neglected to register @mendeley-internal as a public NPM namespace, which was a potential security vulnerability. To test if it was exploitable they registered the namespace and uploaded a test package called @mendeley-internal/api which did nothing but dial home to their server to confirm the existence of an exploitable vulnerability, to see if any of our systems would pick it up.

  • One of our build systems was misconfigured and did pick up the external package (since patched), and NPM reacted commendably quickly itself, blocking access to the package and organisation. In the intervening time we have since acquired ownership of the public @mendeley-internal namespace (along with any other public namespaces corresponding to internal ones) and unpublished the relevant package, but now every time we run an npm audit for a tool which uses the (legitimate) @mendeley-internal/api package (even when the tool only ever retrieves the package from our internal artifactory and does not touch the public NPM repo), we get a spurious warning (GHSA-9cf5-3q4m-6qh3) that the package includes malware.

As this was never a genuinely compromised package (as the pen-testing team were working under our direction), never had a destructive payload and has since been prevented from being exploited by our acquired ownership of all relevant NPM @-organisations, is it possible to have this advisory expunged from the database, or must every tool which uses our internal API package falsely report a non-existent vulnerability for the rest of time?

Many thanks for your consideration,

James Palmer

Engineering Manager,
Mendeley Ltd.

calebbrown added a commit to ossf/malicious-packages that referenced this issue Mar 6, 2025
GHSA withdrew the advisory GHSA-9cf5-3q4m-6qh3 due to
github/advisory-database#5342

However, since the package was malicious and published publicly the report is not removed from this repository.

Signed-off-by: Caleb Brown <[email protected]>
calebbrown added a commit to ossf/malicious-packages that referenced this issue Mar 6, 2025
GHSA withdrew the advisory GHSA-9cf5-3q4m-6qh3 due to
github/advisory-database#5342

However, since the package was malicious and published publicly the report is not removed from this repository.

Signed-off-by: Caleb Brown <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant