CVE-2026-79717 in Ansible Automation Platform
Summary
by MITRE • 08/25/2026
A server-side request forgery (SSRF) vulnerability was found in galaxy_ng, the Ansible Galaxy server plugin for Pulp. An authenticated user with namespace management permissions can set a namespace avatar URL to an arbitrary address, including internal networks, loopback, or cloud instance metadata endpoints. A background worker fetches that URL without checking the destination, which lets the attacker probe internal services and enumerate reachable IP addresses. The HTTP client is also configured without an overall timeout, so a slow or non-responsive target can pin workers and cause a denial of service.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in galaxy_ng, specifically within the Ansible Galaxy server plugin for Pulp, represents a critical security flaw rooted in Server-Side Request Forgery (SSRF). This issue allows an authenticated user who possesses namespace management permissions to manipulate the system into making HTTP requests on their behalf. By setting the avatar URL field of a namespace to an arbitrary address, the attacker can direct the server's background worker process toward internal network resources, loopback interfaces, or cloud instance metadata endpoints that are typically inaccessible from external networks. This capability effectively bypasses standard perimeter defenses because the request originates from within the trusted environment of the application server itself. The core technical flaw lies in the absence of input validation and URL filtering mechanisms when processing the avatar URL field. Instead of restricting requests to a predefined whitelist or validating against known safe domains, the system blindly accepts any valid URI format provided by the user. This lack of sanitization enables the attacker to probe internal services that may be running on non-public ports or protected by firewalls that only allow traffic from specific application servers.
The operational impact of this vulnerability extends beyond simple information disclosure. The ability to enumerate reachable IP addresses and access cloud metadata endpoints can lead to significant data exfiltration, particularly in cloud environments where instance metadata often contains sensitive configuration details, temporary credentials, or other secrets necessary for further exploitation. Furthermore, the HTTP client implementation within galaxy_ng lacks an overall timeout setting. This architectural oversight means that if a target server responds slowly or fails to respond entirely, the background worker thread remains blocked waiting for data indefinitely. In a multi-threaded application environment, this behavior can lead to resource exhaustion as workers are pinned by unresponsive connections. Over time, this accumulation of stalled threads degrades system performance and can result in a denial of service condition, rendering the Ansible Galaxy interface unavailable to legitimate users. This combination of SSRF-induced information leakage and potential availability impact classifies the vulnerability as high severity due to its ease of exploitation for authenticated insiders or compromised accounts with limited privileges.
From a standards perspective, this flaw aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where a web server fetches a URL provided by an attacker without performing sufficient validation. The specific mechanism of using the avatar upload feature as a vector for SSRF is a common pattern in modern web applications that handle user-uploaded media or profile data. Additionally, the lack of timeout configuration relates to CWE-400, Uncontrolled Resource Consumption, which contributes to the denial of service aspect of this vulnerability. In terms of attack tactics, this scenario maps to MITRE ATT&CK technique T1598, specifically Phishing for Information from Cloud Infrastructure or Internal Network Scanning via SSRF, depending on whether cloud metadata is targeted or internal services are probed. The exploitation path relies heavily on the principle of least privilege being insufficiently enforced at the application logic level rather than just network layer controls.
To mitigate this vulnerability, immediate remediation should focus on implementing strict URL validation and filtering rules for all user-supplied URLs that trigger server-side requests. This includes enforcing a whitelist approach where only specific domains or IP ranges are permitted for avatar fetching, while explicitly blocking private IP address ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x, as well as loopback addresses like 127.0.0.1. It is also critical to disable HTTP redirects or ensure they are strictly validated against the same whitelist criteria to prevent bypasses via redirection chains. Furthermore, configuring a reasonable overall timeout for the HTTP client used by background workers will prevent resource exhaustion and mitigate the denial of service risk associated with slow or unresponsive targets. Implementing these controls ensures that even if an attacker gains namespace management permissions, they cannot leverage the application's internal network access to probe sensitive infrastructure or destabilize the system through thread blocking. Regular security audits of similar URL-handling features across the codebase are recommended to identify and patch analogous SSRF vectors before they can be exploited.