Introduction
Organizations running the vulnerable Cockroach Labs cockroach-k8s-request-cert image are exposed to remote attackers, who can get root access to this Kubernetes certificate management container without any authentication. The flaw bypasses every authentication barrier, so any infrastructure that uses this container for CockroachDB deployments is at severe risk.
About Cockroach Labs: Cockroach Labs makes distributed SQL database technology and is best known for CockroachDB. Its products are widely used in cloud-native and Kubernetes environments, where they run mission-critical workloads for organizations from startups to large enterprises. The company is known for its focus on resilience and scalability.
Technical Information
The vulnerability (CVE-2025-9276) comes from the configuration of the /etc/shadow file in the cockroach-k8s-request-cert container image. The root user's entry in that file has an empty password field, so any authentication attempt as root succeeds, whatever password is supplied (or none at all).
The /etc/shadow file controls password authentication for system users, and a blank password for root disables password checks entirely. Attackers can therefore authenticate as root through any interface that relies on system authentication, such as SSH, the local console, or services that use PAM. The vulnerability is classified under CWE-258 (Empty Password in Configuration File).
No code snippet is available in public sources for this vulnerability.
Proof of Concept
The system shadow file in the Cockroach Labs cockroach-k8s-request-cert container image gives the root user a blank password. Because of this, remote attackers can bypass authentication and get unauthorized access to the system.
To exploit it, an attacker tries to log in as root without providing a password. The password field is empty, so the system lets them in, and authentication offers no protection at all.
The issue shows why default configurations need to be secure, especially where authentication credentials are concerned. Administrators should make sure every user account, and above all privileged accounts like root, has a strong, non-empty password.
Reference: ZDI-25-855
Detection Methods
These strategies can help detect unauthorized access through the empty root password in the Cockroach Labs cockroach-k8s-request-cert container image:
- Review system authentication logs regularly for root logins that happened without password authentication. Unusual or unexpected root access entries can indicate exploitation.
- Deploy file integrity monitoring (FIM) tools on critical system files, including
/etc/shadow. Configure alerts for any unauthorized modification, such as a blank password field for the root user. - Configure your security information and event management (SIEM) system to detect patterns associated with unauthorized root access, with alerts for:
- Multiple root login attempts without password prompts.
- Root access to sensitive files or directories without prior authorization.
- Scan container images and deployed systems routinely for configurations with empty root passwords. Automated scanning tools can help find and fix these quickly.
- Examine the configuration of deployed containers to make sure default credentials are not in use. In particular, verify that the
cockroach-k8s-request-certcontainer does not have an empty root password. - Restrict access to the
cockroach-k8s-request-certcontainer and associated systems, so that only authorized personnel can modify configurations or reach sensitive components.
Reference: ZDI-25-855
Affected Systems and Versions
- Product: Cockroach Labs cockroach-k8s-request-cert container image
- All versions of the cockroach-k8s-request-cert container image are affected
- Cockroach Labs no longer supports the image
- Any deployment that uses this image for certificate management in Kubernetes is vulnerable
Vendor Security History
Cockroach Labs has a documented vulnerability management process and has fixed earlier security issues in its core CockroachDB products. In this case, though, the vendor did not respond to the initial disclosure attempts. It instead stated that the affected container image is no longer supported, which leaves remediation to users.
