Docker Registry Vulnerability Lets MacOS Users Pull Images from Any Registry
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
A newly disclosed vulnerability in Docker Desktop’s Registry Access Management (RAM) feature has left macOS users vulnerable to unauthorized image pulls, undermining critical container security controls.
Designated CVE-2025-4095, the flaw allows developers to bypass registry restrictions enforced by administrators, potentially exposing organizations to malicious container images or unapproved software dependencies.
Registry Access Management Vulnerability on macOS Docker
Docker’s Registry Access Management (RAM) is designed to limit container image pulls to pre-approved registries, such as Docker Hub, Amazon ECR, or private artifact repositories.
However, when organizations enforce sign-in policies on macOS via configuration profiles (a common enterprise deployment method), RAM policies fail to activate.
The vulnerability stems from a misconfiguration in Docker Desktop’s policy enforcement engine. On macOS, Docker runs within a Hyperkit virtual machine, with RAM policies applied at the daemon level after user authentication.
Configuration profiles- XML or mobileconfig files used to automate settings- improperly prioritize sign-in enforcement over RAM initialization.
This creates a race condition where the Docker daemon starts before RAM policies load, leaving registries unrestricted until the next reboot.
Affected versions include Docker Desktop 4.36.0 through 4.40.x on macOS. The CVSS v4.0 score of 4.3 (Medium) understates operational risks, as attackers could exploit this gap to inject malicious images into development pipelines.
Risk Factors Details Affected ProductsDocker Desktop on MacOS (versions 4.36.0 before 4.41.0)ImpactBypass Registry Access Management (RAM) policies and pull images from any registryExploit PrerequisitesMacOS system with Docker Desktop installed; organization sign-in enforced via configuration profile.CVSS 3.1 Score4.3 (Medium)
Impact on Container Security Posture
Organizations relying on RAM to comply with NIST SP 800-190 or SLSA Framework requirements face immediate exposure:
Docker’s internal testing confirmed that RAM policies remain inactive for up to 24 hours after initial sign-in when configuration profiles are used, a window ample for exploitation.
Docker released fixes in Desktop 4.41.0, which decouples RAM initialization from sign-in workflows. Administrators should:
For organizations unable to patch immediately, workarounds include:
Docker’s security advisory noted that “Registry Access Management operates at the DNS level, making it vulnerable to localhost proxy bypasses-a risk compounded by CVE-2025-4095”.
Organizations should layer RAM with image signing (e.g., Notary v2) and runtime security tools like Falco to mitigate residual risks.
CVE-2025-4095 exemplifies the fragility of supply chain controls in container ecosystems. While Docker’s prompt patch limits immediate exposure, the incident underscores the need for defense-in-depth strategies, combining registry controls, artifact signing, and continuous vulnerability scanning.
#Cyber_Security #Cyber_Security_News #macOS #Vulnerability
Оригинальная версия на сайте:
Docker Registry Vulnerability Lets MacOS Users Pull Images from Any Registry
Author: Guru BaranA newly disclosed vulnerability in Docker Desktop’s Registry Access Management (RAM) feature has left macOS users vulnerable to unauthorized image pulls, undermining critical container security controls.
Designated CVE-2025-4095, the flaw allows developers to bypass registry restrictions enforced by administrators, potentially exposing organizations to malicious container images or unapproved software dependencies.
Registry Access Management Vulnerability on macOS Docker
Docker’s Registry Access Management (RAM) is designed to limit container image pulls to pre-approved registries, such as Docker Hub, Amazon ECR, or private artifact repositories.
However, when organizations enforce sign-in policies on macOS via configuration profiles (a common enterprise deployment method), RAM policies fail to activate.
The vulnerability stems from a misconfiguration in Docker Desktop’s policy enforcement engine. On macOS, Docker runs within a Hyperkit virtual machine, with RAM policies applied at the daemon level after user authentication.
Configuration profiles- XML or mobileconfig files used to automate settings- improperly prioritize sign-in enforcement over RAM initialization.
This creates a race condition where the Docker daemon starts before RAM policies load, leaving registries unrestricted until the next reboot.
Affected versions include Docker Desktop 4.36.0 through 4.40.x on macOS. The CVSS v4.0 score of 4.3 (Medium) understates operational risks, as attackers could exploit this gap to inject malicious images into development pipelines.
Risk Factors Details Affected ProductsDocker Desktop on MacOS (versions 4.36.0 before 4.41.0)ImpactBypass Registry Access Management (RAM) policies and pull images from any registryExploit PrerequisitesMacOS system with Docker Desktop installed; organization sign-in enforced via configuration profile.CVSS 3.1 Score4.3 (Medium)
Impact on Container Security Posture
Organizations relying on RAM to comply with NIST SP 800-190 or SLSA Framework requirements face immediate exposure:
- Unrestricted Image Pulls: Developers can access public registries like Docker Hub even if blocked by policy, reintroducing risks from typosquatted or compromised packages.
- Credential Leakage: If attackers compromise a developer’s machine, they could push stolen credentials to unauthorized registries without triggering alerts.
- CI/CD Compromise: Malicious images could infiltrate build systems, leading to privilege escalation or data exfiltration.
Docker’s internal testing confirmed that RAM policies remain inactive for up to 24 hours after initial sign-in when configuration profiles are used, a window ample for exploitation.
Docker released fixes in Desktop 4.41.0, which decouples RAM initialization from sign-in workflows. Administrators should:
- Immediately upgrade all macOS Docker Desktop instances to v4.41.0 or later.
- Verify RAM enforcement using docker info | grep -i registry to confirm allowed registries.
- Transition to Admin Console enforcement: Instead of configuration profiles, enforce sign-in via Docker’s centralized console, which properly sequences policy loads.
For organizations unable to patch immediately, workarounds include:
Docker’s security advisory noted that “Registry Access Management operates at the DNS level, making it vulnerable to localhost proxy bypasses-a risk compounded by CVE-2025-4095”.
Organizations should layer RAM with image signing (e.g., Notary v2) and runtime security tools like Falco to mitigate residual risks.
CVE-2025-4095 exemplifies the fragility of supply chain controls in container ecosystems. While Docker’s prompt patch limits immediate exposure, the incident underscores the need for defense-in-depth strategies, combining registry controls, artifact signing, and continuous vulnerability scanning.
#Cyber_Security #Cyber_Security_News #macOS #Vulnerability
Оригинальная версия на сайте:
