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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-08-24T16:17:22.820Z",
  "pubdate": "2026-08-24T16:17:22.820Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability has been identified within multiple notification backends of AWX, specifically impacting the webhook, Mattermost, Rocket.Chat, and Grafana notification components.\nThe root cause involves the direct use of user-supplied notification template URLs as HTTP request targets without adequate validation against private, loopback, or reserved IP address ranges.\nAn authenticated organization notification administrator with sufficient privileges can configure malicious notification templates targeting internal, loopback, or otherwise non-externally accessible services residing on the internal network.\nFurthermore, the webhook notification backend unsafely follows HTTP redirects, inadvertently leaking configured Basic Authentication credentials to attacker-controlled redirect targets regardless of any host changes.\nSimilarly, the Grafana notification backend transmits sensitive API keys within the Authorization header directly to the configured target URL.\nThe successful exploitation of these flaws allows an attacker to interact with internal infrastructure services, perform internal port scanning, and exfiltrate sensitive authentication credentials to external endpoints.\nThe risk implications include unauthorized access to internal services, potential exposure of internal network topologies, and the compromise of critical notification backend secrets.",
  "technicalDetails": "The vulnerability manifests in the notification handling subsystem of AWX, specifically affecting the webhook, Mattermost, Rocket.Chat, and Grafana notification backends.\nThe core vulnerability stems from insufficient input sanitization and validation of notification template URLs prior to initiating outbound HTTP requests from the AWX control node.\nBecause the application fails to restrict target URLs against private IP spaces (such as RFC 1918 addresses), loopback interfaces (127.0.0.1 / ::1), and reserved ranges, the AWX control node acts as an unintended proxy for internal network traversal.\nAn attacker possessing organization notification administrator privileges can define or modify notification templates to point to internal microservices, management interfaces, or localhost-bound services.\nWhen the notification is triggered, the AWX control node issues a direct HTTP request to the specified internal target, granting the attacker the ability to interact with internal APIs or services that lack external exposure.\nIn the context of the webhook notification backend, the implementation unsafely honors HTTP redirect responses by default.\nWhen a redirect is received, the HTTP client automatically resends previously configured Basic Authentication credentials to the new redirect target, even if the destination host has changed.\nAn attacker who controls a redirection endpoint can leverage this behavior to capture and exfiltrate raw Basic Authentication credentials.\nAdditionally, the Grafana notification backend inherently transmits its configured API key within the Authorization header of the outbound HTTP request to the designated target URL.\nIf an administrator configures a Grafana notification template to point to an untrusted or attacker-controlled endpoint, the Grafana API key is exposed directly to that destination.\nAuthentication and privilege requirements involve holding the role of an organization notification administrator to create or modify the vulnerable notification templates.\nThe network exposure involves the outbound network stack of the AWX control node, which can be coerced into initiating connections to arbitrary internal or external network locations."
}