CVE-2025-35939 is an external control of assumed-immutable web parameter vulnerability in Craft CMS Craft CMS. CISA added it to the Known Exploited Vulnerabilities catalogue on 2 June 2025, which means attackers have used it in real attacks. Craft CMS contains an external control of assumed-immutable web parameter vulnerability. This vulnerability could be chained with CVE-2024-58136 as represented by CVE-2025-32432.
What this vulnerability means in a CMS
An external control of assumed-immutable web parameter issue means the application trusts a request value it should have treated as fixed or server-controlled. In a CMS, that can turn ordinary request handling into a security boundary failure because a single manipulated parameter may alter workflow decisions, content handling, or administrative behaviour.
For a web platform, the danger is not the parameter alone, but the assumption around it. Once a value meant to be immutable can be influenced externally, the application may follow an unintended path that was never meant to be reachable by a user. That is why this class belongs in web application attack analysis rather than simple input validation only.
Why it is dangerous when exploited
This vulnerability class is dangerous because it can undermine server-side trust decisions without needing obvious code execution at the outset. Attackers often look for parameters that influence permissions, object selection, redirects, templating, or request routing, then modify them to reach functionality the application assumed was not user-controllable.
In the case of CVE-2025-35939, the page notes that it could be chained with CVE-2024-58136 as represented by CVE-2025-32432. That matters because chained flaws often convert a narrow input-control issue into a more serious compromise path, especially when the first weakness helps the attacker reach a second, higher-impact condition.
For a broader view of how parameter tampering and related web flaws become real attack paths, see Web Application Attacks Guide.
How organisations assess exposure and limit blast radius
Exposure review starts with confirming where Craft CMS is deployed, whether the instance is internet-facing, and whether the vulnerable feature is reachable from untrusted users. Teams should also review vendor advisories and the CISA Known Exploited Vulnerabilities catalogue because this CVE has already been used in real attacks, which raises the priority above theoretical risk.
Where patching is delayed, compensating controls should focus on reducing reachability and limiting the impact of any successful request manipulation. That usually means tightening access paths, restricting administration surfaces, reducing exposure of the affected endpoint, and watching for suspicious request patterns that target parameters the application should have controlled internally.
For the operational side of finding and prioritising exposure, the Vulnerability Management Guide is the most directly relevant internal reference, because it covers asset scoping, KEV-driven prioritisation, and remediation verification.
Detection, remediation, and post-patch review
Detection should look for unusual parameter values, unexpected transitions in application state, and requests that appear to override values the server normally sets. If exploitation is suspected, review web logs, application logs, and any downstream changes that could show the manipulated parameter influenced permissions, content, or execution flow.
Remediation should follow the vendor advisory for the correct version details and apply the fix as soon as change windows allow. After patching, review whether the vulnerability was exploited before remediation, because exploit success may leave behind altered configuration, injected content, new administrator access, or other persistence mechanisms that survive the software fix.
Because this kind of flaw sits in the same family as broader request manipulation techniques, the CVE Program and the NIST National Vulnerability Database are the right places to verify the authoritative record and track downstream references.
Risk and Threat Considerations
This vulnerability matters because externally controlled request data can let an attacker steer application logic that was assumed to be safe, fixed, or server-derived. In a CMS, that can become a path to privilege abuse, content manipulation, or a foothold for chaining into a broader compromise.
Failure mechanism: The attacker supplies or alters a request parameter that the application treats as immutable, then the CMS uses that value in a trust-sensitive decision path instead of ignoring or normalising it.
Impact: The result can be unauthorized state changes, exposure of protected functionality, or a chained compromise that survives simple request filtering if the application logic itself remains vulnerable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | CVE-2025-35939 can bypass intended request-side trust and access decisions. |
| V15 — Secure Coding and Architecture | The flaw arises from unsafe trust in request parameters and broken application logic. | |
| Recommendation — Enforce server-side authorization checks on every state-changing request. Remove client trust assumptions from application logic and validate server-controlled state. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is caused by accepting attacker-controlled input as if it were immutable. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Exploitation review depends on analysing logs for manipulated requests and follow-on actions. | |
| Recommendation — Validate and constrain request parameters before they affect sensitive logic. Review logs for suspicious parameter manipulation and post-exploit activity. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The vulnerability is an application-layer trust failure in a web CMS. |
| Recommendation — Test web application trust boundaries and remediate insecure parameter handling. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a logic-integrity issue, not just a malformed-input problem. If your CMS or adjacent web code relies on client-supplied values for hidden trust decisions, the safest assumption is that an attacker will try to rewrite them.
What to watch for: Look for parameters that are expected to remain fixed across a request flow, especially when they influence object selection, authorisation, or workflow state. Those are the places where a small request tweak can have disproportionate impact.
Practitioner takeaway: Validate the trust model around every security-sensitive parameter, then verify post-patch that no exploit path, chain condition, or persistence artefact remains in place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org