2,000+ CVEs Found in Official OpenClaw Docker Image

A security review of the official OpenClaw Docker image found more than 2,000 known vulnerabilities, including several marked critical and some with no available fix. The findings, reported by Kilo and discussed in devsecops and sysadmin communities, add a new layer of risk for anyone running OpenClaw in a containerized setup.

Docker images package an application and its dependencies into a portable container. That makes deployment easier, but it also means any outdated libraries, base operating system packages, or bundled tools inside the image can become part of the attack surface.

In this case, the concern is not just the number of CVEs, short for Common Vulnerabilities and Exposures, which is the public catalog used to track known security flaws. The image also contains Telegram tokens and Slack credentials, according to the summary, which means a compromise could expose messaging integrations as well as the application itself.

That combination matters because container images are often treated as disposable or low-risk once they are built. In practice, they can still carry sensitive configuration, secrets, and inherited vulnerabilities from the layers they are based on, especially if the image is not tightly maintained.

The issue came to light as part of a review of the official image used to deploy OpenClaw, a tool that many operators use for automation and AI-related workflows. A large CVE count does not automatically mean every flaw is reachable, but security teams generally treat it as a warning sign, especially when critical issues are present and remediation is not available for some of them.

The mention of critical vulnerabilities with no fix is particularly problematic. In vulnerability management, a fix may be unavailable because the flaw exists in upstream software that has not been patched, the affected package is no longer maintained, or the container is pinned to an older dependency stack that cannot be updated cleanly.

Containers can also obscure what is actually running inside the environment. Teams may assume the application layer is the only thing they need to review, while the image may include operating system packages, shell utilities, package managers, and other components that expand exposure far beyond the main app.

Secrets inside the image raise a different class of concern. Telegram tokens and Slack credentials are authentication material, so if they are embedded in a Docker image, anyone with access to the image or a copied layer could potentially use them to interact with those services as the application.

That is especially sensitive for automation platforms, which often connect to chat tools, webhooks, and internal systems. Those integrations are useful because they let software send alerts, receive commands, and move data between services, but they also create additional entry points that need careful handling.

Security teams have long warned that container security is not just about isolation at runtime. It also depends on how the image is built, which packages are included, whether secrets are baked into layers, and how often the base image is rebuilt against newly published CVEs.

For OpenClaw users, the report puts the official Docker path under scrutiny at a time when container-based deployment remains the default for many self-hosted tools. The fact pattern is straightforward: a widely used image, thousands of known vulnerabilities, critical flaws without fixes, and embedded credentials inside the container itself.