Ansible Automation Platform CVE-2026-76648

Exploitation requires an authenticated AWX/Red Hat Ansible Automation Platform 2 account (PR:L) that already holds the resource-level roles gating the copy: inventory.use_role, project.use_role, and execution_environment.read_role (checked by can_add), plus credentials.use_role (checked by can_copy_related). The attacker must NOT need - and specifically lacks - read access on the source JobTemplate, which is exactly the missing check. Exploitation is via a network POST to the CopyAPIView endpoint (awx/awx/api/generics.py) against a default configuration; the GET path is unaffected because it correctly enforces the read guard. Limiting factors: valid credentials and the above use/read roles are prerequisites, so this is an insider/multi-tenant privilege-boundary flaw rather than unauthenticated remote compromise; no user interaction is needed.

This is a credible but non-critical priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, 8.5) describes a network-reachable, low-complexity flaw exploitable by any authenticated low-privilege user who already holds resource-level roles (inventory.use_role, project.use_role, execution_environment.read_role, and credentials.use_role). The core weakness is CWE-862: CopyAPIView's post() handler omits the request.user.can_access(obj._class_, 'read', obj) guard that its own get() handler enforces, so a user who can 'add' and 'copy_related' a JobTemplate can duplicate - and thereby read - a source JobTemplate they have no read permission on. I assess the vendor's S:C and resulting 8.5 as slightly generous: the impact stays inside AWX's single RBAC authority, so S:U (~7.1) is more defensible, though a cross-organization read is a reasonable argument for S:C. Impact is primarily confidentiality (C:H - disclosure of another org/user's JobTemplate configuration via the copy) with minor integrity (I:L - a new object is created) and no availability impact. 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 is a Red Hat self-reported code-audit finding (Bugzilla 2519720), not an observed-in-the-wild issue. The requirement for pre-existing valid credentials and specific resource roles meaningfully limits real-world exposure to insider/multi-tenant abuse rather than opportunistic external attack.

A low-privilege AWX/AAP user who has been granted use_role on an inventory, project, execution environment, and the relevant credentials - but no read access to a sensitive JobTemplate owned by another team - sends a crafted POST to the CopyAPIView endpoint for that JobTemplate. Because post() only checks 'add' and 'copy_related' roles and never verifies 'read' on the source object, the server clones the JobTemplate into a template the attacker can read, disclosing its configuration. No public exploit code was identified; this is a vendor code-audit finding.