Ansible Automation Platform CVE-2026-71459

Exploitation requires a valid authenticated account on the Ansible Automation Platform 2 controller (PR:L) - even a zero-privilege user with no special roles suffices, because ModelAccessPermission.check_get_permissions() returns True for any authenticated principal and the JobJobEventsChildrenSummary view defines no model/parent_model and performs no DRF object-level permission check. The specific enabling condition is this particular endpoint's missing object-level authorization; the correctly-guarded sibling endpoint (/jobs/{id}/job_events/) returning 403 confirms the flaw is endpoint-specific rather than platform-wide. Limiting factors: an account is mandatory (not exploitable pre-authentication), no user interaction is needed, impact is confidentiality-only (event-tree structure, event_processing_finished status, and Job ID existence via a 200/404 oracle) with no data modification or service disruption.

This is a genuine but low-to-moderate priority information-disclosure flaw, not a critical issue. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N, base 5.0) tells a consistent story: network-reachable, low complexity, but requiring authentication (PR:L) and yielding confidentiality-only impact at Low magnitude (C:L, no integrity or availability effect). CWE-862 (Missing Authorization) matches the description precisely - a broken object-level authorization / IDOR where ModelAccessPermission.check_get_permissions() falls through to True and the view uses raw get_object_or_404 without a DRF object-level check. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation likelihood signals are all absent rather than elevated; there is no evidence of active exploitation. The description's contrast with the sibling endpoint (/jobs/{id}/job_events/ correctly returns 403) strongly corroborates that this is a real, verifiable regression rather than a theoretical concern. One point to flag: the vendor assigned S:C (scope change), justified by platform-wide/cross-organization Job ID enumeration and metadata leakage crossing tenant authority; a conservative reading favors S:U (same application authority), which would lower the score to ~4.3 - verify multi-tenancy boundary crossing with Red Hat. The real-world value to an attacker is reconnaissance (enumerating Job IDs and reading event-tree/processing status), not direct compromise.

A low-privilege but authenticated user of an Ansible Automation Platform controller sends GET requests to the JobJobEventsChildrenSummary endpoint, iterating Job primary keys and using the 200-vs-404 response as an oracle to enumerate every Job ID on the platform, including those belonging to other teams or organizations. For each existing Job the attacker reads the event tree structure and event_processing_finished status, harvesting operational reconnaissance about automation activity they should not see. No public exploit code was identified, but the attack requires only ordinary authenticated API access and trivial ID iteration.