Ansible Automation Platform EUVD-2026-85614

Requires a valid authenticated account on the automation-controller: either read access to a workflow (PR:L path), or - via a regex lookup that bypasses the JSON cross-relation filter guard through the world-readable credential-types endpoint - any authenticated user with no roles at all. The target secrets must have been propagated as merged set_stats artifacts into WorkflowJobNode.ancestor_artifacts and persisted before Ansible's no_log masking, so exploitation depends on workflows that use set_stats to pass data between nodes. Limiting factors: an account is mandatory (not internet-anonymous), and recovery is an incremental count/boolean oracle requiring many requests per secret character, making it slow and noisy rather than a single-shot read.

This is a genuine but bounded confidentiality issue, not a top-tier emergency. The Red Hat CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) correctly captures a network-exploitable, low-complexity flaw needing only a low-privileged authenticated account, with pure confidentiality impact (C:H, no integrity or availability effect) - consistent with CWE-639 (authorization bypass through user-controlled key / IDOR). No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis'; this argues against imminent mass exploitation. The severity is driven by impact, not ease of mass-abuse: it is a slow character-by-character oracle attack requiring many crafted REST filter requests, so it favors a targeted, patient adversary already inside the platform over opportunistic scanning. One conflict to verify: the vector states PR:L, but the description notes a second path via the world-readable credential-types endpoint usable by 'any authenticated user with no roles,' which is functionally near-unauthenticated-insider access - the effective barrier may be lower than PR:L implies, though a valid account is still required. Cross-org secret recovery (no_log-masked values) meaningfully raises the stakes in multi-tenant AAP deployments.

A low-privileged authenticated AAP user (in the worst case, a valid account with no assigned roles) issues crafted REST API filter queries against the WorkflowJobNode.ancestor_artifacts column using regular-expression/count lookups, reading the result count as a boolean oracle. By iterating character positions, they reconstruct secret values a playbook author marked no_log - including secrets belonging to other organizations. No public exploit code is identified, but the technique is deterministic and scriptable given the described filter behavior.