Vulnerability Reportnewrelic/nri-kubernetes:latest

newrelic/nri-kubernetes:latest

digestsha256:dbabc07ec36ff7ad8c55cdcc9cd7f0f70e9b4b3ecb25d88b9ccc40d5b004130c

Executive Summary

Last scanned: Nov 4, 2026

Threat ScoreNEEDS ATTENTION• CVE-2026-78669 in the golang.org/x/net package (rated 6.0) is the only finding that affects the verdict. A malicious HTTP/2 peer could send a crafted SETTINGS flood and drive the agent to high CPU use, slowing or stalling metric collection.• The flaw only matters if the agent connects to a hostile or compromised peer; its exposure depends on which Kubernetes API and kubelet endpoints the agent talks to.• The scan found no known-exploited vulnerabilities and no findings rated 7.0 or higher.• The four post-exploit findings are low severity (maximum 2.7) and only matter after the container is already compromised.• The publisher is VERIFIED with a TRUSTED verdict, and the image is pinned by digest, which supports its provenance.

25/100NEEDS ATTENTION

ReputationVERIFIED• Verified Publisher (Trusted Vendor)• Pinned by digest (Immutable)

TRUSTED

This image is acceptable for production, but remediating the identified vulnerabilities is recommended to reduce the attack surface. The main item is CVE-2026-78669 in the golang.org/x/net library, which a malicious HTTP/2 peer could use to slow metric collection through excessive CPU use, but it does not give access to data or code execution. The finding requires the agent to talk to a hostile or compromised endpoint and needs no special configuration to be relevant. The other findings are low severity and matter only after a compromise, so they do not change the verdict. Updating the golang.org/x/net dependency in a future image rebuild is the practical fix.

Hardening plan for this image · 3 steps

Included in Pro

Scanning procedure

Vulnerability scan
Full CVE sweep across OS packages and app dependencies
Exploitability check
CVEs ranked by exploit probability (EPSS) and matched against CISA KEV
Reachability analysis
Symbol-level proof: is the vulnerable code even linked and callable in your binaries?
Runtime verification
Live-container probes: exposed endpoints, feature flags, real defaults
Supply chain analysis
Base-image lineage, package provenance and signatures — nothing slipped in unnoticed
Hardening recommendations
A hardened build plan — patch, remove unused packages, lock down the runtime — with parity tests proving nothing broke

Vulnerabilities

Vulnerability Log

5 total

CVE ID	Adjusted Severity	Package	Exploit Probability	Risk Context
CVE-2026-78669	MEDIUM6	golang.org/x/net v0.59.0 fixed in 0.60.0	0.6% Theoretical Threat	Directly ExposedContext importance: MEDIUM
CVE-2026-78659	LOW2.7	golang.org/x/net v0.59.0 fixed in 0.60.0	0.6% Theoretical Threat	Post-Exploit
CVE-2026-78660	LOW2.7	golang.org/x/net v0.59.0 fixed in 0.60.0	0.4% Theoretical Threat	Post-Exploit
CVE-2026-97032	LOW2.12	golang.org/x/net v0.59.0 fixed in 0.60.0	0.5% Theoretical Threat	Post-Exploit
CVE-2026-78663	LOW1.91	golang.org/x/net v0.59.0 fixed in 0.60.0	0.6% Theoretical Threat	Post-Exploit

Want to check another image? Run a full scan with the Docker Security Scanner.