macOS Docker Flaw Opens Door to Unauthorized Image Access
A newly revealed security oversight in Docker Desktop for macOS exposes a critical gap in container governance—allowing unrestricted image pulls that bypass established registry controls. Tracked as CVE-2025-4095, the flaw undermines enterprise-level restrictions meant to safeguard software supply chains.
At the heart of the issue is Docker’s Registry Access Management (RAM) system, a feature intended to enforce strict limits on which container registries developers can access. Typically, RAM ensures only trusted sources like Docker Hub, Amazon ECR, or internal artifact repositories are reachable by enforcing DNS-level filters.
However, macOS deployments that use configuration profiles—a common method for enforcing sign-in and policy settings across Apple ecosystems—are inadvertently disabling these protections. When macOS is configured to require user sign-in via mobileconfig or XML profiles, it delays the activation of Docker’s RAM policies.
Here’s the technical crux: Docker on macOS operates within a Hyperkit-based virtual machine, and policy enforcement occurs after the user logs in. The misalignment causes the Docker daemon to launch before RAM restrictions are applied, resulting in a time-sensitive vulnerability where image pulls go unfiltered until a system reboot resets the sequence.
The affected versions range from Docker Desktop 4.36.0 through 4.40.x, and while the official CVSS 4.0 rating sits at 4.3 (Medium), the practical implications are far more severe. Attackers exploiting this gap could introduce compromised images or unauthorized dependencies directly into a team’s build process—undermining both CI/CD pipelines and supply chain integrity.
Risk Overview
| Category | Information |
|---|---|
| Impacted Software | Docker Desktop for macOS (versions 4.36.0 up to, but not including, 4.41.0) |
| Security Implication | Enables circumvention of Registry Access Management (RAM), allowing unrestricted image pulls from any source |
| Conditions for Exploitation | macOS device running Docker Desktop with organizational sign-in enforced via Apple configuration profiles |
| Severity Rating (CVSS 3.1) | 4.3 (Medium) – may understate the real-world impact on development and supply chain security |
Security Posture Implications for Containerized Environments
Organizations leveraging Docker’s Registry Access Management (RAM) to meet compliance mandates—such as NIST SP 800-190 or the SLSA Framework—are at heightened risk due to this flaw:
- Policy Evasion Risks: Developers may still pull images from unauthorized public registries (e.g., Docker Hub), even when explicitly blocked, opening the door to supply chain threats such as typosquatted or tampered containers.
- Credential Exposure: In the event of a compromised developer system, attackers could quietly exfiltrate credentials or push malicious content to external registries—without triggering typical security alerts.
- Pipeline Infiltration: Malicious images pulled during this vulnerability window can compromise CI/CD workflows, enabling privilege escalation, data theft, or backdoored software releases.
Internal testing by Docker confirmed that when macOS systems rely on Apple configuration profiles for enforcing sign-in, RAM protections may remain inactive for up to 24 hours—an exposure window long enough to be exploited.
Docker has addressed this issue in version 4.41.0, which corrects the policy sequencing flaw by initializing RAM independently of sign-in logic.
Recommended Actions for Administrators:
- Upgrade Immediately: Deploy Docker Desktop v4.41.0 or later across all macOS endpoints.
- Audit Registry Restrictions: Run
docker info | grep -i registryto confirm registry enforcement is active and aligned with policy. - Centralize Policy Control: Move sign-in enforcement to Docker’s Admin Console, which correctly applies policies in the expected sequence.
Interim Mitigations for organizations unable to upgrade right away include:
(Consider listing these next.)
Docker’s advisory emphasized a critical design consideration:
“Registry Access Management functions at the DNS layer, leaving it susceptible to localhost proxy bypasses—an issue further exacerbated by CVE-2025-4095.”
To reduce exposure beyond this vulnerability, organizations are urged to strengthen registry controls with layered defenses, including:
- Image signing protocols such as Notary v2, to ensure image authenticity and integrity
- Behavioral runtime security tools like Falco, to detect anomalous container activity in real time
CVE-2025-4095 highlights a broader concern: the inherent fragility of supply chain defenses in modern container environments. While Docker’s patch in version 4.41.0 curtails the immediate threat, the incident serves as a reminder that defense-in-depth remains essential—blending registry policy, artifact validation, and ongoing security scanning to maintain trust across the container lifecycle.
