EUVD-2026-38065
GHSA-w8qh-qh69-53cx
Severity by source
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
Attacker must hold the webhook_key (PR:L), target must have PAT-based credentials configured (AC:H), and stolen PAT impacts GitHub outside AWX (S:C/C:H).
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
A flaw was found in the AWX GitHub webhook integration. When processing GitHub pull_request webhooks, the controller stores the pull_request.statuses_url value from the webhook payload without validating that it points to a trusted GitHub API endpoint. If a job template is configured with a GitHub Personal Access Token as its webhook credential, the controller later POSTs that token to the stored callback URL when posting job status updates. An attacker who can submit a correctly signed forged webhook using the job template's webhook_key can redirect the callback to an attacker-controlled URL and exfiltrate the configured GitHub PAT.
AnalysisAI
Server-Side Request Forgery in AWX's GitHub webhook integration (Red Hat Ansible Automation Platform 2) enables a remote attacker possessing a job template's webhook_key to redirect PAT-bearing status callbacks to an attacker-controlled endpoint, exfiltrating the configured GitHub Personal Access Token. The attack exploits AWX's failure to validate that the pull_request.statuses_url field in an incoming webhook payload points to a legitimate GitHub API domain before using it as a POST target. No public exploit is identified at time of analysis, but successful exploitation yields persistent GitHub repository access through the stolen PAT, extending the blast radius well beyond the AWX system itself.
Technical ContextAI
AWX (the open-source upstream component of Red Hat Ansible Automation Platform 2) implements GitHub webhook integration that ingests pull_request events and posts job execution status back to GitHub via the payload-supplied statuses_url field - normally an api.github.com endpoint. The root cause is CWE-918 (Server-Side Request Forgery): AWX stores the statuses_url value from the untrusted webhook JSON body without asserting that the hostname belongs to the expected GitHub API domain. When a job template is configured with a GitHub PAT as its webhook credential, AWX authenticates outbound status POST requests with that PAT as a Bearer token. Because the callback target URL is attacker-controllable through the unvalidated payload field, the PAT is delivered to whatever HTTP endpoint the attacker specifies. Affected products per CPE cpe:2.3:a:red_hat:red_hat_ansible_automation_platform_2:*:*:*:*:*:*:*:* cover all versions of Red Hat Ansible Automation Platform 2; upstream AWX installations with the same webhook architecture are similarly affected.
RemediationAI
Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-12726 and the tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=2490796 for the latest patch availability, as no specific fix version is confirmed in the available data; check for an updated RAAP 2 package release from Red Hat. While awaiting a patch, implement the following specific compensating controls: (1) Apply egress firewall rules on AWX controller hosts that restrict outbound HTTPS to api.github.com only, blocking all other destinations - this directly prevents the SSRF callback from reaching attacker-controlled infrastructure, though it may break other outbound integrations if not scoped carefully. (2) Immediately rotate all GitHub PATs configured as AWX webhook credentials and replace them with fine-grained PATs scoped to the minimum required permissions (e.g., statuses:write on specific repositories only), to limit the impact of any PAT that may have already been exfiltrated. (3) Disable GitHub webhook integration on any job templates that do not strictly require it, reducing the attack surface. (4) Audit AWX outbound network logs for unexpected POST requests to non-GitHub-API domains originating from the webhook processing path, as evidence of prior exploitation. Note that PAT rotation alone does not remediate the underlying SSRF vulnerability.
Credential disclosure in Red Hat Ansible Automation Platform 2.5 and 2.6 allows any authenticated user to retrieve plain
Server-side request forgery in the Red Hat Ansible Automation Platform 2 Controller's HashiCorp Vault credential plugin
Arbitrary file write in pulpcore's FilesystemExport feature allows an authenticated administrator to escape the intended
mTLS authentication bypass in the Red Hat Ansible Automation Platform (AAP) Gateway Envoy proxy allows unauthenticated r
Arbitrary command execution in ansible-core allows an attacker who controls a collection source URI to run commands on a
Local code execution in the Visual Studio Code Ansible (Lightspeed) extension lets a malicious project run arbitrary she
Credential exfiltration via SSRF in AWX's GitHub webhook status callback affects Red Hat Ansible Automation Platform 2:
SSRF vulnerabilities in AWX notification backends (webhook, Mattermost, Rocket.Chat, and Grafana) allow an authenticated
Remote code execution in galaxy_ng's legacy role import API (v1) allows an authenticated user controlling a git reposito
Path traversal in AWX's project_archive action plugin allows arbitrary file writes to execution node filesystems outside
Incomplete RBAC authorization in AWX's websocket event consumer exposes real-time job stdout to any authenticated user,
Server-side request forgery in galaxy_ng, the Ansible Galaxy server plugin for Pulp, allows authenticated users holding
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today