CVE-2026-18424 in Concrete CMS
Summary
by MITRE • 09/15/2026
Concrete CMS 9.0.0 to 9.5.2 is vulnerable to Server-Side Request Forgery iremote file import via cross-port reuse of a host's validated DNS pin. When multiple remote URLs share the same host, only the first `ValidatedRemoteUrl` is retained and reused for every later URL with that host. A low-privileged authenticated user permitted to import files could therefore supply a DNS-rebinding host that resolved to a public address during validation and to a private or loopback address during the unpinned download, causing the server to fetch internal-only resources such as loopback services, internal admin panels, or cloud metadata endpoints and to save the responses into the file manager. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Thanks Ahmad Wicaksono (sonix03) for reporting.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
Concrete CMS versions 9.0.0 through 9.5.2 contain a critical Server-Side Request Forgery vulnerability that arises from an improper implementation of DNS pinning and connection reuse mechanisms within the remote file import functionality. The core technical flaw lies in how the application manages validated remote URLs. When multiple requests target different paths or resources on the same hostname, the system retains only the first ValidatedRemoteUrl associated with that host and reuses it for all subsequent downloads involving that domain. This design decision fails to account for DNS rebinding attacks, where a single hostname can resolve to different IP addresses at different times due to Time-to-Live expiration or dynamic configuration changes by an attacker-controlled DNS server.
The operational impact of this vulnerability is significant because it allows low-privileged authenticated users to bypass network-level security controls intended to restrict access to internal resources. An attacker with valid credentials and permission to import files can supply a maliciously controlled domain name that initially resolves to a public IP address, thereby passing the initial validation check performed by Concrete CMS. However, during the actual download phase, the DNS record for that same hostname is manipulated or expires such that it resolves to an internal private IP address or loopback interface. Because the application reuses the previously validated connection context without re-verifying the current destination IP against its security policies, it proceeds to fetch data from sensitive internal services.
This mechanism effectively circumvents firewalls and network segmentation strategies by leveraging the trust established during the initial validation phase. The attacker can target a variety of internal endpoints that are typically inaccessible from external networks or untrusted zones. Common targets include local administrative panels running on loopback interfaces, cloud metadata endpoints such as AWS Instance Metadata Service which often contain sensitive credentials and configuration data, and other internal microservices or databases exposed only to the application server's network interface. The fetched content is then saved directly into the CMS file manager, providing the attacker with a persistent foothold and access to potentially critical organizational assets.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically involving DNS rebinding techniques that exploit timing differences between validation and execution phases. It also relates to CWE-20 Improper Input Validation regarding the failure to re-validate network destinations during multi-step processes. In terms of offensive security frameworks, this attack vector corresponds to ATT&CK technique T1557 Adversary-in-the-Middle or more specifically T1648 Supply Chain Compromise if used to exfiltrate data from internal systems that feed into broader infrastructure monitoring tools. The low CVSS v4.0 score of 2.1 reflects the high complexity and requirement for authentication, but does not diminish the severity of potential data exposure in environments where SSRF can lead to lateral movement or credential theft.
Mitigation strategies should focus on enforcing strict DNS validation at every step of the request lifecycle rather than caching validated states across multiple operations. Implementing IP address verification during both the initial check and the actual download phase would prevent redirection to internal addresses after a successful initial handshake. Additionally, restricting outbound connections from the web server application to only explicitly whitelisted domains or IPs can limit the blast radius of such vulnerabilities. Organizations running affected versions should immediately update Concrete CMS to version 9.5.3 or later where this logic has been corrected to ensure that each request undergoes independent validation against current DNS resolutions and security policies, thereby closing the window for DNS rebinding exploitation.