internallib_v647 / internallib_v811 (npm): malicious packages install unauthenticated HTTP tarball from internal IP, enabling arbitrary code execution on npm install
Severity: critical · Patch status: no-fix-needed · Since 2026-11-13
Two malicious npm packages, internallibv647@1.0.3 and internallibv811@1.0.1, were published to the npm registry and flagged by Amazon Inspector via the OpenSSF malicious-packages database on 2026-11-13. Both declare a dependency, internallib-helper, as a plain-HTTP tarball URL pointing at a bare internal IP (http://10.0.77.5:8000/...), with no version pin, no integrity hash, and no TLS. On npm install, npm fetches and installs whatever bytes that endpoint serves and runs any lifecycle scripts in the tarball, so anyone controlling or able to MITM traffic to 10.0.77.5:8000 controls code executed on the installing host. The shipped package code is a trivial stub; the manifest line itself is the install-time execution vector, and the dependency naming mirrors a dependency-confusion/internal-package lure. No patched versions exist; the packages should be removed.
What to do
- Search lockfiles and installed node_modules for internallib_v647, internallib_v811, and internallib-helper; remove and rebuild from clean sources if found
- Audit package.json manifests for dependencies declared as http:// tarball URLs, especially on private IPs, and block them in CI
- Check build and developer hosts that installed these packages for signs of lifecycle-script execution (postinstall payloads, unexpected processes, outbound connections)
- Enforce npm integrity/lockfile checks, disallow non-registry tarball sources, and require TLS for any internal package mirror
- Rotate any credentials/secrets that may have been present on affected build environments
Sources
All live incidents on Threat Watch
