CVE-2026-32279: Server-Side Request Forgery in Connect-CMS External Page Migration

Connect-CMS exposes an "External Page Migration" feature within the Page Management Plugin. This component allows administrators to import external HTML content directly into the content management system. The intended functionality provides a convenient mechanism for migrating content from legacy systems or external websites.

CVE-2026-32279 is a Server-Side Request Forgery (SSRF) vulnerability categorized under CWE-918. The application accepts user-supplied URLs and issues outbound HTTP requests to them without adequately verifying the destination network block. The backend server acts as a proxy, fetching the requested resource on behalf of the user.

An authenticated attacker with administrative privileges can force the underlying server to issue arbitrary HTTP requests. This permits interaction with internal network resources, loopback interfaces, and cloud provider metadata services. The attack occurs entirely from the server's network context, effectively bypassing external firewall restrictions.

The requirement for administrative privileges limits the attack surface and reduces the overall CVSS score to 6.8. However, in scenarios where an attacker compromises an administrative account via credential stuffing or cross-site scripting, this vulnerability provides a critical pivot point into the internal infrastructure.

The flaw originates in the migrationGet method within the app/Plugins/Manage/PageManage/PageManage.php controller. The application relies on Laravel's standard Validator facade to ensure the url parameter is present in the incoming HTTP request. This parameter dictates the target from which the application retrieves external content.

The validation schema solely enforces the required constraint. It omits critical checks for URL scheme, host resolution, and destination IP address classification. Consequently, the backend application accepts any well-formed string as a valid migration target, regardless of whether it points to a public or private IP address.

Following parameter extraction, the application invokes a server-side HTTP client to fetch the remote content. Because the framework does not implement a network boundary filter, the HTTP client blindly connects to the specified host. This behavior violates the principle of safe external resource inclusion.

The underlying HTTP client also follows redirects automatically by default. This default behavior introduces a secondary risk known as a Redirect SSRF. An attacker can supply a public URL that passes initial scrutiny but subsequently redirects the server to an internal IP address during the HTTP handshake.

Unpatched versions implement insufficient input validation. The migrationGet method constructs a validator that checks only for the presence of the source_system, url, and destination_page_id parameters. The following snippet illustrates the vulnerable controller logic prior to version 1.41.1:

$validator = Validator::make($request->all(), [
    'source_system'       => 'required',
    'url'                 => 'required', // Missing destination validation
    'destination_page_id' => 'required',
]);

The remediation introduces a dedicated utility class, UrlUtils::isGlobalHttpUrl, which implements rigorous SSRF protections. The patch modifies the validation pipeline to enforce this custom rule before initiating any outbound connections. The core validation logic is shown below:

public static function isGlobalHttpUrl(string $url): bool
{
    $parsed_url = parse_url($url);
    if ($parsed_url === false || !isset($parsed_url['scheme']) || !isset($parsed_url['host'])) {
        return false;
    }
 
    $scheme = strtolower($parsed_url['scheme']);
    if (!in_array($scheme, ['http', 'https'], true)) {
        return false; // Restrict to HTTP/HTTPS
    }
 
    $host = self::normalizeHost($parsed_url['host']);
    if ($host === '' || self::isLocalhost($host)) {
        return false; // Block localhost
    }
 
    // DNS Resolution check for all IPs (A and AAAA)
    $resolved_ips = self::resolveHostIps($host);
    foreach ($resolved_ips as $ip) {
        if (!self::isGlobalIp($ip)) {
            return false; // Block if ANY resolved IP is private/reserved
        }
    }
    return true;
}

The patched implementation first verifies the URL scheme to restrict connections to HTTP and HTTPS protocols. It subsequently normalizes the host and rejects explicit loopback addresses. Finally, it resolves the hostname to its underlying IP addresses and uses PHP's filter_var function with FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE flags to ensure no resolved IP falls within private or reserved address spaces.

To address open redirect abuse, the updated application disables automatic HTTP redirection in the client configuration. The application now manually tracks redirect headers and reapplies the isGlobalHttpUrl validation against every subsequent URL in the redirect chain.

Exploitation requires the attacker to possess an active session with page management privileges. The attacker navigates to the administrative interface and accesses the "External Page Migration" module. This module presents a form requesting the source URL of the content to be migrated.

The attacker crafts a malicious payload by entering a targeted internal URI into the "Source URL" field. Examples of high-value targets include the local loopback address (http://127.0.0.1:8080/admin), private network infrastructure (http://192.168.1.254/config), or cloud metadata endpoints (http://169.254.169.254/latest/meta-data/).

Upon form submission, the application issues the forged request from the server's network context. The HTTP response is subsequently processed by the migration routine. Depending on the exact logic, the application returns the fetched data in the user interface or infers state based on success or failure error messages.

This capability allows an attacker to map internal network topologies via port scanning. The attacker observes timing differences or HTTP status codes returned by the migration endpoint to determine which internal hosts and services are active. Successful retrieval of data directly results in the exposure of sensitive internal information.

The CVSS v3.1 base score for this vulnerability is 6.8, reflecting a Medium severity level. The requirement for administrative privileges (PR:H) reduces the overall score, but the resulting impact on confidentiality remains high (C:H). The vulnerability operates over the network (AV:N) and requires low attack complexity (AC:L).

Successful exploitation enables an attacker to bypass network perimeter controls. The attacker leverages the vulnerable server as a proxy to interact with systems that are not directly exposed to the internet. This exposes administrative interfaces, internal APIs, and unauthenticated internal databases to the attacker.

In cloud environments such as AWS, Azure, or GCP, an attacker can target the instance metadata service (IMDS). Fetching the metadata endpoint often yields temporary security credentials, instance configuration data, and user-data scripts. These credentials facilitate unauthorized access to other cloud resources, leading to broader infrastructure compromise.

The scope change metric (S:C) indicates that the vulnerability affects components beyond the vulnerable application itself. The attacker effectively attacks the internal network infrastructure, secondary applications, or adjacent cloud resources using the CMS application as the conduit.

The vendor addressed the vulnerability in Connect-CMS versions 1.41.1 and 2.41.1. Upgrading to these versions replaces the vulnerable endpoint logic with the newly implemented UrlUtils validation framework. The patch guarantees that all outbound requests originating from the migration feature target globally routable IP addresses.

The update also hardens the broader application ecosystem. The patch updates Node.js dependencies (qs and express) to mitigate unrelated prototype pollution risks. Additionally, it refines the upload controller to restrict .html file uploads, implementing defense-in-depth measures against SSRF payload staging and cross-site scripting vectors.

Organizations that cannot immediately deploy the patch should implement network-level mitigations. Administrators should apply egress filtering rules to the server hosting Connect-CMS. These rules must explicitly block outbound HTTP and HTTPS connections to internal subnets (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and the cloud metadata IP address (169.254.169.254).

Requiring IMDSv2 on cloud instances effectively mitigates metadata extraction via simple GET requests. IMDSv2 requires a specific X-aws-ec2-metadata-token header, which standard SSRF vulnerabilities cannot typically inject. Applying this configuration secures the instance credentials regardless of the application layer flaw.