Patch PHP now.Two critical flaws.
PHP fixed two critical flaws on October 21, 2026. An attacker can run code on an affected web server without a login. Install 8.5.12, 8.4.27, 8.3.36, or 8.2.35 today.
Update. Then confirm.
The only complete fix is a patched PHP version. Do these in order.
- Install a patched release
Use PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a newer build in that branch. A WordPress, plugin, or theme update does not fix this.
- Inventory every public PHP site
Include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Count sites a host runs for you outside EMPIST.
- If you cannot update today, take it offline
The NSA recommends taking the system offline until it is fully mitigated. Partial settings reduce some paths. They do not make the server safe.
- Keep session upload progress off
Set
session.upload_progress.enabled=0until the next bugfix. If you set it on October 21, leave it. PHP will publish CVE-2026-115560 with that release.
Install one of these.
PHP 8.1 and older no longer get releases from the PHP project. Ask your Linux vendor about a backport, or move to a supported branch.
| Branch | Install | Status |
|---|---|---|
| 8.5 | 8.5.12 or newer | Supported |
| 8.4 | 8.4.27 or newer | Supported |
| 8.3 | 8.3.36 or newer | Supported |
| 8.2 | 8.2.35 or newer | Security fixes end Dec 31, 2026 |
| 8.1 and older | No PHP project release | Vendor backport, or upgrade |
| 8.6 test builds | RC4 includes the fix | Not for production |
Linux distributions received the patches early, so check your vendor packages. Windows binaries are on the PHP downloads page. PHP also published minimal source backports for 7.4, 8.0, and 8.1 for people who build from source.
Sources
The flaw is in PHP.
These are not bugs in WordPress, Laravel, or your config. Risk is highest on mod_php: PHP says an unauthenticated request can trigger the attack before application code runs. The NSA calls the pair PHP2Shell.
Exposed
- Any PHP install serving web requests
- mod_php carries the highest risk
- PHP 8.1 and older, unless a vendor backports the fix
- Internet-facing sites, including ones you do not manage in-house
Does not fix it
- A WordPress, plugin, or theme update alone
- Hiding errors with display_errors or @
- A runtime ini_set() for the upload-progress mitigation
- Waiting on a security tool to add a signature
CVE-2026-109618 and CVE-2026-109619 both allow unauthenticated remote code execution. PHP rated both CVSS v4.0 9.2. One is tied to out-of-memory handling during request setup. The other reuses freed request state on the same worker. An attacker could steal data, disrupt the site, or move further into the network.
Settings are not a fix.
PHP says updating is the only safe choice. Use the steps below only to reduce exposure for a few hours, then patch. On October 23, PHP added a follow-up for an unlikely extra path, CVE-2026-115560.
- Limit the out-of-memory path
For CVE-2026-109618, set
memory_limit=-1where the app cannot override it, such asphp_admin_valuein the FPM pool or Apache config. Confirm no pool or folder puts a finite limit back. Lowerpost_max_sizeto 8M if you do not need uploads, or 32M if you do, and keepupload_max_filesizebelow that. Do not useRLIMIT_ASorRLIMIT_DATAas a stand-in. Those limits can cause the allocation failure this flaw uses. - Turn off session upload progress
For CVE-2026-109619, set
session.upload_progress.enabled=0in php.ini or the FPM pool, then restart every worker.ini_set()and.user.inido not apply in time. On PHP 8.5, also setfatal_error_backtraces=0and restart workers. - Leave that setting off until the next bugfix
The October 23 note covers CVE-2026-115560. The extra issue needs an unusual setup: the app stores
session.serialize_handlerasphp_binaryorphp_serialize, then switches it tophpwithini_set()beforesession_start(), while upload progress is still on. Apps that never change that handler at runtime can keep the feature on. If you turned it off on October 21, leave it off. No further action until the next release.
If we run the server.
Call and we will confirm the version on systems we manage. Sites on another host still need that host to ship the package.
- Servers and sites we manage
Call (866) 442-3018 or (312) 360-1900, or open a ticket in EMPIST 360. We check the running PHP version and apply the operating-system or host package. Ongoing coverage is our patch management service.
- Sites you host somewhere else
Ask that host for the PHP version, not the WordPress version. Control panels often hide PHP under a selector. If they cannot patch, take the site offline until they can.
- If you already see attacker behavior
Patching a server that is already compromised is not enough. Use the under-attack line and call. Do not wipe machines before someone is guiding containment.
Questions people ask first
WordPress, old PHP, and what October 23 changed.
01Does a WordPress update fix this?
02Which PHP versions are safe?
03Are EMPIST-managed servers already patched?
04What if we cannot patch today?
05What is PHP2Shell?
06What changed on October 23?
session.upload_progress.enabled=0 until the next bugfix, to close an unlikely extra path tracked as CVE-2026-115560. If you already set that on October 21, leave it. The October 21 patches are still required.Not sure which servers run PHP?
Tell us what you host. We will confirm the version and the patch path. Managed clients can also call EMPIST Support.