CVE-2026-49262: Aimeos Pagible CMS SSRF Vulnerability

CVE-2026-49262 Overview

CVE-2026-49262 is a Server-Side Request Forgery (SSRF) vulnerability in the Aimeos Pagible content management system (CMS) prior to version 0.10.4. The administrative proxy route cmsproxy fails to prevent DNS rebinding attacks against its URL validation logic. A Time-of-Check to Time-of-Use (TOCTOU) race condition [CWE-367] exists between the URL validation phase and the subsequent HTTP request phase. Authenticated attackers can leverage this window to access internal network resources and cloud metadata endpoints. Version 0.10.4 addresses the flaw by resolving the hostname once and reusing the resolved IP throughout the request lifecycle.

Critical Impact
Authenticated attackers with access to the admin proxy can reach internal-only services and cloud provider metadata endpoints, potentially exposing sensitive configuration data.

Affected Products

Aimeos Pagible CMS versions prior to 0.10.4
Administrative proxy route (cmsproxy) component
Deployments exposing the admin interface to reachable attackers with low privileges

Discovery Timeline

2026-08-12 - CVE CVE-2026-49262 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-49262

Vulnerability Analysis

The Pagible admin proxy accepts a URL query parameter and fetches remote content on behalf of the requesting user. Prior to the patch, the controller called Utils::isValidUrl($url) to confirm that the hostname resolved to a non-private, non-reserved IP address. The controller then passed the raw URL string to a separate fetch() call. Between these two operations, the DNS record could be updated to return an internal IP address such as 169.254.169.254 or a loopback range. This is the classic DNS rebinding pattern layered on top of a TOCTOU race condition. The proxy would then fetch content from the internal target using the server's network position.

Root Cause

The root cause is the separation of DNS resolution between validation and request execution. isValidUrl() performed its own DNS lookup while the underlying HTTP client performed a fresh lookup at fetch time. An attacker-controlled authoritative DNS server can return different A records for consecutive queries, satisfying validation with a public IP and serving an internal IP to the HTTP client.

Attack Vector

Exploitation requires an authenticated administrative session and user interaction, with high attack complexity due to timing sensitivity. An attacker submits a URL pointing to a host they control. The DNS server returns a public IP for the validation query, then returns an internal or metadata IP for the fetch query. The proxy retrieves the internal content and returns it to the attacker.

php

// Patch: admin/src/Controllers/AdminController.php
$url = (string) $request->query('url');
$range = $request->header('Range') ?: null;

-        if (!\Aimeos\Cms\Utils::isValidUrl($url)) {
+        if (empty($url) || !\Aimeos\Cms\Utils::isValidUrl($url)) {
+            abort(400, 'Invalid or missing URL');
+        }
+
+        $parsed = parse_url($url);
+        $host = $parsed['host'] ?? '';
+        $port = $parsed['port'] ?? (($parsed['scheme'] ?? '') === 'https' ? 443 : 80);
+
+        if (!($ip = \Aimeos\Cms\Utils::resolve($host))) {
             abort(400, 'Invalid or missing URL');
         }

         try {
-            $response = $this->fetch($url, $method, $range);
+            $response = $this->fetch($url, $method, $range, "$host:$port:$ip");

Source: GitHub Commit 09a8205. The fix resolves the host once and pins the resolved IP through cURL's --resolve mechanism, eliminating the second DNS lookup that DNS rebinding relies on.

Detection Methods for CVE-2026-49262

Indicators of Compromise

Requests to cmsproxy with url parameters pointing to attacker-controlled domains with abnormally low DNS TTL values
Outbound HTTP requests from the Pagible server to RFC1918 addresses, 127.0.0.0/8, or cloud metadata IPs such as 169.254.169.254
Proxy responses containing cloud instance metadata, IAM credentials, or internal service banners

Detection Strategies

Monitor web server access logs for cmsproxy requests targeting external hostnames followed by anomalous internal traffic from the same worker process
Correlate DNS query logs with application requests to identify hosts returning multiple distinct IPs within a short time window
Alert on Pagible processes initiating connections to link-local or private address ranges

Monitoring Recommendations

Enable verbose logging on the admin proxy controller, capturing the fully resolved destination IP for every fetch
Deploy egress filtering at the network boundary and log any denied connections from the CMS to private ranges
Track authentication events for administrative accounts that subsequently invoke the proxy route

How to Mitigate CVE-2026-49262

Immediate Actions Required

Upgrade Aimeos Pagible to version 0.10.4 or later, which pins the resolved IP for the entire request lifecycle
Restrict access to the administrative interface to trusted networks or VPN-only routes
Rotate any cloud IAM credentials or tokens that were reachable via instance metadata from the Pagible host

Patch Information

The fix is delivered in commit 09a8205d513ec89ed22cdd7bdae0f4c181cee082 and released in version 0.10.4. The patch introduces a single Utils::resolve() call and forwards the host:port:ip triple to the fetch helper so cURL bypasses DNS resolution during the actual request. Details are available in the GitHub Security Advisory GHSA-mmj8-wcvw-6789.

Workarounds

Block the cmsproxy route at the reverse proxy layer until patching is complete
Configure host-level egress firewall rules that deny outbound traffic from the web server to 169.254.169.254, 127.0.0.0/8, and RFC1918 ranges
Require Instance Metadata Service Version 2 (IMDSv2) on AWS deployments to require session tokens for metadata access

bash

# Example iptables egress restriction for the Pagible service user
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT