CVE-2025-35939

What it actually does

Craft CMS improperly stores unauthenticated, user-controlled return URL parameters in PHP session files under a predictable local path such as `/var/lib/php/sessions/sess_[session_value]`. Because the session identifier is returned to the client in a `Set-Cookie` header, an attacker can know the resulting session filename and place arbitrary content into it. By itself, this is primarily session-file poisoning and arbitrary local file content injection; it becomes substantially more severe when chained with a separate local file inclusion, file read, template execution, or PHP include vulnerability that can access and execute the poisoned session file. Craft CMS 5.7.5 and 4.15.3 address the issue, and the upstream Git fix is commit `679b82edce8c60ce1008dc70740bf2610adac57d`.

Why it matters to the business

Public Craft CMS sites may be exposed to unauthenticated attacker-controlled data being written to server-side session files. If attackers can chain this with another flaw or misconfiguration, they may achieve code execution, web shell deployment, credential theft, site defacement, or disruption of web publishing operations. This vulnerability is listed in CISA KEV with active exploitation observed in the wild and a remediation due date of 2025-06-23, so it should be treated as urgent even though the standalone CVSS score is moderate and EPSS is relatively low.

How an attack unfolds

An attacker first sends an unauthenticated request to a Craft CMS URL that requires authentication, causing Craft CMS to redirect to the login page and create a server-side PHP session file. The attacker controls parts of the requested return URL or its parameters and embeds crafted content, potentially including PHP code or a later-stage marker. Craft CMS stores that value unsanitized in the PHP session file. The attacker then reads the `Set-Cookie` response to learn the session value and infer the server-side filename, typically under `/var/lib/php/sessions/sess_[session_value]`. To turn file poisoning into execution, the attacker must chain another weakness that causes the application or PHP runtime to include, evaluate, deserialize, or otherwise process that local session file. In active exploitation scenarios, defenders should assume attackers may be probing for such chains and looking for ways to pivot from poisoned sessions to command execution or persistent web access.

How to fix it

Upgrade Craft CMS to a fixed release immediately: use Craft CMS 5.7.5 or later for 5.x deployments and Craft CMS 4.15.3 or later for 4.x deployments. For source-based deployments, ensure the upstream fix commit `679b82edce8c60ce1008dc70740bf2610adac57d` or an equivalent vendor patch is present. After patching, restart PHP-FPM/Apache/Nginx workers as applicable and clear stale application/session caches where operationally safe. As defense in depth, restrict access to administrative routes, ensure PHP session directories are not web-accessible, prevent PHP execution from session/cache/upload directories, harden file permissions on `/var/lib/php/sessions`, and review the application for any local file inclusion or file-read primitives that could be chained with session poisoning.

How to confirm the fix worked

Confirm the installed Craft CMS version with package metadata, Composer, release artifacts, or the application control panel and verify it is 5.7.5, 4.15.3, or later. For Git deployments, verify that commit `679b82edce8c60ce1008dc70740bf2610adac57d` or an equivalent patch is included. In a non-production or controlled test environment, send an unauthenticated request to an authentication-protected route with a benign unique marker in the return URL parameter and confirm the marker is not stored unsanitized in the corresponding PHP session file. Review web server and application logs to ensure requests to protected routes still redirect correctly but do not persist raw attacker-supplied payloads. Validate that `/var/lib/php/sessions` is outside the web root, not directly retrievable over HTTP, and not configured for PHP execution.

Typical attack path

1. Identify an internet-facing Craft CMS instance and determine whether it is running an affected 4.x or 5.x version.
2. Request an authentication-protected Craft CMS route while supplying a crafted return URL or parameter value.
3. Receive a login redirect and capture the session cookie value from the `Set-Cookie` response header.
4. Infer the corresponding PHP session file path, commonly `/var/lib/php/sessions/sess_[session_value]`.
5. Repeat requests as needed to place attacker-controlled content into the server-side session file.
6. Attempt to chain the poisoned session file with a separate local file inclusion, PHP include, template execution, or file processing vulnerability.
7. If execution is achieved, run commands, deploy a web shell, steal secrets, or establish persistence.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse proxy logs, WAF logs, Craft CMS application logs, PHP-FPM logs, web server error logs, EDR telemetry, and filesystem artifacts. Focus on unauthenticated requests to protected or administrative Craft CMS routes that resulted in login redirects and session creation, especially when query strings contain encoded PHP tags, command-execution function names, PHP stream wrappers, base64-like blobs, or unusually long return URL values. Correlate `Set-Cookie` session values with files named `sess_*` under `/var/lib/php/sessions` and inspect session files modified around suspicious request times for PHP code, shell commands, serialized payloads, or attacker markers. Look for attempts to chain the poisoned session file with file inclusion or file read behavior, including references to `/var/lib/php/sessions/sess_`, `php://filter`, `data://`, `phar://`, or path traversal sequences. Investigate any child processes spawned by PHP or the web server, such as shells, download tools, scripting interpreters, or unexpected outbound network connections. Because active exploitation is reported, absence of a single known payload is not sufficient; prioritize behavioral indicators and session-file content review.

• /var/lib/php/sessions/sess_
• Set-Cookie: CraftSessionId=
• returnUrl=
• return=
• redirect=
• %3C%3Fphp
• <?php
• <?=`
• base64_decode(
• shell_exec(
• system(
• passthru(
• proc_open(
• popen(
• eval(
• assert(
• php://filter
• data://
• phar://
• ../var/lib/php/sessions
• ..%2Fvar%2Flib%2Fphp%2Fsessions
• /etc/passwd
• /bin/sh
• /bin/bash
• curl
• wget
• storage/logs/web.log
• storage/logs/phperrors.log

What your security team should do

• Prioritize patching all internet-facing Craft CMS instances because the issue is in CISA KEV and active exploitation has been reported.
• Upgrade to Craft CMS 5.7.5 or later, or 4.15.3 or later, and verify the upstream fix commit where applicable.
• Hunt for poisoned PHP session files containing PHP tags, command-execution functions, stream wrappers, encoded payloads, or unusually long return URL values.
• Correlate suspicious unauthenticated requests that receive login redirects with subsequent access attempts involving local file paths, PHP stream wrappers, or unusual application errors.
• Check for evidence of successful chaining, including web server child processes spawning shells, `curl`, `wget`, `python`, `perl`, or other interpreters.
• Restrict administrative and authentication-required Craft CMS routes behind VPN, SSO, IP allowlists, or WAF controls where feasible.
• Create WAF/SIEM detections for encoded PHP tags, PHP stream wrappers, and command-execution function names in query strings targeting Craft CMS routes.
• Review the environment for separate local file inclusion, arbitrary file read, template injection, or unsafe include behaviors that could make this flaw exploitable as code execution.