CVE-2026-57232: Server-Side Request Forgery in Contao CMS Feed Reader Module

CVE-2026-57232 describes a Server-Side Request Forgery (SSRF) vulnerability in the Contao Open Source Content Management System (CMS). The defect resides within the Feed Reader front-end module, which is designed to fetch, parse, and display RSS feeds from external sources. Because the network architecture of the module did not restrict target destinations, the application represents an exposed attack surface to anyone capable of editing frontend module configurations.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery). The scope of this issue allows an attacker to direct HTTP requests from the hosting server to arbitrary external hosts, internal local networks, loopback addresses, or cloud-specific instance metadata endpoints. This dynamic allows adversaries to bypass boundary protection systems that restrict direct external access to internal infrastructure.

While the baseline impact on confidentiality is low, the vulnerability introduces operational risks depending on the network environment in which Contao is deployed. The system acts as an open proxy for internal services, rendering administrative panels, microservices, and management daemons vulnerable to targeted enumeration.

The root cause of this vulnerability lies in the implementation of the RSS rendering logic within core-bundle/src/Controller/FrontendModule/FeedReaderController.php. The controller uses a third-party feed-reading library named FeedIo to handle the downloading and formatting of RSS feeds. When fetching external documents, the FeedReaderController::getResponse() function processes user-configured feed URLs and executes the network request using the statement $this->feedIo->read($url, new Feed()).

The underlying HTTP client injected into the feed-reading service was wired directly to the @psr18.http_client service, which maps to Symfony's standard HttpClient wrapper. By default, this HTTP client contains no inherent filters to validate or block destination IP addresses. As a result, the client handles requests targeting internal IP address blocks, such as loopback interfaces (127.0.0.1, [::1]), private subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local addresses (169.254.169.254) with no validation checks.

Additionally, the Data Container Array (DCA) field definition for rss_feed in tl_module.php did not enforce strict schema or protocol verification on the input values. Administrators or users with restricted module-editing permissions could save arbitrary URI schemes and targets. The combination of unvalidated backend database configuration fields and an unfiltered outbound HTTP client directly enabled the SSRF state.

To resolve the vulnerability, the Contao maintainers introduced a decorated HTTP client named NoPrivateNetworkExceptRootPagesHttpClient to wrap Symfony's HTTP client structure. Below is a simplified representation of how the patch inspects and blocks requests to private ranges while permitting legitimate loopback calls to root pages of the CMS.

// Contao\CoreBundle\HttpClient\NoPrivateNetworkExceptRootPagesHttpClient
 
private function ipCheck(string $ip, string|null $host, string $url): void
{
    $ipFlags = FILTER_FLAG_IPV4 | FILTER_FLAG_IPV6;
    if (!\defined('STREAM_PF_INET6')) {
        $ipFlags &= ~FILTER_FLAG_IPV6;
    }
 
    $ipFlags |= FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE;
 
    // Verify if the resolved IP belongs to a public space
    if (false !== filter_var($ip, FILTER_VALIDATE_IP, $ipFlags) && !IpUtils::checkIp($ip, IpUtils::PRIVATE_SUBNETS)) {
        return;
    }
 
    // Allow private IPs only if the request targets a pre-configured CMS root page
    if ($this->originAllowed($url)) {
        return;
    }
 
    throw new TransportException(\sprintf('IP "%s" is blocked for "%s".', $ip, $url));
}

The implementation is robust against DNS Rebinding attacks. Many simple SSRF filters perform a single DNS resolution at the start of the request lifecycle, creating a Time-of-Check to Time-of-Use (TOCTOU) bug. Contao mitigates this risk by registering an on_progress callback with Symfony's HTTP transport, validating the connection's primary_ip during the actual socket connection phase:

$options['on_progress'] = function (int $dlNow, int $dlSize, array $info) use ($onProgress): void {
    static $lastPrimaryIpUrl = '';
    if (!empty($info['primary_ip']) && $info['primary_ip']."\0".$info['url'] !== $lastPrimaryIpUrl) {
        $this->ipCheck($info['primary_ip'], null, $info['url']);
        $lastPrimaryIpUrl = $info['primary_ip']."\0".$info['url'];
    }
    null !== $onProgress && $onProgress($dlNow, $dlSize, $info);
};

Furthermore, the patch disables automatic HTTP redirects (max_redirects = 0) at the native library layer. Instead, it processes each redirect link manually within the decorator loop, running the resolved IP check on every hop in the redirection chain. This structure prevents attackers from using a public domain to trigger an internal redirect to loopback services.

Exploitation of CVE-2026-57232 requires low-privileged administrative access to the Contao backend. The attacker must possess credentials belonging to a role permitted to modify frontend modules, specifically those of the Feed Reader type.

Once logged in, the exploitation steps proceed as follows:

First, the attacker creates or edits a Feed Reader module within the administrative interface. In the "RSS feeds" form field, instead of entering a legitimate external feed, they input an address pointing to a restricted internal network resource, such as http://169.254.169.254/latest/meta-data/.

Second, the module configuration is saved to the database. The attacker then ensures this module is assigned to a published page. When the attacker or an unsuspecting visitor requests the page containing the Feed Reader module, the server-side application processes the page and executes FeedReaderController::getResponse().

Third, the web server initiates an outbound HTTP request directly to the specified target. If the service on the targeted IP returns structured XML, the module may render parts of the data. Even if the service returns non-XML data resulting in a parsing error, the attacker can verify connectivity, perform blind SSRF, or measure response times to map active ports and internal network infrastructure.

The impact of CVE-2026-57232 is quantified by its CVSS v3.1 vector string of CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, yielding a base score of 3.1 (Low). The low score is primarily influenced by the privilege requirement, as an attacker must have a backend account with module modification rights (PR:L), and the high attack complexity (AC:H) due to the parser expecting valid RSS syntax to display response data.

In environments where Contao is deployed on cloud hosting solutions such as AWS, Google Cloud, or Azure, the vulnerability poses a risk of metadata exposure. If the cloud instance is configured with older metadata endpoint formats (such as AWS IMDSv1, which does not require a custom HTTP header), an attacker could query local endpoints to extract sensitive data, instance credentials, or API keys.

In standard enterprise environments, the server-side request capability allows adversaries to bypass perimeter security. An attacker can scan internal corporate networks, map accessible ports on the local host, and trigger arbitrary GET requests against unauthenticated administrative services running within the loopback boundary.

The primary remediation strategy is to upgrade the Contao CMS installation to a fixed version. Maintainers have released patches addressing this vulnerability across all supported branches. System administrators must upgrade immediately to Contao version 5.3.48 (LTS) or version 5.7.9.

If patching cannot be executed immediately, administrators should implement the following mitigating controls:

1. Restrict backend user permissions to ensure that only trusted, highly privileged administrators can create or edit frontend modules, specifically limiting the modification of the Feed Reader module.
2. Apply host-level firewall rules or security groups to prevent the web server process from initiating outbound connections to the local network or cloud metadata addresses (e.g., block outgoing traffic to 169.254.169.254 and limit outbound egress on ports 80 and 443 to known external gateways).
3. Implement a Web Application Firewall (WAF) rule to inspect backend module submission parameters and block input strings in rss_feed fields containing private or loopback IP structures.