"Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend," Kaspersky's container-security analysis warns — and then documents how that popularity has translated into predictable, dangerous exposures.
Kaspersky’s sampling: 100 images, 64 with critical flaws
To quantify the risk, Kaspersky scanned a random sample of 100 Docker Hub images with between 10,000 and 1 million downloads. In the 64 images it fully scanned, the company found outdated software versions containing critical vulnerabilities. Only one in ten images in the analyzed sample was fully up to date. The report stresses that a container image is a snapshot and does not receive automatic security updates the way a traditional Linux server might; to receive fixes it must be rebuilt and redeployed, a step often missed in practice.
Active exploitation and notable CVEs in use
Kaspersky documents rapid weaponization of recently disclosed flaws. The report notes that one day after the disclosure of CVE-2025-55182 in React Server Components, honeypots recorded numerous attack attempts exploiting it, used by campaigns ranging from cryptocurrency miners to Mirai and Gafgyt variants. The company also found images containing other high‑impact vulnerabilities, including CVE-2025-49844 in Redis (RCE via a Lua parser bug), CVE-2026-24061 in nginx (server crash and, with ASLR disabled, potential RCE), CVE-2025-32463 in sudo, and CVE-2023-4911 in glibc — all examples of flaws that can materially increase an attacker’s ability to compromise containers and move laterally.
Configuration problems: secrets, sudo, healthchecks, and permissions
Beyond unpatched packages, Kaspersky’s KIRA AI assistant flagged numerous insecure image configurations that carry practical exploitation risk. Examples in the analysis include hardcoded passwords in Dockerfile ENV directives and image layer histories, cleartext passwords passed into healthcheck command arguments (making them visible in process lists and logs), and use of passwordless sudo entries (NOPASSWD: ALL) for service accounts such as solr or postgres. The report also highlights commonplace file-permission mistakes — chmod 0777 on system paths — and the absence of integrity checks when downloading archives (HTTP downloads, or use of --no-check-certificate for HTTPS), which expose build-time man-in-the-middle and tampering risks.
KIRA’s remediation guidance, as quoted in the analysis, recommends avoiding passwords in Dockerfiles, using orchestrator secret mechanisms (Docker secrets, Kubernetes Secrets) or BuildKit --secret during builds, preferring Unix socket/local connections for healthchecks or dedicated minimal-privilege users, delegating only specific sudo commands rather than broad NOPASSWD rules, enforcing conservative file permissions (0755/0644), and verifying archives via SHA256 checksums or storing verified artifacts in an internal repository.
Supply-chain tradeoffs: updates versus injected risk
Kaspersky points to a structural tension: rebuilding images to apply updates reduces exposure to known vulnerabilities but increases exposure to supply‑chain compromise if dependencies or base images are tampered with. The company did not find supply‑chain compromises in its scanned sample, but it cites a March 2026 incident that affected the Trivy and LiteLLM projects, in which an infected file was injected into a container image in an official repository. This episode underlines the report’s recommendation to pin dependencies to known-good versions and to scan updated images for malware after every update.
What this means for technologists, procurement leaders, and maintainers
- Technologists and security teams: prioritize image rebuilds combined with rigorous scanning. Kaspersky recommends pinning dependencies, scanning for malware on every update, and using secret-management facilities rather than baking credentials into images.
- Procurement and enterprise IT leaders: demand supply‑chain hygiene from vendors and insist on images that are demonstrably maintained — the report’s finding that only 10% of sampled images were fully up to date is a concrete procurement risk metric.
- Open-source maintainers and registry operators: CAs and registries should emphasize integrity checks and reproducible, pinned releases; the March 2026 Trivy/LiteLLM incident is cited as a tangible example of how official repositories can be vectors for injected content.
Attackers are exploiting both the software-supply layer and simple operational mistakes. Kaspersky’s analysis — combining automated scanning with its KIRA assistant and a targeted sampling of public images — yields a clear operational prescription: do not treat container images as immutable conveniences. Rebuild and update intelligently, pin and verify dependencies, remove embedded secrets, and scan images for malware after every change. The choice between infrequent updates with known vulnerabilities and frequent updates that increase supply‑chain exposure is not binary; it demands procedural safeguards that the report lays out in concrete terms.
Read the original analysis: https://securelist.com/container-security-typical-issues/119974/
