.
Overview
In rare cases, the official npm Registry (https://registry.npmjs.org) may delete package tarballs that violate their policies ( ie. compromised packages ). If package maintainers do not publish a newer package version afterward, some npm clients (e.g., Nexus Repository) may not recognize that the package metadata needs updating to not reference these deleted tarballs.
Nexus Repository proxy repositories rely on standard ETags or Last-Modified headers to determine when metadata has changed at a remote. If these headers are not updated by the registry maintainers when tarballs are deleted, simply using the Invalidate Cache or relying on Metadata Max Age expiration will not resolve the issue.
To force Nexus Repository to fetch the latest metadata, you must delete the stale package metadata asset, which triggers a fresh retrieval from the remote registry.
How to Delete npm Package Metadata Asset
- Log in to the Nexus Repository UI as an admin user.
- In the Browse UI, select the relevant npm proxy repository that contains the affected asset.
- Navigate to the stale vulnerable npm component (metadata asset).
- Example: If the package name is error-ex, select the error-ex node.
- Click Delete Asset (⚠️ Do not use Delete Folder).
NOTE: If the icon is the document icon like the below, please still click [ Delete asset ]:
If the icon is the directory icon like the below, please do NOT click [ Delete folder ]: - Invalidate the npm client cache and reinstall dependencies:
npm cache clean --force npm install
Supply Chain Attack Impacts
In September 2025, multiple npm components were identified as malicious in a large-scale supply chain attack. The npm Registry maintainers removed the compromised versions. More details:
👉 Sonatype Blog: npm chalk and debug packages hit in supply chain attack
If you were not protected by Nexus Repository Firewall, Nexus Repository instances may have cached these vulnerable versions.
Deleting the vulnerable package versions from your proxy repository can prevent any downloading of the tgz files internally, but invalidating the cache does not refresh package metadata for proxy or group repositories.
Running commands like "npm view <component_name> version" may cause it to seem like the list of available versions includes vulnerable versions and they are still available to download. This is not true if the tgz has been deleted from the proxy repositories and the remote has also deleted the tgz.
Resolution paths
If no newer version of the npm package was published → follow the steps above to delete the stale metadata asset.
If a newer non-vulnerable version exists → Nexus Repository will automatically update metadata once the configured metadata max age expires or the Invalidate Cache button is clicked.
Detailed Problem Diagnosis
Nexus Repository stores the Last-Modified and ETag headers from the npm registry for conditional requests.
Example: For the error-ex package, the registry returned:
last_modified: 2025-09-10T02:00:04.357Z
etag: W/"c9e6bd1ca7e5caf64f69f543578fcba4"
Sample database verification:
support_zip_db=# select attributes from npm_asset where npm_asset.repository_id = '24' and path = '/error-ex';
{
"npm": { "asset_kind": "PACKAGE_ROOT", "last_modified": 1702934263627 },
"cache": { "cache_token": "15539402181144330", "last_verified": "2025-09-10T02:00:04.357Z" },
"content": { "etag": "W/\"c9e6bd1ca7e5caf64f69f543578fcba4\"", "last_modified": "2025-09-08T15:02:36.000Z" },
"checksum": { "sha1": "73bb9c3bfa8ffdcc380916a8d3f12742789a556f" },
"provenance": { "hashes_not_verified": false }
}Registry metadata sample (jq output):
"name": "error-ex"
"dist-tags": { "latest": "1.3.3" }
"time": {
"created": "2015-08-25T21:16:59.317Z",
"modified": "2025-09-08T15:30:21.954Z",
...
"1.3.3": "2025-09-08T13:16:05.782Z" <-- vulnerable version published
}Despite updated metadata, the Last-Modified and ETag values did not change:
curl -sv -o /dev/null https://registry.npmjs.org/error-ex ... < etag: "c9e6bd1ca7e5caf64f69f543578fcba4" < last-modified: Mon, 08 Sep 2025 15:02:36 GMT
Because Nexus relies on conditional requests, it continues serving cached metadata until forced refresh is performed.