CVE-2026-41130: craftcms cms · Server-Side Request Forgery (SSRF)
Affects craftcms cmsSource CVE Database V5
Public exploit available · CVSS 5.5 Medium : upgrade to 5.9.15 or 4.17.9 as a priority.
Data as of 30 Oct 2026, 11:52 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 25% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 5.9.15, 4.17.9
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:PExploitation evidence
Disclosed: evidence found.
CVE published 21 Apr 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
CVSS exploit maturity: proof of concept public
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), CVSS vector, the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade cms and craftcms/cms to 5.9.15 or 4.17.9.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| craftcmscms | Affected
| Fixed in
|
| craftcmscms | Affected
| Fixed in
|
GitHubcraftcms/cmspkg:github/craftcms/cmsOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A fix is available in Craft CMS versions 4.17.9 and 5.9.15. Users should upgrade to these or later versions to remediate the vulnerability. If upgrading is not immediately possible, explicitly restricting the trustedHosts configuration to trusted domains can mitigate the risk by preventing the server from trusting arbitrary Host headers.
Description
Craft CMS versions 4.x through 4.17.8 and 5.x through 5.9.14 contain a Server-Side Request Forgery (SSRF) vulnerability in the resource-js endpoint. This vulnerability arises when the trustedHosts configuration is not explicitly restricted, allowing the application to trust a client-supplied Host header. An attacker can exploit this to control the baseUrl used in prefix validation, causing the server to make arbitrary HTTP requests. Versions 4.