CVE-2026-84713 in Ansible Automation Platforminfo

Summary

by MITRE • 09/23/2026

A flaw was found in the automation-controller notification subsystem. Although NotificationTemplate.notification_ configuration is protected from API filtering, its recipient value is copied in clear text into the unprotected Notification.recipients field on every send. Because the credential-types endpoint is listable by any authenticated user and the API filter backend traverses object relations without per-hop authorization, a user with no privileges can use a relational filter as a boolean count-oracle to recover, character by character and across organizations, the secret recipient values of other tenants' notifications — including PagerDuty service keys and Slack/Mattermost/RocketChat/Webhook bearer-token URLs. This flaw affects confidentiality.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/23/2026

The vulnerability identified in the automation-controller notification subsystem represents a critical failure in data isolation and access control mechanisms within multi-tenant environments. The core technical flaw stems from an inconsistent handling of sensitive configuration data during the serialization process for API responses. Specifically, while the NotificationTemplate object attempts to protect its internal notification_configuration field through API filtering mechanisms, this protection is bypassed when the system copies recipient values into a separate, unprotected Notification.recipients field upon every send operation. This architectural inconsistency creates a direct pathway for unauthorized access to sensitive credentials that are intended to be isolated per tenant or organization. The flaw fundamentally undermines the confidentiality guarantees expected in enterprise automation platforms where multiple distinct organizations share infrastructure but require strict logical separation of their operational secrets and communication channels.

The exploitation vector relies on a sophisticated combination of information leakage and relational traversal weaknesses within the API backend. Although direct access to sensitive fields is restricted, the credential-types endpoint remains listable by any authenticated user, providing an initial foothold for enumeration. More critically, the API filter backend traverses object relations without enforcing per-hop authorization checks. This design oversight allows a low-privileged or unauthenticated user to construct relational filters that act as boolean count-oracles. By manipulating these queries and analyzing the response counts, an attacker can perform character-by-character extraction of secret recipient values across organizational boundaries. This technique effectively bypasses standard access controls by leveraging the database query structure rather than attempting direct unauthorized reads, turning a simple listing capability into a powerful data exfiltration tool for PagerDuty service keys, Slack tokens, Mattermost credentials, RocketChat secrets, and generic webhook bearer-token URLs.

The operational impact of this vulnerability is severe, particularly in environments where automation controllers manage critical infrastructure alerts and incident response workflows. The exposure of PagerDuty service keys allows attackers to trigger false alarms or silence legitimate ones, disrupting business continuity and potentially causing financial loss through unnecessary on-call escalations or missed critical incidents. Similarly, the compromise of Slack, Mattermost, RocketChat, or webhook bearer tokens enables unauthorized access to internal communication channels. Attackers can inject malicious commands into automated workflows, exfiltrate sensitive data shared within these channels, or impersonate legitimate automation processes to execute further attacks against connected systems. The ability to recover secrets character by character across organizations means that a single compromised low-privileged account in one tenant can lead to the complete compromise of security credentials for all other tenants sharing the same controller instance, leading to widespread confidentiality breaches and potential lateral movement within the broader network ecosystem.

This vulnerability aligns with CWE-200, which classifies it as an Information Exposure Vulnerability, specifically highlighting the exposure of sensitive information through improper access controls. Furthermore, the exploitation technique involving relational filters for data extraction maps directly to ATT&CK T1537, which describes Transfer Data to Cloud Account or Service via Exfiltration Over Alternative Protocol, although in this context, it is more accurately described as exfiltration over an API using boolean-based side-channel techniques akin to blind SQL injection principles. The failure to enforce per-hop authorization during relation traversal also reflects CWE-862, a Missing Authorization issue, where the system fails to verify that the user has permission for each step in the data retrieval chain.

Mitigation strategies must address both the immediate technical flaw and the broader architectural weaknesses. Immediately, administrators should apply vendor-provided patches that correct the serialization logic to ensure sensitive recipient fields are never copied into unprotected structures or are properly masked before API response generation. In parallel, access control policies must be reviewed to restrict listability of credential-types endpoints to privileged users only, reducing the initial attack surface. Crucially, the API backend requires a comprehensive audit and patching to enforce strict per-hop authorization checks during relation traversal. This ensures that every step in an object graph query validates the requesting user's permissions against the specific resource being accessed at that hop, preventing relational filters from acting as boolean oracles for cross-tenant data extraction. Regular security assessments focusing on multi-tenancy isolation and API filter logic are essential to prevent similar vulnerabilities from emerging in related subsystems.

Responsible

Redhat

Reservation

09/02/2026

Disclosure

09/23/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!