CVE-2026-18424 is a server-side request forgery in Concrete CMS 9.0.0 through 9.5.2, scored high (CVSS 3.1 7.1) in the record. A reused DNS check lets a low-privileged user who can import files make the server fetch internal addresses. Upgrade to the fixed release in the 9.5.3 notes.
What's affected
The record says Concrete CMS 9.0.0 to 9.5.2 is affected. Its only reference is the version history page ending in 953-release-notes, which points to a fix in 9.5.3. That page returned an error when we fetched it, so confirm the fixed version in the release notes directly.
The score differs by method. The record text states that the Concrete CMS team rated the issue 2.1 under CVSS 4.0, citing high attack complexity and a need for privileges. The CVSS 3.1 figure in the record is 7.1, with a changed scope and high confidentiality impact. Use both when you decide on urgency.
The record credits Ahmad Wicaksono for the report.
How to check if you're exposed
Check the Concrete CMS version in the dashboard. Anything from 9.0.0 through 9.5.2 is in scope.
Then look at who can use the remote file import feature in the file manager. The record says a low-privileged authenticated user who is permitted to import files is enough, so list the groups with that permission.
Also check what an application server can reach internally. If the web host can connect to loopback services, internal admin panels or a cloud metadata address, an SSRF flaw has something to find. Network egress rules and metadata service protections limit that.
What to do now
- Verify the Concrete CMS version on every site.
- Upgrade to the fixed version listed in the 9.5.3 release notes.
- Limit the remote file import permission to the smallest set of users.
- Block the web server from reaching cloud metadata and internal admin services unless it truly needs them.
- If your cloud provider offers a hardened metadata service mode, turn it on.
- Review the file manager for imported files that you do not recognize.
Why it matters
The weakness class is CWE-918, server-side request forgery. The application checks that a URL resolves to a public address, then downloads it later. The record explains that when several URLs share the same host, only the first validated result was kept and reused. A DNS record that answers with a public address during the check and a private one during the download can bypass the check.
The result is that the server fetches internal-only resources and stores the response in the file manager, where the importing user can read it. The practical lesson is that validating a hostname once is not the same as controlling the connection. The dependable pattern is to pin the validated address for the actual connection. No exploitation is recorded and KEV is false.
Quick check
What can an SSRF flaw reach?
Anything the server can reach that the attacker cannot, such as loopback services, internal admin panels and cloud metadata endpoints, as the record lists.
Do I need to be logged in to exploit it?
Yes, a low-privileged authenticated user with permission to import files.
Sources
Last reviewed: 18 October 2026.
