CVE-2026-48707: InstantCMS SSRF Vulnerability

CVE-2026-48707 Overview

CVE-2026-48707 is a Server-Side Request Forgery (SSRF) vulnerability in InstantCMS, a free and open source content management system. The flaw resides in the file upload functionality at system/core/uploader.php (lines 509-532). The "upload from URL" feature validates the initial hostname against a private IP address blacklist, but the check is not re-applied when the HTTP client follows a redirect. An authenticated attacker can supply a public URL that redirects to internal addresses, allowing scanning and access to internal network services. Versions prior to 2.18.2 are affected, and version 2.18.2 contains the fix. The weakness is classified as [CWE-918].

Critical Impact
Authenticated users can pivot the upload feature into an internal network scanner, reaching services on private IP ranges that should be inaccessible from the public internet.

Affected Products

InstantCMS (icms2) versions prior to 2.18.2
system/core/uploader.php component, uploadFromLink() method
Installations exposing the "upload from URL" feature to authenticated users

Discovery Timeline

2026-09-08 - CVE-2026-48707 published to the National Vulnerability Database (NVD)
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-48707

Vulnerability Analysis

The vulnerable code path is the uploadFromLink() method in system/core/uploader.php. This method accepts a user-supplied URL, validates its structure with filter_var() and parse_url(), then performs the download. Before the fix, the private IP blacklist and allowed-host checks were applied only to the hostname parsed from the initial URL. When the underlying HTTP client processed a 3xx response, it followed the Location header without re-validating the new destination. An authenticated user could therefore host a redirector on a public domain that returns a redirect to 127.0.0.1, 169.254.169.254, or any RFC1918 range. The vulnerability enables reconnaissance of internal HTTP services, cloud metadata endpoints, and administrative interfaces bound to loopback or private interfaces.

Root Cause

The root cause is missing revalidation of the destination host after HTTP redirects. The blacklist check occurred once against the user-supplied URL, not against each hop in the redirect chain. This pattern also enables DNS rebinding, where a hostname resolves to a public address at check time and a private address at fetch time. The patch rewrites uploadFromLink() to enforce host validation consistently and tightens URL parsing before any network request is issued.

Attack Vector

Exploitation requires an authenticated account with permission to use the upload-from-URL feature. The attacker submits a URL pointing to an attacker-controlled server that responds with an HTTP redirect to an internal target such as http://127.0.0.1:8080/admin or http://169.254.169.254/latest/meta-data/. InstantCMS follows the redirect and fetches the internal resource, returning content or timing information usable for port scanning and service enumeration.

php

// Patched code from system/core/uploader.php (uploadFromLink method)
public function uploadFromLink(string $post_filename, $allowed_size = 0, $destination = false) {

    $url = trim((string)($_POST[$post_filename] ?? ''));

    if (!$url) {
        return [
            'success' => false,
            'error'   => 'Empty Url',
            'name'    => '',
            'path'    => ''
        ];
    }

    // Additional validation and allowed-host enforcement follows,
    // now applied consistently across redirects to prevent SSRF and DNS rebinding.
}
// Source: https://github.com/instantsoft/icms2/commit/04b8fe0eb75fc5f44eecb15684c7d3660586683d

Detection Methods for CVE-2026-48707

Indicators of Compromise

Outbound HTTP requests originating from the InstantCMS web server to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), or link-local (169.254.0.0/16) addresses.
Requests to cloud metadata endpoints such as 169.254.169.254 sourced from the web application process.
Application logs showing calls to uploadFromLink() with URLs pointing to external hosts that then trigger internal fetches.

Detection Strategies

Inspect web server egress traffic for HTTP redirect chains where the final destination is a private or loopback address.
Correlate authenticated user actions in InstantCMS with outbound network requests from the web tier.
Alert on any request from the CMS process to internal administrative ports (for example, 6379, 9200, 8500, 2375).

Monitoring Recommendations

Enable verbose logging on the reverse proxy or egress firewall in front of the InstantCMS host to capture all outbound URLs.
Baseline normal outbound destinations for the CMS and alert on deviations, particularly requests to private IP space.
Retain HTTP request logs for at least 90 days to support post-incident review of upload-from-URL activity.

How to Mitigate CVE-2026-48707

Immediate Actions Required

Upgrade InstantCMS to version 2.18.2 or later, which contains the fix in system/core/uploader.php.
Audit user accounts with permission to use the upload-from-URL feature and reduce privileges where the workflow is not required.
Review outbound proxy and firewall logs for prior requests from the CMS to internal IP ranges.

Patch Information

The fix is delivered in InstantCMS 2.18.2. See the GitHub commit 04b8fe0 and the GitHub Security Advisory GHSA-cm47-mwv3-f534 for full details. The patch also raises the minimum PHP version to 7.3.0.

Workarounds

Disable the upload-from-URL feature entirely if the deployment does not require it.
Route outbound traffic from the InstantCMS host through an egress proxy that blocks connections to RFC1918, loopback, and link-local addresses.
Restrict the allowed_remote_hosts configuration to a strict allowlist of trusted external domains for remote uploads.

bash

# Example iptables rules to block egress from the web server to private ranges
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8    -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 169.254.0.0/16 -j REJECT