Ansible Automation Platform EUVD-2026-85610

Requires an authenticated account of any privilege level on a Red Hat Ansible Automation Platform 2 automation-controller instance; no elevated role is needed because the credential-types endpoint is listable by any authenticated user and the API filter backend traverses object relations without per-hop authorization. The target secret must have been copied into the unprotected Notification.recipients field, which happens on every notification send, so the deployment must be actively using notification templates with sensitive recipients (PagerDuty service keys, Slack/Mattermost/RocketChat/Webhook bearer-token URLs). Practical limits: exploitation is a slow character-by-character boolean count-oracle requiring many iterative API requests (potentially detectable in logs), and value is highest in multi-tenant deployments where cross-organization secret recovery breaks tenant isolation; impact is confidentiality only (no integrity or availability effect).

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) is internally consistent and well-supported by the description: a network-reachable, low-complexity attack requiring only a low-privilege authenticated account (any authenticated user can list the credential-types endpoint and abuse the relational filter backend), yielding high confidentiality impact with no integrity or availability effect. This is a genuine confidentiality risk rather than a CVSS-inflated non-issue - the count-oracle deterministically recovers cross-organization secret recipient values (PagerDuty service keys, Slack/Mattermost/RocketChat/Webhook bearer-token URLs) character by character, breaking tenant isolation. However, real-world urgency is tempered: no EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active or imminent exploitation. Exploitation status: no public exploit identified at time of analysis. The attack is slow and noisy (iterative boolean queries per character) and requires an existing authenticated foothold, so this is a priority for multi-tenant AAP operators to patch but not an emergency drive-by. One data-quality caveat: the 'Authentication Bypass' tag conflicts with the actual mechanism (CWE-639 is an authorization/IDOR issue enabled through a low-priv authenticated account, not an auth bypass).

A low-privileged tenant user in a shared Red Hat Ansible Automation Platform 2 deployment issues API requests using a relational filter that traverses object relations to the Notification.recipients field without per-hop authorization. By observing whether each filtered query returns a matching count (a boolean oracle), the attacker reconstructs another organization's secret notification recipients - such as a PagerDuty service key or a Slack/Webhook bearer-token URL - one character at a time. No public exploit code is identified, and exploitation requires an authenticated account plus many iterative requests.