CVE-2026-71365
Description
A server-side request forgery (SSRF) vulnerability was found in AWX's webhook status callback mechanism. When processing GitHub pull request webhooks, AWX extracts the status callback URL (pull_request.statuses_url) from the incoming webhook payload without validating the target host against the expected Git provider. This URL is persisted in job extra variables and later used to send authenticated status updates. A user with admin role on a webhook-enabled job template can read the template's webhook signing key, forge a signed GitHub webhook payload with an arbitrary statuses_url, and cause AWX to POST status updates to an attacker-controlled or internal URL. The status update request includes the configured Git Personal Access Token (PAT) in the Authorization header, resulting in credential leakage to the attacker-specified endpoint.
Statement
Red Hat has assessed this vulnerability as Important impact. The webhook status callback code in AWX does not validate the target URL host before sending authenticated status updates, allowing a job template administrator to redirect status callbacks to arbitrary endpoints and exfiltrate the configured Git PAT credential. This crosses two trust boundaries: first, the template admin role grants operational control over the template but should not provide access to plaintext credential values, which are stored encrypted and not readable through the API; second, the AWX control node is used as a proxy to reach internal or loopback services that are not directly accessible to the attacker. Red Hat Ansible Automation Platform ships the affected code as part of Automation Controller. In managed service deployments where template administrators are tenants, the SSRF additionally allows probing internal service mesh endpoints. Customers are advised to restrict webhook template admin access to trusted users and review webhook-enabled templates until a fix is available.
Mitigation
There is no complete mitigation for this vulnerability other than applying the update when available. However, the following measures reduce exposure:
1. Restrict the admin role on webhook-enabled job templates to trusted personnel who already have legitimate access to the associated Git credentials.
2. Use Git credentials with the minimum required scope (e.g., read-only access to the specific repository) to limit the impact of credential leakage.
3. Implement network egress filtering on the Automation Controller nodes to prevent outbound connections to non-allowlisted hosts. Block outbound connections to loopback (127.0.0.0/8), private (RFC1918), and link-local (169.254.0.0/16) address ranges.
4. Monitor for unusual outbound connections from the Controller node to unexpected destinations.
5. Rotate Git PAT credentials periodically and after any suspected compromise.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.7 | N/A | 7.7 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Changed | N/A | Changed |
| Confidentiality | High | N/A | High |
| Integrity Impact | None | N/A | None |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data
Integrity
Technical Impact: Execute Unauthorized Code or Commands
Access Control
Technical Impact: Bypass Protection Mechanism
By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly. The server can be used as a proxy to conduct port scanning of hosts in internal networks, use other URLs such as that can access documents on the system (using file://), or use other protocols such as gopher:// or tftp://, which may provide greater control over the contents of requests.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
