CVE-2026-71463

In CopyAPIView (awx/awx/api/generics.py:873), permission_classes = (IsAuthenticated,) is set, so DRF's get_object() performs no object-level RBAC. The get() handler explicitly guards with request.user.can_access(obj._class_, 'read', obj), but post() does not — it only checks can_access(model, 'add', create_kwargs_check) and can_access(model, 'copy_related', obj). For JobTemplate, can_add and can_copy_related do not imply read permission on the source job template.

LaunchConfigurationBaseSerializer.scm_branch has no validate_scm_branch() leading-dash check, unlike Project/JobTemplate/JobLaunch serializers. Schedule and WFJT Node accept --upload-pack=/bin/id as scm_branch. Currently blocked at runtime by jobs.py:1502 ValueError check (defense-in-depth), but the API validation gap means sole reliance on a task-layer guard. Refactoring that guard away would promote this to RCE.

The StringListPathField.to_internal_value() method calls os.path.exists() on unbounded user-supplied paths. The 200 vs 400 response difference reveals the existence of arbitrary absolute paths on the controller-web pod, including sensitive files like SECRET_KEY or service account tokens.

The HostList.list() method catches bare Exception and returns str(e) verbatim. Via host_filter, any authenticated user can trigger Django FieldError (leaking the complete Host model relation graph) or PostgreSQL DataError (leaking raw database error strings).

The /api/v2/config/ endpoint is protected only by IsAuthenticated, meaning any authenticated user receives license_info, including account numbers, subscription IDs, pool_id, SKU, support level, and instance counts. The superuser/auditor gate only covers other fields, not license_info.

The JobJobEventsChildrenSummary view has no model or parent_model, causing ModelAccessPermission.check_get_permissions() to return True for any authenticated user. The view uses raw get_object_or_404(Job, pk) without DRF object-level permission check, allowing a zero-privilege user to read event tree structure and enumerate Job IDs platform-wide.

URLModificationMiddleware resolves named-URL lookups against unfiltered Model.objects before RBAC. The 403→404 shim only rewrites 403 responses, leaving the pk=0 miss path with a different 404 detail string. The differential "Not found." vs "No <Model> matches..." reveals whether a named resource exists on the platform.

A flaw in AWX: the container group pod_spec_override field uses an incomplete blocklist that only restricts automountServiceAccountToken, allowing injection of initContainers, serviceAccountName overrides, and projected service account token volumes. An AAP platform administrator can exploit this to escalate privileges to OpenShift namespace-level access and exfiltrate namespace secrets.

A server-side request forgery (SSRF) vulnerability was found in multiple AWX notification backends. The webhook, Mattermost, Rocket.Chat, and Grafana notification backends use notification template URLs as direct HTTP request targets without validating the target address against private, loopback, or reserved IP ranges. An organization notification administrator can create notification templates pointing to internal or loopback addresses, causing the AWX control node to issue HTTP requests to services that are not externally accessible. Additionally, the webhook notification backend follows HTTP redirects and resends configured Basic Authentication credentials to redirect targets regardless of host change, allowing an attacker to exfiltrate notification credentials by redirecting to an attacker-controlled host. The Grafana backend sends its API key in the Authorization header to the configured target URL.

A path traversal vulnerability was found in AWX's project archive extraction. The project_archive action plugin extracts zip and tar archive members by joining the project directory path with the member filename without performing path normalization, boundary validation, or rejecting directory traversal sequences. A malicious archive containing members with path traversal components can write files to arbitrary locations on the execution node's filesystem outside the intended project directory. An attacker who controls the archive content, either through a compromised upstream source, a malicious archive URL, or a man-in-the-middle attack on a plain HTTP connection, can achieve arbitrary file writes as the user performing the extraction, potentially leading to remote code execution through mechanisms such as cron files, SSH authorized keys, or playbook content injection.