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 HatNVDcve.org
Base Score7.7N/A7.7
Attack VectorNetworkN/ANetwork
Attack ComplexityLowN/ALow
Privileges RequiredLowN/ALow
User InteractionNoneN/ANone
ScopeChangedN/AChanged
ConfidentialityHighN/AHigh
Integrity ImpactNoneN/ANone
Availability ImpactNoneN/ANone

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

Want to get errata notifications? Sign up here.