You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
calebbrown
added a commit
to ossf/malicious-packages
that referenced
this issue
Mar 6, 2025
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.
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.
The text was updated successfully, but these errors were encountered: