Scope. This post is based on the CVE record published by Wordfence (the CNA), the CISA KEV entry and CISA’s SSVC assessment, the WordPress 7.1.4 release notes, and a diff we ran of the WordPress 7.1.3 and 7.1.4 source files. The exploitation telemetry is Wordfence’s, as reported by The Hacker News. We did not reproduce the attack.

What the vulnerability is

The CVE record’s description says: “WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.”

The attack complexity is High for a reason: the attacker has to hit files that exist only while a core update runs. According to The Hacker News’s summary of Wordfence’s analysis, exploitation needs a full-package update that includes the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time before WordPress deletes the temporary files. The same report says attackers have been repeatedly polling paths such as setup-config.php.

“Automatable: no” in the SSVC entry does not make this low priority. It reflects the narrow timing window, not the impact. Combined with active exploitation and total technical impact, it still puts the CVE near the top of a queue; our SSVC guide shows how your own mission and exposure values turn those three into a decision, and every public WordPress site is internet-facing.

Fixed versions

WordPress released 7.1.4 on 28 October 2026 and says: “Because this is a security release, it is recommended that you update your sites immediately.” The release fixes this issue (“A race condition during core updates that could lead to remote code execution reported by Umut Bayram”) along with 21 other listed items.

The CVE record lists 25 affected branches, each with an inclusive upper limit (lessThanOrEqual). We checked each against the backport list in the release notes; in every branch the fixed release is the next point release.

WordPress adds that backports are “a courtesy” and that “only the most recent version of WordPress is actively supported.” Sites on 4.6 or earlier get no fix at all.

What changed in 7.1.4

We fetched wp-admin/includes/class-wp-upgrader.php and wp-admin/includes/update-core.php from the 7.1.3 and 7.1.4 tags of the WordPress/WordPress GitHub mirror and diffed them. Three changes stand out.

1. The staging folder name becomes unguessable. In 7.1.3, unpack_package() names the working directory after the downloaded package file: $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' ), inside wp-content/upgrade/. In 7.1.4 a new get_working_dir_name() appends '-' . wp_generate_password( 16, false ).
2. The upgrade folder can no longer be listed. 7.1.3 deletes everything in wp-content/upgrade/ before unpacking. 7.1.4 skips index.php during that cleanup and writes one if missing, with a comment that the directory “is web-served” and must not be listed “so the name of the working directory created below cannot be discovered from a directory index.”
3. A staged wp-config.php is never copied into the live site. update_core() in 7.1.4 adds wp-config.php to the list of files it skips when copying the new release over the old one, with the comment “Never copy a wp-config.php, which could have been written to the working directory.”

Read together, the fix closes both halves of the race: finding the staged copy, and turning a file written into it into something that persists after the update. That is our reading of the diff; the CNA’s own advisory is the authority on the exploit chain.

Why the update itself is the risky moment

The vulnerable step runs in the code that is already installed. When WordPress updates core, Core_Upgrader::upgrade() calls unpack_package() from the running version’s WP_Upgrader class, and only then copies the new release’s update-core.php into place and runs it. So updating a 7.1.3 site to 7.1.4 stages the 7.1.4 package with the 7.1.3 naming and cleanup logic. The new wp-config.php skip does apply during that update, because it lives in the new update-core.php, but the staging folder is still predictable and listable for that one run.

Two practical consequences:

• Block the staging path before you update, not after. A web server rule that refuses every request under /wp-content/upgrade/ removes the public half of the race. WordPress writes to that folder through the filesystem, not over HTTP, so it should not need web access to it.
• Do not rely on a rule file inside wp-content/upgrade/. Affected versions delete everything in that folder before unpacking, so a .htaccess placed there is gone when it matters.

Illustrative configuration (we did not test these against a live site; adapt paths for subdirectory installs):

# nginx, inside the WordPress server block
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache, in the site's root .htaccess or vhost (mod_alias)
RedirectMatch 403 ^/wp-content/upgrade/

Also check whether automatic updates already did the work. In 7.1.4’s Core_Upgrader::should_update_to_version(), the minor auto-update setting reads get_site_option( 'auto_update_core_minor', 'enabled' ), so minor (security) releases install automatically unless the WP_AUTO_UPDATE_CORE constant, a filter or that option turns them off. Many sites will have moved to their branch’s fix on their own; managed hosts and fleets that disable auto-updates will not have.

What to do this week

1. Inventory versions. On each site, wp core version (WP-CLI) or wp-includes/version.php gives $wp_version. Anything at or below its branch’s “last affected” row above needs the update. Anything on 4.6 or earlier needs a migration plan.
2. Block /wp-content/upgrade/ at the web server, reload, and confirm with a request that it returns 403.
3. Update to 7.1.4, or to your branch’s fixed release if you cannot move to 7.1 yet.
4. Check for leftovers. CISA marks this entry for forensic triage. At minimum:

# Run from the WordPress root. Illustrative; adapt the log path.
wp core verify-checksums                 # core files that differ from the release
ls -la wp-content/upgrade/               # should be empty apart from index.php after 7.1.4
find . -name 'wp-config.php' -not -path './wp-config.php'   # unexpected copies
grep -E '/wp-content/upgrade/' /var/log/nginx/access.log* | grep -v ' 403 '

Requests to /wp-content/upgrade/.../setup-config.php or install.php that did not get a 403, especially close to the time of a core update, are the lead to follow. Look for PHP files that verify-checksums does not explain, new administrator accounts, and changes to wp-config.php since the update.

5. Record the decision. If you track patch decisions as tickets, this is a KEV entry with active exploitation and total technical impact on internet-facing hosts; our vulnerability prioritization workflow shows how to carry those signals into the ticket, and the KEV JSON feed guide explains the dueDate and forensicTriage fields.

Limits of this article

• We did not reproduce exploitation. The preconditions and the 62,969-attack figure come from Wordfence via The Hacker News; we could not retrieve Wordfence’s own advisory page in this run.
• Which update package a given site downloads (full, no-content or partial) depends on what the WordPress update API offers it; we did not test which update paths stage the installer files.
• The web server rules are illustrative and untested; test them on a staging site first.

Sources and verification

CVE-2026-48356 is the Magento file-upload flaw that Sansec calls PolyShell, and it is now on CISA’s Known Exploited Vulnerabilities catalog (added October 27, 2026; federal due date November 10). Adobe shipped the fix in APSB26-73 on July 14, 2026. If your store is not on a 2026-jul build, update now. If it was exposed for any time since March, hunt as well. Attackers have used the flaw to plant webshells and to inject JavaScript loaders into CMS blocks, and an update removes neither.

What is affected and what fixes it

The table comes from Adobe’s CVE record and the APSB26-73 solution table, which agree on the fixed builds.

Two details matter here.

2.4.9 is listed as affected. Sansec’s PolyShell write-up says Adobe released the fix in 2.4.9 on May 12, 2026, and backported it to the supported release lines through APSB26-73 on July 14. Adobe’s CVE record, however, lists 2.4.9 among the affected versions and 2.4.9-2026-jul as unaffected. We have not diffed the two releases, so we can’t say which is right. The safe reading is Adobe’s: move to 2.4.9-2026-jul.

Older Open Source lines are not listed at all. Adobe lists 2.4.4 and 2.4.5 2026-jul builds only for Adobe Commerce. For Magento Open Source 2.4.5 and older, the record names neither an affected nor a fixed version. Don’t read that as safe: Sansec says every version up to 2.4.9-alpha2 is affected. If you run one of those lines, plan an upgrade and treat the server-side mitigations below as essential in the meantime.

Check what you run with bin/magento --version or composer show magento/product-community-edition (magento/product-enterprise-edition for Commerce), and compare the result with the table.

How PolyShell works

Sansec describes the flaw in the REST API’s handling of file uploads for cart item custom options, where a product option has type “file”. The most exposed routes are the unauthenticated guest-cart ones:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Uploaded files are written to pub/media/custom_options/quote/. Sansec says the GraphQL mutations use a different code path and are not vulnerable.

What an upload leads to depends on the server. Sansec lists code execution through an uploaded PHP file for Apache before 2.3.5 without php_flag engine 0, for stock nginx configs on 2.0.0 to 2.2.x, and for any nginx config that passes every .php request to PHP-FPM. Stored XSS is possible on versions before 2.3.5 and on custom web server configurations.

Adobe describes the same CVE differently. The CVE record says exploitation “requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page” and scores it CVSS 3.1 9.3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N). The regional copy of the bulletin we read shows 9.6 with A:L and labels the impact “Privilege escalation”. We report both; neither changes the action. A KEV listing outranks the UI:R in the vector. Our CVSS vs EPSS vs KEV guide explains why.

What attackers have done with it

Sansec reported a mass wave on March 30, 2026: 471 stores compromised in one hour, with a backdoor named accesson.php dropped across multiple directories and loaders injected into CMS pages and static blocks. That was months before Adobe’s July backport.

On October 26, The Hacker News reported Sansec’s findings on a longer campaign: 953 stores infected since July 2025 with a JavaScript loader stored in Magento’s cms_block table. Per that report, Sansec attributes 471 of those infections to CVE-2026-48356, and about 102 more to file uploads through PolyShell or CVE-2025-54236 (SessionReaper). One store on 2.4.7-p10 with no missing core patches was compromised through a rogue administrator account. The report also describes webshells disguised as PNG files in pub/media/custom_options/quote/. The loader’s final payload is not known.

These figures are Sansec’s, as reported by The Hacker News. CISA’s catalog entry does not say who is exploiting the flaw, and lists known ransomware use as “Unknown”.

Step 1: Install the fixed build

Update to the 2026-jul build for your release line, then redeploy static content and clear caches as your normal release process requires. If you can’t update this week, do steps 2 and 3 now anyway: they limit what a successful upload can do and tell you whether one has already happened.

Sansec suggests a WAF rule that blocks the vulnerable API calls. That buys time, but it is a mitigation, not a fix.

Step 2: Make sure uploads can’t be served or executed

Magento ships deny rules for this directory. Check that your live config still has them.

nginx. The stock nginx.conf.sample in the 2.4-develop branch denies the directory and only hands named entry points to PHP. These are excerpts from that file, not a complete config:

location /media/custom_options/ {
    deny all;
}

location ~ ^/(index|get|static|errors/report|errors/404|errors/503|health_check)\.php$ {
    # ... fastcgi_pass to PHP-FPM ...
}

# Banned locations (only reached if the earlier PHP entry point regexes don't match)
location ~* (\.php$|\.phtml$|\.htaccess$|\.htpasswd$|\.git) {
    deny all;
}

The risky pattern is a hand-written or hosting-panel config with a generic location ~ \.php$ { fastcgi_pass ...; } and no deny for /media/custom_options/. With that, a PHP file uploaded to the directory is executed. Sansec recommends a deny all location for custom_options placed before any \.php$ block.

Apache. The repository ships pub/media/custom_options/.htaccess containing Require all denied (Apache 2.4) or deny from all (older). Confirm it exists on disk and that AllowOverride lets Apache read it. Sansec also recommends php_flag engine 0 there.

Neither rule stops the upload. Both stop the uploaded file from being fetched or run through the web server.

Step 3: Hunt for an existing compromise

Run these from the Magento root, or adjust the paths. Sansec published the first checks; we added the database queries.

Files in the upload directory. Customer uploads can be legitimate, but any script file there is a strong sign of compromise:

# Everything uploaded through custom options, newest first
find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n' | sort -r | head -50

# Script extensions there are a red flag
find pub/media/custom_options/ -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \)

# The backdoor name from the March wave, anywhere in the docroot tree
find /var/www -name 'accesson.php' -type f

The October report describes webshells disguised as .png. A PNG that starts with <?php is not an image. Check with file or head -c 64 on anything recent in that directory.

Injected scripts in CMS content. The loader lives in the database, so file scans miss it. Run this against a replica or read-only connection (add your table prefix if you use one):

SELECT 'block' AS kind, block_id AS id, identifier, update_time
FROM cms_block
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
UNION ALL
SELECT 'page', page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%<script%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%lanhd6549tdhse%'
ORDER BY update_time DESC;

Column names come from Magento’s Cms module schema; we checked the query’s syntax against a small SQLite copy of those tables, not against a live MySQL store. Many stores have legitimate scripts in CMS blocks, so review hits by update_time and by where the script loads from. The October report lists these loader domains: manulfie[.]click, neswnsssn[.]click, lanhd6549tdhse[.]top, additionalver[.]com and deepveindrilling[.]com. Sansec’s March write-up adds jslibrary[.]net and canevaslab[.]com. Add any you want to the LIKE list.

Admin accounts you didn’t create. One store in the October report was compromised through a rogue admin:

SELECT user_id, username, email, created, logdate, is_active
FROM admin_user
WHERE created >= '2026-03-01'
ORDER BY created DESC;

Web logs. Look for requests to the guest-cart item routes, which usually sit under /rest/V1/ or /rest/<store_code>/V1/:

grep -E '"(POST|PUT) /rest/([a-z0-9_]+/)?V1/guest-carts/[^/ ]+/items' /var/log/nginx/access.log* | head

Headless storefronts call these routes legitimately, so a hit is not proof. Line up timestamps with new files in pub/media/custom_options/quote/ and with cms_block updates.

If you find a webshell or an injected loader, treat the store as compromised. Remove the artifacts, rotate admin, database and integration credentials, check for other persistence (cron, other PHP files, modified app/etc/env.php), and consider your payment-card obligations, since these loaders run in shoppers’ browsers. Our PHP2Shell response guide covers the server-side hunt for PHP webshells in more detail.

Hardening after the patch

• Keep pub/ as the document root and let PHP run only for Magento’s named entry points. Sansec’s RCE conditions are old releases or web server configs that execute PHP files in upload directories.
• Turn off PHP execution in every writable media directory, not just this one. Our php.ini hardening guide covers related settings.
• If you don’t use file-type custom options, Sansec’s WAF suggestion is cheap: block file uploads to the guest-cart item routes.
• Monitor cms_block and cms_page for changes. A loader injected through the database survives code deploys.

Limits of this article

We did not reproduce the exploit or diff the patched releases. Affected and fixed versions come from Adobe’s CVE record and bulletin. The upload mechanics, server conditions and campaign figures come from Sansec, the latter through The Hacker News. The adobe.com/trust copy of APSB26-73 could not be retrieved during research; we used Adobe’s regional helpx copy, which shows “Last updated on 14 July 2026” and may not reflect later revisions. We ran the find and grep commands against a mock directory tree and sample log lines, and the SQL against SQLite, not against a production store.

Sources and verification

To stop session fixation in PHP, call session_regenerate_id(), or the timestamp-based rotation shown below, whenever a user’s privilege changes. Do it before you store the authenticated user in $_SESSION. Don’t destroy the old session on the spot. Mark it with a timestamp and refuse it after a short grace period, and enforce your own idle and absolute timeouts, because PHP’s garbage collector is not a timeout. That is what PHP’s own manual asks for. Below is a helper that follows it, tested against a fixation attack, plus the one shortcut in the manual’s example that brings the attack back if you use it at login.

Every behaviour here was run on PHP 8.3.6 CLI with the built-in web server (php -S) and curl, using the default files save handler. The cookie flags and php.ini settings that go with this code are covered in our php.ini security hardening guide. This article is about the session lifecycle in your application code.

The attack strict mode doesn’t stop

session.use_strict_mode=1 makes PHP reject a session ID it never issued. That stops an attacker inventing an ID such as PHPSESSID=123456. But the PHP manual is explicit about the gap: “an attacker can force users to use an initialized session ID which has been created by an attacker.” The attacker visits your site, receives a real ID, and plants it in the victim’s browser. The manual describes two routes: setting a cookie that the browser’s precedence rules let override yours (for example from another subdomain), and JavaScript injection. If your login code keeps that ID, the attacker now holds an authenticated session.

We reproduced it with a minimal app whose login does only $_SESSION['uid'] = 42;, run with strict mode on:

$ PHPFLAGS="-d session.use_strict_mode=1" ./test.sh naive 8090
attacker ID: pmq468mni64u18nhukmh7vqe1v
logged in
ID after login: unchanged
attacker replays old ID: account page for uid 42

The test script fetches / to get a real ID, sends /login with that ID as the victim, then replays the ID as the attacker.

What PHP’s manual requires

The session security chapter is unusually prescriptive. The rules that matter for application code:

• Rotate on privilege change, before writing auth state. “Session IDs must be regenerated when user privileges are elevated, such as after authenticating. session_regenerate_id must be called prior to setting the authentication information to $_SESSION.” Rotate again on any later privilege change, such as entering an admin area or completing step-up authentication. The OWASP Session Management Cheat Sheet makes the same point: renew the ID “after any privilege level change”.
• Don’t delete active sessions immediately. “session_regenerate_id(true); and session_destroy must never be called together for an active session.” Deleting right away loses sessions when requests overlap or the new cookie never arrives. It also removes your chance to notice that someone used an old ID.
• Use timestamps instead. Set “a short-term expiration time (timestamp) in $_SESSION” on the old session and refuse it later: “a few seconds later for stable networks… and a few minutes later for unstable networks such as cell phones or Wi-Fi.”
• Don’t rely on session.gc_maxlifetime for expiry. “Attackers may access a victim’s session ID periodically to prevent its expiration and keep exploiting it.” The setting only controls when data “will be seen as ‘garbage’ and potentially cleaned up” (default 1440 seconds).
• Treat obsolete-ID access as a signal. When an expired ID is used, the manual recommends removing “authenticated status from all of the user’s sessions” and forcing re-authentication.

The session_regenerate_id() page has two example implementations. Both are labelled “not fully working code, but an example!”

A tested rotation helper

session_guard.php follows the manual’s pattern, with two corrections we found in testing (explained after the code). It targets PHP 8.1 or later (session_create_id() exists from 7.1, and the cookie-options array for setcookie() from 7.3).

<?php
// session_guard.php: timestamp-based session ID rotation, adapted from the
// pattern in the PHP manual's session_regenerate_id() page.
declare(strict_types=1);

defined('SESSION_GRACE')    || define('SESSION_GRACE', 60);     // old ID usable after rotation (s)
defined('SESSION_IDLE')     || define('SESSION_IDLE', 1800);    // idle timeout (s)
defined('SESSION_ABSOLUTE') || define('SESSION_ABSOLUTE', 28800); // absolute timeout (s)
defined('SESSION_ROTATE')   || define('SESSION_ROTATE', 900);   // periodic rotation (s)

final class ObsoleteSessionAccess extends RuntimeException {}

function secure_session_start(): void
{
    ini_set('session.use_strict_mode', '1');
    session_start();
    $now = time();

    // 1. Old ID after rotation: allow a short grace period, then refuse.
    if (isset($_SESSION['destroyed'])) {
        if ($_SESSION['destroyed'] < $now - SESSION_GRACE) {
            throw new ObsoleteSessionAccess('obsolete session ID used');
        }
        if (isset($_SESSION['new_session_id'])) {
            // Cookie for the new ID was probably lost: move the client over.
            session_commit();
            session_id($_SESSION['new_session_id']);
            session_start();
            return;
        }
    }

    // 2. Idle and absolute timeouts, enforced in application code.
    if (isset($_SESSION['uid'])) {
        if ($now - ($_SESSION['last_seen'] ?? 0) > SESSION_IDLE
            || $now - ($_SESSION['created'] ?? 0) > SESSION_ABSOLUTE) {
            secure_logout();
            session_start();
            return;
        }
        $_SESSION['last_seen'] = $now;
        if ($now - ($_SESSION['rotated'] ?? 0) > SESSION_ROTATE) {
            secure_regenerate(true);
        }
    }
}

// $forward: let a client still holding the old ID be moved to the new one
// during the grace period (lost Set-Cookie on a flaky network). Never forward
// on a privilege change: whoever holds the old ID would be handed the new one.
function secure_regenerate(bool $forward): void
{
    $data = $_SESSION;                      // session_start() below loads an empty session
    $new = session_create_id();
    if ($forward) {
        $_SESSION['new_session_id'] = $new;
    }
    $_SESSION['destroyed'] = time();
    session_commit();                       // old session keeps the markers

    session_id($new);
    ini_set('session.use_strict_mode', '0'); // let session_start() accept $new
    session_start();
    ini_set('session.use_strict_mode', '1');
    $_SESSION = $data;
    $_SESSION['rotated'] = time();
}

function secure_login(int $uid): void
{
    secure_regenerate(false);               // rotate BEFORE marking authenticated
    $_SESSION['uid'] = $uid;
    $_SESSION['created'] = $_SESSION['last_seen'] = time();
}

function secure_logout(): void
{
    $_SESSION = [];
    $p = session_get_cookie_params();
    setcookie(session_name(), '', [
        'expires' => time() - 3600, 'path' => $p['path'], 'domain' => $p['domain'],
        'secure' => $p['secure'], 'httponly' => $p['httponly'], 'samesite' => $p['samesite'] ?: 'Lax',
    ]);
    session_destroy();
}

Wire it in by calling secure_session_start() instead of session_start(), secure_login($userId) after you have verified the password and any second factor, and secure_logout() from your logout handler. On ObsoleteSessionAccess, return 401 and log the event.

What we tested

Against the same attack, with the helper in place:

$ ./test.sh guard 8086
attacker ID: jt6upaht8b1i3hcuuk743hivm5
logged in
ID after login: 24qohqtgd4trsgfuov1tjn20nm
attacker replays old ID: anonymous

Periodic rotation, with rotation forced on every request and a 2-second grace period:

$ ./test2.sh
account page for uid 42
login ID 10d0f50p49pto2ocoffotrbsv3 rotated to r4428iae8369vin9533ubpb292
old ID inside grace: account page for uid 42
old ID after grace:  401 obsolete session
logout with current ID: logged out
current ID after logout: anonymous

With a 1-second idle timeout, a request made 3 seconds after login came back anonymous with a new session cookie, and the logged-in session’s file was gone from session.save_path. The pre-login session stayed on disk, marked as destroyed, until garbage collection, as the manual intends.

Correction 1: never forward an old ID after login

The manual’s second example deals with lost cookies: if the old ID comes back during the grace period, it switches the client to the new ID it stored in the old session. That is reasonable for periodic rotation, where the person holding the old ID is almost always the legitimate user. At login it is a hole. The attacker holds the old, pre-login ID, so forwarding hands them the new, authenticated one.

Our first draft forwarded in both cases, and the fixation test failed: the attacker’s replay returned account page for uid 42. The manual hints at this in a comment (“Do not try to set session ID again if you would like to remove authentication flag”). The helper makes it explicit: secure_regenerate(false) at login, secure_regenerate(true) only for timed rotation. The trade-off is that a user whose login response is lost has to log in again.

Correction 2: carry the session data across

In the manual’s example, the new session is started with session_id($new); session_start();. In our test on PHP 8.3.6, that started an empty $_SESSION: the authenticated user vanished on the first periodic rotation. The helper copies the data before committing the old session and restores it after starting the new one. At login this also keeps pre-login state, such as a cart.

Other session rules worth enforcing

• Timeouts. OWASP gives common idle timeouts of “2-5 minutes for high-value applications and 15-30 minutes for low risk applications”. Every session should also have an absolute timeout “regardless of session activity”. The helper’s defaults (30 minutes idle, 8 hours absolute) are examples; set your own.
• Locking. PHP locks session data per request, which attackers can abuse to tie up workers. The manual suggests session_start(['read_and_close' => true]) for requests that only read the session, and session_commit() as soon as you have finished writing.
• Remember-me is not a long session. The manual says not to “use long life session IDs for auto-login”. Use a separate, single-use random token in its own cookie, and replace it each time it is used.
• Track active sessions if you need “log out everywhere” or the manual’s response to obsolete-ID access. PHP doesn’t do this for you. The manual suggests a user-ID-prefixed ID from session_create_id(), which “is vital” to pair with strict mode. Don’t use a confidential value as the prefix.
• Sessions don’t stop CSRF. “Sessions and authentication do not protect against CSRF attacks.” See our CSRF defences comparison.
• Session files are an attack surface. October’s PHP2Shell attempts tried to plant code through session files. See the PHP2Shell patch-and-hunt guide.

Common mistakes

Limits of this article

The helper is a tested example, not a drop-in library. It assumes PHP’s default files handler. A custom or Redis save handler must implement session ID validation for strict mode to work, as the manual notes for user-defined handlers. It does not implement the cross-session “remove authentication from all of the user’s sessions” response, which needs an active-session registry. If you use a framework, prefer its session layer to this helper, and check that it rotates the ID at login and enforces timeouts. Our tests ran on a single PHP process. We did not load-test concurrent requests during rotation.

Sources and verification

To harden PHP for production, start from php.ini-production, then change six settings it leaves permissive: turn off expose_php, turn on session.use_strict_mode, set the session cookie’s HttpOnly, Secure and SameSite flags, and turn off allow_url_fopen if your code never reads URLs as files. Apply them in php.ini or with php_admin_value in the PHP-FPM pool so applications cannot undo them, and do not treat disable_functions or open_basedir as a sandbox.

Everything below was checked against PHP 8.4.27’s php.ini-production and the PHP manual, and every behaviour we describe was run on PHP 8.3 CLI (Ubuntu 24.04 package). Where a setting behaves differently under PHP-FPM or Apache, we say so.

The baseline

“Built-in default” is what PHP uses with no php.ini at all (php -n). Bold marks the six settings where the production template differs from the hardened value. We measured both columns with the audit script at the end of this article.

Where to set them so they stick

PHP settings come from several layers, and the later ones can override the earlier ones for directives that allow it: php.ini and its scan directory, web server or FPM pool configuration, .user.ini files in the document root, and ini_set() in code. Each directive has a changeable mode. INI_SYSTEM settings such as disable_functions, allow_url_fopen and allow_url_include can only be set in php.ini or server configuration.

For PHP-FPM, use php_admin_value and php_admin_flag for anything security-relevant. The PHP-FPM documentation says: “Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set.” Plain php_value and php_flag can be.

; /etc/php/8.3/fpm/pool.d/app.conf (path varies by distribution)
[app]
user = app
group = app
listen = /run/php/app.sock

php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php/app-error.log
php_admin_flag[allow_url_fopen] = off
php_admin_value[session.use_strict_mode] = 1
php_admin_value[session.cookie_httponly] = 1
php_admin_value[session.cookie_secure] = 1
php_admin_value[session.cookie_samesite] = Lax

; Only execute .php files (the default also allows .phar)
security.limit_extensions = .php

This is illustrative: we validated the directive names and values against the PHP-FPM documentation and our CLI tests, but did not run this pool file. Restart the pool after editing. For Apache with mod_php, the equivalent is php_admin_value and php_admin_flag in the virtual host.

You can see runtime locking in action. With disable_functions set in configuration, ini_set('disable_functions', '') returns false and changes nothing. With open_basedir set, an attempt to widen it to / also returns false.

Stop advertising your PHP version

php.ini-production ships with expose_php = On. Its comment says the header “is no security threat in any way”, and that is fair: hiding the version does not fix anything. But the header tells every scanner which PHP release you run, which turns mass scanning for a new CVE into a simple header match. We ran PHP’s built-in server with each value:

$ curl -sI http://127.0.0.1:8099/index.php | grep -i x-powered   # expose_php=1
X-Powered-By: PHP/8.3.6
$ curl -sI http://127.0.0.1:8099/index.php | grep -i x-powered   # expose_php=0
$

Frameworks and reverse proxies can add their own version headers, so check the response at the edge too. Our guide to HTTP security headers covers the headers you do want to send.

Log errors, never display them

The production template sets display_errors = Off and log_errors = On, and its comment explains why: displayed errors could leak “sensitive information … such as database usernames and passwords or worse.” The built-in defaults are the opposite, so a server that runs PHP without loading a php.ini (a misconfigured container is the usual case) will print errors to users. Point error_log at a file or stderr that your logging pipeline collects.

Turn off URL includes and, if you can, URL file reads

allow_url_include lets include and require load code from a URL. It is off by default and the PHP manual marks it “Deprecated as of PHP 7.4.0”; enabling it now prints a deprecation notice at startup. Keep it off.

allow_url_fopen is broader: it lets file_get_contents(), fopen() and similar functions open http:// and ftp:// URLs. If your application only makes HTTP requests through cURL or an HTTP client library, turning it off removes one way for user input passed to a file function to become an outbound request. It does not stop server-side request forgery through your HTTP client; see our SSRF guide for that. Test before you change it: some libraries and package managers rely on it.

Session settings

PHP’s session defaults favour compatibility. Four changes matter.

Strict mode

The PHP manual is blunt: “Enabling session.use_strict_mode is mandatory for general session security. All sites are advised to enable this.” Without it, PHP accepts any session ID the browser sends, even one the server never issued, which enables session fixation. We simulated a browser sending an attacker-chosen PHPSESSID cookie:

<?php
// strict.php: run with `php -d session.use_strict_mode=0|1 strict.php`
ini_set('session.save_path', __DIR__);
$_COOKIE[session_name()] = 'attackerchosenid123456';
session_start();
printf("use_strict_mode=%s -> session_id=%s\n", ini_get('session.use_strict_mode'), session_id());

$ php -d session.use_strict_mode=0 strict.php
use_strict_mode=0 -> session_id=attackerchosenid123456
$ php -d session.use_strict_mode=1 strict.php
use_strict_mode=1 -> session_id=3e4393b3059589b68078c6a9f5c4fe34

Strict mode does not replace calling session_regenerate_id(true) after login; do both.

Cookie flags

• session.cookie_httponly = 1 makes the cookie inaccessible to JavaScript. The manual says it “can effectively help to reduce identity theft through XSS attacks”. It does not stop an XSS payload from making requests as the user.
• session.cookie_secure = 1 sends the cookie only over HTTPS. The manual notes that with it on, “sessions only work with HTTPS connections”. If TLS terminates at a load balancer, that means the browser’s connection: the flag is a cookie attribute the browser enforces, so it works as long as users reach you over HTTPS.
• session.cookie_samesite = Lax stops the browser sending the session cookie on most cross-site subrequests and form posts. It reduces CSRF exposure but does not remove the need for tokens; we compare the options in CSRF protection: SameSite, tokens and Fetch Metadata.

These cookie protections address token theft through the browser. They do nothing about a cookie stolen from the endpoint itself, which our explainer on token theft and MFA covers.

Request size and resource limits

post_max_size (8M in both defaults), upload_max_filesize (2M), max_input_vars (1000), memory_limit (128M) and max_execution_time (30 seconds) are mainly availability controls. Set them to what your application needs, not higher, and enforce body size limits at the web server or proxy as well, because those apply before PHP parses anything.

These limits briefly became security-critical in October 2026. PHP’s stopgap advice for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) included a low post_max_size, memory_limit=-1 set non-overridably and session.upload_progress.enabled=0. Those were emergency measures for unpatched servers and PHP said they “do not make an installation safe”. Once patched, keep a finite memory_limit unless you have a container or cgroup limit doing that job. Note that session.upload_progress.enabled is on by default and in the production template; if your application does not show upload progress bars, turning it off removes a feature you do not use.

What not to rely on

Two directives look like sandboxes and are not.

disable_functions removes named internal functions. With system, exec and shell_exec disabled, calling system() raises Error: Call to undefined function system(), which defeats the laziest webshells. But the PHP manual says plainly: “This directive can be circumvented and should not be considered a sufficient security measure for shared hosting environments.” It only covers internal functions you thought to list, and in PHP 8 a disabled function’s name can be redefined by userland code.

open_basedir limits which paths PHP’s file functions can open, and the manual says symlinks are resolved so they cannot be used to escape it. It is still not an isolation boundary. The same manual notes that “With dynamic loading, it’s possible to ignore all open_basedir restrictions”, which is one reason to keep enable_dl off, and the restriction only applies to PHP’s own file access, not to anything a spawned process does. It also disables PHP’s realpath cache, which has a performance cost.

If you host more than one application, or code you do not fully trust, isolate them at the operating system level: a separate PHP-FPM pool per application running as its own Unix user, with file permissions that stop one user reading another’s files, or separate containers. That is the boundary; the two directives above are defence in depth inside it.

Audit what is actually running

The settings that matter are the ones the serving process loaded, which may not be the php.ini you edited. The CLI and FPM usually read different files (on Debian and Ubuntu, /etc/php/<version>/cli/ and /etc/php/<version>/fpm/). This script prints the effective values against the baseline above. Run it under the SAPI you care about: from the command line for the CLI, or temporarily as a web request for FPM or mod_php (then delete it, since it reveals configuration).

<?php
// ini-audit.php: compare effective settings with a hardened baseline.
$baseline = [
    'expose_php'               => '0',
    'display_errors'           => '0',
    'display_startup_errors'   => '0',
    'log_errors'               => '1',
    'allow_url_include'        => '0',
    'allow_url_fopen'          => '0',   // only if the app never opens URLs with file functions
    'enable_dl'                => '0',
    'session.use_strict_mode'  => '1',
    'session.use_only_cookies' => '1',
    'session.cookie_httponly'  => '1',
    'session.cookie_secure'    => '1',
    'session.cookie_samesite'  => 'Lax',
    'session.use_trans_sid'    => '0',
];
$norm = fn($v) => match (strtolower((string)$v)) {
    'on', 'true', 'yes' => '1', 'off', 'false', 'no', '' => '0', default => (string)$v };

$fail = 0;
foreach ($baseline as $key => $want) {
    $have = ini_get($key);
    $ok = ($key === 'session.cookie_samesite')
        ? in_array($have, ['Lax', 'Strict'], true)
        : $norm($have) === $want;
    $fail += $ok ? 0 : 1;
    printf("%-26s %-6s want %-5s %s\n", $key, var_export($have, true), $want, $ok ? 'ok' : 'CHECK');
}
printf("\n%d setting(s) differ from the baseline (SAPI: %s, ini: %s)\n",
    $fail, PHP_SAPI, php_ini_loaded_file() ?: 'none');

Run against PHP 8.4.27’s php.ini-production with php -c php.ini-production ini-audit.php on PHP 8.3 CLI, it reported:

expose_php                 '1'    want 0     CHECK
display_errors             ''     want 0     ok
display_startup_errors     ''     want 0     ok
log_errors                 '1'    want 1     ok
allow_url_include          ''     want 0     ok
allow_url_fopen            '1'    want 0     CHECK
enable_dl                  ''     want 0     ok
session.use_strict_mode    '0'    want 1     CHECK
session.use_only_cookies   '1'    want 1     ok
session.cookie_httponly    ''     want 1     CHECK
session.cookie_secure      '0'    want 1     CHECK
session.cookie_samesite    ''     want Lax   CHECK
session.use_trans_sid      '0'    want 0     ok

6 setting(s) differ from the baseline (SAPI: cli, ini: php.ini-production)

With no php.ini at all (php -n), 10 of the 13 differed. With the hardened values applied, none did.

Limits of this article

This covers PHP’s own configuration, not your web server, framework or application code. We tested behaviour on PHP 8.3 CLI and read defaults from PHP 8.4.27’s template; check the manual for your version, since defaults and deprecations change between releases. The PHP-FPM pool example was not run. The baseline is a starting point for a typical web application: turning off allow_url_fopen in particular can break code that depends on it, so test in staging first.

Sources and verification

CVE-2026-109618 and CVE-2026-109619, which the security community has nicknamed “PHP2Shell”, are two memory-safety flaws in PHP’s core that can give an unauthenticated attacker remote code execution on a server running PHP for the web. The fixes are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 26, 2026, and gave federal agencies until October 29 to act.

These are bugs in the PHP interpreter, so they apply regardless of your framework or CMS. If you run PHP behind a web server, update the PHP package today, restart every PHP worker, then look for signs that someone got in first. Everything below comes from the PHP project’s advisory and CVE records and CISA’s KEV entry unless we say otherwise.

Are you affected?

The CVE records list PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12 as affected. PHP’s advisory adds who is at risk: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” It rates mod_php highest, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

The CVE records only list 8.2 to 8.5. Do not read that as “8.1 is safe”: PHP says 8.1 and older “no longer receive updates” and published source backports for 7.4, 8.0 and 8.1 because of the severity.

Why php -v can mislead you

Most production PHP comes from a distribution or a container base image, and those vendors backport fixes without changing the upstream version number. PHP says Linux distributions and LTS vendors “received the patches in advance”.

We checked an Ubuntu 24.04 host. php -v reports 8.3.6, which is far below 8.3.36, yet the package changelog shows the fix:

$ dpkg -l php8.3-cli | tail -1 | awk '{print $2, $3}'
php8.3-cli 8.3.6-0ubuntu0.24.04.13
$ zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | head -4
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via

So for a distribution build, search the package changelog for the CVE IDs. On Debian or Ubuntu, zcat /usr/share/doc/php*-common/changelog.Debian.gz | grep -m1 CVE-2026-109618 works; on RPM-based systems the equivalent is rpm -q --changelog <php package> | grep CVE-2026-109618 (illustrative; we did not run the RPM form). For official php Docker images and source builds, the upstream version is the one that counts.

Also check the binary that actually serves traffic. The CLI, php-fpm and libapache2-mod-php can come from different packages and be updated at different times.

A version check for upstream builds

This script compares upstream version strings against the fixed releases. We ran it with PHP 8.3 CLI (php php2shell-check.php 8.2.34 8.4.27 8.1.31). It cannot see distribution backports, so a “VULNERABLE” result on a distro build means “check the changelog”, not “definitely exposed”.

<?php
// Compares upstream PHP versions with the fixed releases for
// CVE-2026-109618 / CVE-2026-109619. Does not detect vendor backports.
$fixed = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];

function status(string $v, array $fixed): string {
    $branch = implode('.', array_slice(explode('.', $v), 0, 2));
    if (!isset($fixed[$branch])) {
        return version_compare($v, '8.2', '<')
            ? 'END OF LIFE: no upstream fix; needs vendor backport or upgrade'
            : 'UNKNOWN branch: check php.net';
    }
    return version_compare($v, $fixed[$branch], '>=')
        ? "fixed upstream (>= {$fixed[$branch]})"
        : "VULNERABLE upstream (< {$fixed[$branch]}) unless your vendor backported the fix";
}

foreach (array_slice($argv, 1) ?: [PHP_VERSION] as $v) {
    printf("%-10s %s\n", $v, status($v, $fixed));
}

$ php php2shell-check.php 8.2.34 8.4.27 8.1.31
8.2.34     VULNERABLE upstream (< 8.2.35) unless your vendor backported the fix
8.4.27     fixed upstream (>= 8.4.27)
8.1.31     END OF LIFE: no upstream fix; needs vendor backport or upgrade

What the two flaws do

Both bugs leave PHP’s internal request state inconsistent and let later code trust it.

• CVE-2026-109618, “RCE via OOM corruption”. The CVE record says PHP “uses longjmp() for out-of-memory (OOM) errors to exit the current context”. Some code paths “leave request memory in an uninitialized state before performing an allocation”, and “the subsequent request cleanup procedure may read or branch on this memory.” An attacker who can push a request into an out-of-memory failure at the right moment can trigger it.
• CVE-2026-109619, “RCE via stale global state”. Global state that “temporarily points into request memory” may not be reset, so it “may refer to request memory even after it has been freed.” PHP’s advisory explains the consequence: “A later request handled by the same worker may use that stale state before normal initialization resets it.”

Both carry a CVSS v4.0 base score of 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H): network-reachable, no privileges, no user interaction, but high attack complexity with attack requirements present. If you want to decode the vector, see our guide to reading a CVSS v4.0 vector string. The fix shipped in all four branches as one change, described in PHP’s NEWS file as “Avoid state corruption via bailout”.

Credits in the CVE records name Wiz, Ryan at Calif.io and OpenAI as reporters or finders.

Exploitation status

The public picture is mixed, so here is what each source says:

CISA’s Vulnrichment SSVC entry in the CVE records, dated October 21, still says Exploitation: none. That predates the KEV listing. For how these signals usually relate, see CVSS vs EPSS vs KEV.

Our reading: mass scanning started within hours, working exploits exist, and CISA has listed both as exploited. Whether specific attacks succeeded against production servers is not yet established in public sources. That uncertainty is a reason to hunt after patching, not a reason to wait.

What to do now

1. Inventory. Find every PHP runtime that serves HTTP: VMs, containers, base images, appliances with embedded PHP, and managed hosting. Container images need a rebuild and redeploy; patching the host does nothing for them.
2. Update. Move to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or your vendor’s patched package. For 8.1 and older, use a vendor backport or upgrade. PHP 8.2 itself reaches end of life on December 31, 2026, according to PHP’s release notes, so plan that upgrade too.
3. Restart every worker. CVE-2026-109619 is about state that persists across requests in the same worker. Restart PHP-FPM pools, Apache (for mod_php) and any long-running PHP servers after the package update.
4. Prioritise internet-facing mod_php, then FPM behind public web servers, then internal applications.

If you cannot update today

PHP lists stopgaps and is explicit that “only an update is a complete solution” and these “do not make an installation safe”:

; php.ini or FPM pool config, applied before request parsing, then restart workers.
; Illustrative: check each value against your application's needs.

; CVE-2026-109618 (OOM corruption)
; In an FPM pool use php_admin_value[memory_limit] = -1 so applications can't override it.
memory_limit = -1
; 8M if the app takes no uploads, 32M if it needs them; keep upload_max_filesize below it
post_max_size = 8M
upload_max_filesize = 2M

; CVE-2026-109619 (stale global state)
session.upload_progress.enabled = 0
; PHP 8.5 only:
; fatal_error_backtraces = 0

The reasoning behind each, from the advisory:

• memory_limit=-1 “removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.” With no PHP memory limit, a container or cgroup memory limit becomes your availability boundary. PHP warns: “Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.”
• Low post_max_size, plus limits at the web server or proxy on decoded request size, field count, multipart part count, header count and nesting depth. These “must also cover requests without a usable Content-Length.”
• session.upload_progress.enabled=0 “blocks the confirmed session paths but not other variants”. Set it in php.ini, the FPM pool or server config; PHP says “Do not rely on ini_set() or FPM .user.ini.”
• Hiding errors does not help: “Hiding diagnostics with error_reporting, display_errors or @ does not help.”

php_admin_value matters here because, per the PHP-FPM documentation, “Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set.”

What to hunt for after patching

Patching removes the bug, not an attacker who already used it. Preserve web server and PHP logs before you rotate or rebuild anything. The indicators below come from VulnCheck’s published honeypot observations. They describe scanners and one attempt; real attackers can change every one of them.

• User agents: php2shell-scan/109618, php2shell-verify/1.0, Mozilla/5.0 (php2shell-poc).
• Requests: multipart POSTs to /index.php that upload two files named a and b through the upload-progress path; follow-up GET requests using php://filter to read a session file.
• Session files containing PHP code. The attempt VulnCheck saw tried to plant a webshell through a session file, with a payload that prints PWNED::. A legitimate PHP session file contains serialized data, never <?php.

Two checks you can run on a Linux host. We tested both against sample files; adjust paths to your log format and to the session.save_path of the pool that serves traffic (php -i shows the CLI’s value, not necessarily FPM’s):

# Web logs: known scanner user agents and php://filter reads
grep -hE 'php2shell|php://filter' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

# Session files that contain PHP code or the test marker
grep -lE '<\?php|PWNED::' /var/lib/php/sessions/sess_* 2>/dev/null

Then do the usual post-compromise checks for a web server: new or changed .php files under the document root since October 17, unexpected child processes of the PHP worker or web server user (shells, curl, wget), and outbound connections from web hosts. Our guide to logging for incidents covers which of these you will wish you had recorded.

Federal agencies have to follow CISA’s forensic triage requirements for this KEV entry. If you want to borrow that process, our explainer on CISA BOD 26-04 covers it.

Limits of this article

We have not read the full GitHub security advisories, which PHP says contain the technical details; they were not reachable from our research environment. Exploitation reporting comes from vendors and press summaries we cite, not from our own telemetry. The hunting indicators come from one vendor’s honeypots and will not catch a modified attack. Exposure counts published by vendors differ widely, so we have not repeated them.

Sources and verification