CVE-2026-12566: Docker Registry Credential Leak via Unsafe realm Parameter in bbot

Technical summary

The docker_pull module fails to validate the realm parameter extracted from a Docker registry's WWW-Authenticate HTTP response header before using it as an authentication endpoint URL. This implements a form of Server-Side Request Forgery (CWE-918) where attacker-controlled input from a registry response is used to determine where authentication credentials are sent. An attacker in a network-layer MITM position can modify the WWW-Authenticate header to specify an attacker-controlled realm URL, causing bbot to leak authentication tokens to that endpoint.

Business impact

Successful exploitation could expose Docker registry credentials used by bbot instances, potentially granting attackers unauthorized access to private container images and registries. In environments where bbot is used for reconnaissance or container scanning, compromise of registry credentials could allow attackers to inject malicious images, modify scanning workflows, or pivot into downstream systems that consume those container images. The practical impact depends on the sensitivity of registries accessed and the scope of bbot's deployment.

Affected systems

bbot instances using the docker_pull module to authenticate against Docker registries are affected. The vulnerability requires user interaction (triggering a docker_pull operation) and a network-layer MITM attack capability, limiting the attack surface to environments where bbot communicates with registries over unencrypted or poorly validated TLS connections. No specific version information is provided in source data; verify the affected version range and patch availability against the vendor advisory.

Exploitability

Exploitation requires an attacker to occupy a man-in-the-middle network position between a bbot instance and a Docker registry, and additionally requires user interaction to trigger the docker_pull operation. These constraints—combined with the need for the victim to use an unprotected or poorly validated registry connection—place this in the LOW severity category. However, in targeted scenarios or penetration testing exercises, an attacker with network access (e.g., on a shared network segment or compromised proxy) could reliably execute this attack.

Remediation

Implement validation of the realm parameter before using it as an authentication endpoint. The realm value should be parsed and validated to ensure it matches the expected registry hostname or is on an approved list. Additionally, ensure all Docker registry communication uses proper TLS validation and certificate pinning where feasible. Review bbot's Docker authentication flow to confirm realm parameters cannot be exploited for SSRF attacks.

Patch guidance

Consult the official bbot security advisory and release notes for the specific patched version that addresses realm parameter validation in the docker_pull module. Apply patches in a test environment first to confirm no regression in docker_pull functionality. Verify that the patch does not break legitimate multi-realm authentication scenarios if your environment uses complex Docker registry setups.

Detection guidance

Monitor bbot logs and network traffic for unexpected authentication attempts to non-standard or unusual hostnames when docker_pull operations are performed. Alert on deviations in the hostname target of Docker authentication requests, particularly if they differ from configured registry endpoints. Network-layer detection is challenging without TLS interception, but HSTS and certificate transparency logs may reveal suspicious realm redirects. Consider requiring explicit TLS validation enforcement and logging of all realm values encountered during registry authentication.

Why prioritize this

Although marked LOW severity, organizations running bbot in threat-intel or container-scanning pipelines should prioritize this patch because compromised Docker registry credentials can have outsized downstream impact. The barrier to exploitation (MITM + user interaction) is non-trivial but achievable in specific network architectures. Prioritize if bbot accesses private or sensitive registries or if your network lacks robust TLS validation controls.

Risk score, explained

CVSS 3.1 score of 3.1 (LOW) reflects the attack vector (network), high complexity (MITM required), lack of privileges needed, requirement for user interaction, unchanged scope, and only low confidentiality impact (token leakage). The score appropriately accounts for the need to position an attacker between bbot and the registry. However, contextual risk depends on the sensitivity of credentials in use and registry access scope.

Frequently asked questions