CVE-2026-42151

What it actually does

Prometheus versions prior to 3.5.3 and 3.11.3 incorrectly treat the Azure AD remote write OAuth client_secret configuration value as a normal string rather than a Secret type. Prometheus redacts Secret-typed values when returning runtime configuration through the /-/config HTTP API endpoint, but because this value was not classified as secret, it could be exposed in plaintext to any unauthenticated or unauthorized user, service, container, sidecar, proxy, or process that can reach that endpoint. The impact is confidentiality loss of the Azure OAuth client secret used by Prometheus remote write integrations; integrity and availability are not directly affected by the flaw itself.

Why it matters to the business

An exposed Azure OAuth client secret can allow an attacker to impersonate the configured application or service principal, potentially giving them access to monitoring data pipelines or any other Azure permissions assigned to that identity. Even though EPSS is currently low and there is no known KEV listing or reported exploit maturity, the vulnerability is simple to exploit wherever the Prometheus HTTP endpoint is reachable, and leaked cloud credentials can create downstream incident response, credential rotation, compliance, and data exposure risk.

How an attack unfolds

An attacker first identifies a reachable Prometheus web/API endpoint. If the Prometheus server exposes /-/config to the attacker and the deployment uses Azure AD OAuth for remote write, the attacker requests the configuration endpoint. In vulnerable versions, the response includes the Azure AD remote write OAuth client_secret in plaintext rather than a redacted placeholder. The attacker can then copy the client ID, tenant-related configuration, token URL, and exposed secret from the configuration and attempt to obtain Azure OAuth tokens for the associated application or service principal. Any further impact depends on the permissions granted to that Azure identity, such as access to remote write infrastructure, observability data, or other Azure resources inadvertently assigned to the same identity.

How to fix it

Upgrade Prometheus to a patched release: 3.5.3 or later for the 3.5.x line, or 3.11.3 or later for the 3.11.x line. After upgrading, rotate any Azure AD client secrets that may have been present in Prometheus remote write configuration, because exposure through /-/config should be treated as credential disclosure if the endpoint was reachable by untrusted users or services. Restrict access to the Prometheus HTTP endpoint, especially /-/config, using network controls, authentication, authorization, reverse proxy policy, and service mesh rules. Apply least privilege to the Azure application or service principal used for remote write so that credential compromise does not grant broad cloud access. If immediate upgrade is not possible, block or tightly restrict access to /-/config and rotate the Azure OAuth secret after the control is in place.

How to confirm the fix worked

Confirm the running Prometheus version is 3.5.3, 3.11.3, or a later fixed release. Query the /-/config endpoint from an authorized administrative network path and verify that Azure AD remote write client_secret values are redacted rather than displayed in plaintext. Review Prometheus startup logs, deployment manifests, package versions, container image tags, and binary versions to ensure no vulnerable instances remain. Validate that the Prometheus web/API interface is not internet-exposed and that only approved operators or services can access administrative endpoints. Confirm that any Azure AD client secret formerly stored in vulnerable configuration has been rotated and that old credentials are disabled or expired.

Typical attack path

1. Discover or enumerate an exposed Prometheus HTTP endpoint.
2. Send an HTTP request to the Prometheus configuration endpoint at /-/config.
3. Inspect the returned configuration for remote_write entries using Azure AD OAuth settings.
4. Extract the plaintext client_secret and related OAuth metadata if present.
5. Use the exposed secret to request Azure AD OAuth tokens for the configured application or service principal.
6. Access downstream services or Azure resources permitted to that identity.
7. Optionally rotate infrastructure, create persistence, or exfiltrate data depending on the Azure permissions available.

How to detect it

Investigate whether the Prometheus /-/config endpoint was accessed by untrusted clients before the upgrade or before access controls were applied. Useful log sources include reverse proxy access logs, ingress controller logs, load balancer logs, web application firewall logs, service mesh telemetry, Kubernetes audit/network logs, Prometheus server logs if HTTP request logging is enabled by surrounding infrastructure, and Azure AD sign-in/service principal logs for the affected application. Look for HTTP GET requests to /-/config, especially from unexpected IP addresses, pods, containers, user agents, scanners, or non-administrative networks. Correlate any such access with the time window when vulnerable Prometheus versions were running and Azure AD remote write configuration contained a client_secret. In Azure AD logs, look for new or unusual token issuance, failed credential attempts, sign-ins from unfamiliar geographies or autonomous systems, and resource access by the affected service principal shortly after /-/config access. Forensics should also review shell histories, downloaded files, debug bundles, ticket attachments, CI logs, and configuration snapshots for copied Prometheus configuration containing plaintext client_secret values.

• GET /-/config
• POST /-/config
• /-/config
• client_secret:
• client_secret=
• azuread
• remote_write
• oauth2
• storage/remote/azuread
• Authorization: Bearer
• login.microsoftonline.com
• /oauth2/v2.0/token
• /oauth2/token

What your security team should do

• Inventory all Prometheus instances and identify versions older than 3.5.3 or 3.11.3 that use Azure AD OAuth for remote write.
• Prioritize remediation for any Prometheus endpoint reachable from the internet, shared networks, Kubernetes clusters with broad pod-to-pod access, or environments where non-administrative users can reach /-/config.
• Upgrade Prometheus to 3.5.3, 3.11.3, or later and verify redaction behavior through the configuration API.
• Rotate the affected Azure AD client secret and revoke the previous secret value after confirming dependent services are updated.
• Review Azure AD sign-in and service principal activity for suspicious token requests or resource access using the affected application identity.
• Restrict /-/config and other administrative Prometheus endpoints with authentication, authorization, network ACLs, reverse proxy rules, or service mesh policy.
• Reduce permissions assigned to the Azure application or service principal used for remote write to the minimum required scope.
• Add monitoring for access to /-/config and for unusual Azure AD token activity tied to Prometheus remote write identities.