CVE-2026-12726: AWX GitHub Webhook Credential Exfiltration Vulnerability
AWX, an open-source automation platform, contains a vulnerability in how it handles GitHub webhook callbacks. When a job template is set up with GitHub credentials and receives a webhook notification about a pull request, the system doesn't properly verify that callback URLs are legitimate GitHub endpoints. An attacker who can craft a valid webhook message to the job template can trick the controller into sending sensitive GitHub credentials to an attacker-controlled server, exposing the stored Personal Access Token. The attack requires authenticated access to submit the forged webhook, but the impact—credential theft—is severe.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 6.3 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
- Weaknesses (CWE)
- CWE-918
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-19 / 2026-06-22
NVD description (verbatim)
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.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The vulnerability stems from insufficient validation of the pull_request.statuses_url value extracted from GitHub webhook payloads in AWX. The controller accepts and stores this URL without verifying it points to a trusted GitHub API domain. Later, when job status updates are posted, the system POSTs to the stored callback URL and includes the configured GitHub Personal Access Token in the request. An attacker with knowledge of a job template's webhook_key can forge a correctly signed webhook payload, embed a malicious statuses_url pointing to attacker infrastructure, and capture the PAT when the controller attempts to post status updates. This is classified as a Server-Side Request Forgery variant (CWE-918) because the server is being manipulated into making requests to unintended endpoints and leaking sensitive credentials in the process.
Business impact
Compromise of GitHub Personal Access Tokens stored in AWX job templates can grant attackers repository access, the ability to create or modify automation workflows, access to sensitive code and configurations, and potential lateral movement into other systems that trust the compromised token. For organizations using AWX to automate deployment pipelines or infrastructure management, token theft could lead to unauthorized code changes, deployment of malicious artifacts, or exposure of deployment credentials and secrets. The blast radius depends on the scope and permissions of the stolen PAT and how widely that token is used across the organization's GitHub ecosystem.
Affected systems
AWX is affected by this vulnerability. The vendors_products field in the source data is empty, indicating that only AWX itself is confirmed impacted. Administrators should verify the exact affected version range against the official AWX advisory. Systems running AWX with GitHub-based job templates that use Personal Access Token credentials as webhook credentials are at highest risk.
Exploitability
Exploitability requires the attacker to possess or deduce the job template's webhook_key, which is a shared secret used to sign webhook payloads. This requirement for authentication (PR:L in the CVSS vector) means casual external attackers cannot exploit the flaw; however, any authenticated AWX user or someone who obtains the webhook_key can perform the attack. The attack does not require user interaction, and a correctly signed payload will be processed automatically by the controller. The CVSS score of 6.3 reflects this balance: medium severity due to the authentication requirement, but high confidentiality impact given the credential exfiltration outcome.
Remediation
Remediation requires patching AWX to validate that callback URLs in webhook payloads point to legitimate, expected GitHub API endpoints before storing or using them. Additionally, credential handling should be reviewed to ensure that sensitive tokens are not unnecessarily included in outbound requests to user-controlled URLs. Organizations should consult the AWX advisory for the specific patched version and apply it to all affected AWX deployments. Until patching is possible, restrict webhook access to trusted networks and review GitHub PAT permissions to follow the principle of least privilege.
Patch guidance
Check the official AWX release notes and security advisory for the patched version number and upgrade instructions. Verify the patch includes URL validation logic for webhook callback endpoints and confirm that GitHub PAT credentials are no longer transmitted to untrusted endpoints. After patching, validate in a staging environment that existing GitHub-integrated job templates continue to function correctly.
Detection guidance
Monitor AWX controller logs for POST requests to unexpected or non-GitHub URLs. Set up alerts for any job status update callbacks that deviate from the expected GitHub API domain pattern. Review audit logs for modifications to job template webhook settings or credentials. Network detection should flag outbound HTTPS connections from AWX controllers to non-GitHub IP ranges or domains. Additionally, implement monitoring of GitHub Personal Access Token usage patterns to detect anomalous access or unexpected API calls originating from token activity logs.
Why prioritize this
Although the CVSS score is 6.3 (medium), this vulnerability should be prioritized for patching because it directly enables theft of authentication credentials used for critical infrastructure automation. The impact is confidentiality-based but targets high-value secrets. Organizations with GitHub-based automation pipelines and those storing PATs in AWX should treat this as a near-term remediation priority, especially if the PAT has broad repository or organization-level permissions.
Risk score, explained
CVSS 6.3 reflects a medium-severity vulnerability with high confidentiality impact (C:H) but limited scope and authentication requirement (AV:N/AC:H/PR:L/UI:N/S:C). The score accounts for the fact that an authenticated or webhook-key-aware attacker can exfiltrate a valuable credential, but the attack surface is constrained by the need to know or possess the webhook_key and the requirement for the job template to be configured with GitHub PAT credentials. The Medium severity rating appropriately captures the risk: this is not a system-wide compromise vector, but a targeted credential theft mechanism that requires specific configuration and attacker foreknowledge.
Frequently asked questions
Can an external attacker exploit this without any prior knowledge of our AWX setup?
No. The attacker must either possess the job template's webhook_key or be an authenticated AWX user. The webhook_key is a shared secret, and forged webhooks without correct signatures are rejected. This requirement is reflected in the CVSS metric PR:L (Privileges Required: Low). However, if the webhook_key is exposed or if an insider has AWX access, the attack becomes feasible.
What is the webhook_key and where should we find it?
The webhook_key is a secret token generated when a job template is configured to receive webhooks from an external system like GitHub. It is used to cryptographically sign webhook payloads to ensure authenticity. In AWX, you can view and rotate the webhook_key in the job template settings under the 'Webhooks' section. If you suspect it has been compromised, rotate it immediately.
If we use GitHub App credentials instead of Personal Access Tokens, are we protected from this vulnerability?
GitHub App credentials and PATs are handled differently in AWX. If a job template uses GitHub App authentication instead of a PAT, the token exfiltration risk is reduced because GitHub App tokens are typically more tightly scoped and have shorter lifespans. However, the underlying validation flaw still exists. Patch the vulnerability and, where possible, prefer GitHub App authentication as a defense-in-depth measure.
What should we do immediately while waiting for a patch?
Review all GitHub-integrated job templates and identify those using Personal Access Token credentials. Assess the permissions of those PATs and consider rotating them or restricting their scope. Restrict webhook access to your AWX controller to GitHub's IP address ranges. Enable audit logging to detect any suspicious callback URL modifications. Once a patch is available, test it in a staging environment and deploy promptly.
This analysis is provided for informational purposes and represents SEC.co's interpretation of the disclosed vulnerability details. Verify all version numbers, patch guidance, and remediation steps against the official AWX advisory and vendor documentation before implementation. No exploit code or attack reproduction guidance is provided. Organizations should conduct their own risk assessment based on their deployment, configuration, and threat landscape. This page does not constitute security advice and should be reviewed in conjunction with your organization's security policies and the vendor's official guidance. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2025-58175MEDIUMGeoServer SSRF Vulnerability in Proxy Configuration
- CVE-2026-10052MEDIUMQuay SSRF in LDAP/SMTP Validation—Internal Network Reconnaissance Risk
- CVE-2026-10177MEDIUMSSRF in Aider-AI Aider 0.86.3 AWS Metadata Endpoint
- CVE-2026-10239MEDIUMJeecgBoot Server-Side Request Forgery (SSRF) in Word Editing Module
- CVE-2026-10240MEDIUMJeecgBoot SSRF Vulnerability in /airag/airagModel/test Endpoint
- CVE-2026-10241MEDIUMJimuReport SSRF in File Download Function – Patch to 3.9.2
- CVE-2026-10274MEDIUMServer-Side Request Forgery in aem-mcp-server
- CVE-2026-10276MEDIUMJenkins-server-mcp SSRF Vulnerability (0.1.0)