CVE-2026-71366
Description
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.
Statement
Red Hat has assessed this vulnerability as Important impact. Multiple notification backends in AWX send HTTP requests to user-configured URLs without private-network egress filtering, allowing an organization notification administrator to use the AWX control node as an SSRF proxy to reach internal services. The webhook notification backend compounds this by following redirects and resending Basic Authentication credentials to redirect targets without host validation, enabling credential exfiltration through a controlled redirect. The Grafana notification backend similarly exposes its API key to the configured endpoint. Red Hat Ansible Automation Platform ships all affected notification backends as part of Automation Controller. This flaw is tracked separately from CVE-2026-71365 (webhook status callback SSRF) because it affects a different code path, requires different permissions, and exposes different credentials. In managed service deployments where notification administrators are tenants, the SSRF risk is elevated because tenants should not be able to probe internal infrastructure. Customers are advised to restrict notification template creation to trusted administrators 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 ability to create and modify notification templates to trusted administrators who have legitimate need for this capability.
2. Implement network egress filtering on the Automation Controller nodes to block outbound connections to loopback (127.0.0.0/8), private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local (169.254.0.0/16) address ranges.
3. Monitor notification template configurations for URLs pointing to internal or unusual addresses.
4. Avoid configuring sensitive credentials (Basic Auth, Grafana API keys) in notification templates until the fix is applied. Use notification backends that do not require credentials where possible.
5. Review and audit existing notification templates for URLs pointing to internal services.
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).
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.