CVE-2025-27403: Ratify Auth Bypass Vulnerability

CVE-2025-27403 Overview

CVE-2025-27403 affects Ratify, a verification engine used as a binary executable and on Kubernetes to verify artifact security metadata. The vulnerability impacts deployments configured to authenticate to a private Azure Container Registry (ACR) using Azure workload identity or Azure managed identity authentication providers. Ratify versions prior to 1.2.3 and 1.3.2 failed to verify that the target registry was an ACR before exchanging an Entra ID (EID) token for an ACR refresh token. An attacker controlling a malicious registry referenced by a user workload can capture the presented EID token and abuse its ACR access. The flaw is categorized as an improper authentication weakness [CWE-287].

Critical Impact
Entra ID tokens with ACR access can be extracted by an attacker-controlled registry and reused to access private Azure Container Registry resources.

Affected Products

Ratify versions prior to 1.2.3
Ratify versions prior to 1.3.2 (1.3.x branch)
Kubernetes deployments using Ratify with Azure workload identity or managed identity providers

Discovery Timeline

2025-03-11 - CVE-2025-27403 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-27403

Vulnerability Analysis

Ratify integrates with Azure Container Registry by using Azure workload identity or Azure managed identity to obtain an Entra ID token. That EID token is then exchanged for an ACR refresh token, which Ratify uses to pull artifacts and signatures. The exchange endpoint is normally an ACR endpoint derived from the image reference of the workload being verified.

The affected versions did not validate the destination registry domain before sending the EID token. When a Kubernetes workload referenced an image hosted on a non-ACR registry, Ratify still attempted the same token-exchange flow against that arbitrary registry. The attacker-controlled endpoint receives a valid EID token scoped for ACR access. The token can then be replayed against the legitimate ACR to read or manipulate container images.

Root Cause

The root cause is missing target validation in the Azure authentication providers. The code path that performs the EID-to-ACR token exchange trusted the registry hostname extracted from the image reference without confirming it belonged to a known ACR domain.

Attack Vector

An attacker submits or convinces a user to deploy a workload that references an image hosted on a registry domain under attacker control. When Ratify processes the admission request, its Azure authentication provider sends an EID token to the attacker-controlled endpoint. The attacker captures the token and uses it to authenticate to the victim's ACR. Exploitation requires the ability to influence image references in admitted workloads, which maps to the network attack vector with user interaction.

No verified proof-of-concept code is publicly available. Refer to the GitHub Security Advisory GHSA-44f7-5fj5-h4px for vendor technical details.

Detection Methods for CVE-2025-27403

Indicators of Compromise

Outbound HTTPS requests from Ratify pods to registry domains that do not match *.azurecr.io or other configured ACR endpoints.
Kubernetes admission requests referencing container images hosted on unfamiliar or newly registered registry domains.
Entra ID sign-in logs showing ACR token exchange activity originating from unexpected client identities or unusual destinations.

Detection Strategies

Inspect Ratify logs for token-exchange attempts targeting non-ACR hostnames.
Correlate Kubernetes audit logs with image pull destinations to identify workloads referencing untrusted registries.
Monitor Azure activity logs for ACR refresh token usage that does not align with normal Ratify verification patterns.

Monitoring Recommendations

Enable Azure Entra ID audit logging for the workload identity or managed identity used by Ratify.
Apply egress network policies on the Ratify namespace and alert on connections to unapproved registry domains.
Track Ratify version inventory across clusters and alert on instances running below 1.2.3 or 1.3.2.

How to Mitigate CVE-2025-27403

Immediate Actions Required

Upgrade Ratify to version 1.2.3 or 1.3.2 or later across all Kubernetes clusters.
Rotate any Entra ID credentials and ACR access associated with the workload identity or managed identity used by Ratify.
Audit recent workload deployments for image references pointing to unexpected registries.

Patch Information

The fix is delivered in Ratify 1.2.3 and 1.3.2. Both Azure authentication providers now validate the registry domain against a pre-configured list of well-known ACR endpoints, with wildcard support, before performing the EID token exchange. See GitHub Commit 0ec0c08 and GitHub Commit 84c7c48 for the upstream changes.

Workarounds

Restrict admission of workloads to images sourced only from approved ACR registries using a Kubernetes admission policy.
Apply namespace-level egress filtering so Ratify can only reach known ACR domains during token exchange.
If patching is not immediately feasible, disable the Azure workload identity and managed identity providers in Ratify configuration until upgrade.

bash

# Upgrade Ratify via Helm to a patched release
helm repo update
helm upgrade ratify ratify/ratify \
  --namespace gatekeeper-system \
  --version 1.3.2

# Verify the running version
kubectl get pods -n gatekeeper-system -l app=ratify \
  -o jsonpath='{.items[*].spec.containers[*].image}'