Quick answer
Step-by-step
- List every site that answers the web with PHP. Include the public site, any staging hostname, and software that hides PHP inside it (a panel, a billing app, a WordPress or Laravel install, a container image). The PHP project’s warning covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is the setup they rank highest, because a request can hit the bug before the application runs.
-
Read the version the website uses.
In Plesk or a similar panel, open the domain’s PHP setting and note the exact version. On a server you administer, also compare that with
php -v. The command-line binary is often a different build from the one serving the site. A one-file info page is fine for the check if it is not linked from the site and you delete it the same day. - Install a fixed release. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Stay on the same major line when you can (8.3 moves to 8.3.36). On PHP 8.1 or older, the PHP project is not shipping normal updates. Use a distribution backport only if the vendor names these CVEs in the package, otherwise plan a move onto 8.2.35 or newer. Source-only backports exist for 7.4, 8.0 and 8.1 for people who build PHP themselves.
- Restart the workers and read the version again. Restart PHP-FPM or Apache so old workers exit. Then read the version from a web request, not only from the shell. The site is on the fix when that page shows one of the four releases above, or a vendor package whose changelog names CVE-2026-109618 and CVE-2026-109619.
- If you cannot update today, take the site off the public internet. The PHP project says there is no complete workaround. Until the new version is running, keep the application off the public network. Temporary php.ini changes listed later on this page only close some paths. They are not a reason to leave the site exposed.
Watch a short explanation
Sujit Manke’s walks through PHP2Shell: PHP 5.4 through 8.5.11 are affected, and the fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The written sections below are the full page.
If the player stays blank, open the same short at youtu.be/eAgQHJkSFAw.
What happened on 21 October 2026
On 21 October 2026 the PHP project published emergency releases for two critical bugs, now widely called PHP2Shell. The identifiers are CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). Both are scored CVSS v4.0 9.2. Both can allow unauthenticated remote code execution on a machine where PHP answers web requests.
The same day’s note from the PHP project names the fixed packages: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA published an alert the same day telling organisations to inventory PHP and patch internet-facing systems first. The Canadian Centre for Cyber Security published AL26-026 with the same version table.
A day earlier, on 20 October, the CVE numbers leaked with a release time that was not final and with a CVSS figure of 10.0. The PHP Foundation later said that score was wrong and that the score with the release is 9.2. Use 9.2 when you brief a client or a board.
Who is at risk
The PHP project’s own line is the one to plan against: every PHP installation that serves web requests. That includes:
- PHP-FPM (the usual setup on Nginx and on many Apache hosts)
- Apache with mod_php — the PHP project calls this the highest risk, because a demonstrated attack hits PHP before the application runs
- php-cgi
- FrankenPHP
- LiteSpeed
Shared hosting, a VPS, a container image, and a panel that bundles its own PHP all count. So does PHP inside another product (a firewall appliance, a helpdesk, an old billing tool) if that product’s web screens run PHP.
WordPress, Laravel, Drupal and custom apps do not contain this bug. They inherit it from the PHP version underneath. Replacing the application files, a theme, or a plugin does not close PHP2Shell.
A PHP binary that only runs a scheduled job and never accepts HTTP is outside the case the advisory describes. The moment that same server also has a vhost, a panel, or a health URL on PHP, it is in scope. Check the web-facing copy, not only the cron copy.
The two bugs, in plain language
Both sit in PHP’s own memory and error handling, which almost every request touches. You do not need a plugin, a theme, or a logged-in user.
| ID | What the PHP project says | Score |
|---|---|---|
| CVE-2026-109618 | Out-of-memory handling can interrupt PHP while request data is only partly set up. Cleanup can then treat that invalid data as real. | CVSS v4.0 9.2 |
| CVE-2026-109619 | State that belonged to one request can still be used after its memory was freed. A later request on the same worker can see that stale state. | CVSS v4.0 9.2 |
Canadian Cyber Centre classifies both as use-after-free (CWE-416). This page does not describe how a request is built. The action that matters is the version on the server.
Fixed versions
| Line you run now | Still vulnerable | Install this |
|---|---|---|
| PHP 8.5 | 8.5.11 and older | 8.5.12 |
| PHP 8.4 | 8.4.26 and older | 8.4.27 |
| PHP 8.3 | 8.3.35 and older | 8.3.36 |
| PHP 8.2 | 8.2.34 and older | 8.2.35 |
| PHP 5.4 through 8.1 | All of these builds. No upstream release from the PHP project. | Move to a fixed line above, or a vendor package that names both CVEs. Source backports exist for 7.4, 8.0 and 8.1 only. |
Linux distributions and long-term-support vendors received the patches before the public release, so the package name on Alma, Rocky, Ubuntu, Debian, or a Plesk PHP build may not be the upstream tarball version. Trust the package only when its changelog names CVE-2026-109618 and CVE-2026-109619. The PHP project also warned that the volunteer repo rpms.remirepo.net would not have packages on the release day, and asked people who use it to switch to distribution packages or build from source.
On a PrecisionTech-managed host, tell us the domain. We read the vhost’s PHP, apply the package, restart the pool, and confirm the version from a web request. Write to support@precisiontech.in. Hours are 11 AM–5 PM, Mon–Fri (excl. holidays). The support guidelines explain what to include so the ticket is actionable.
How to check the version that matters
You need the version inside the process that answers the browser.
- Plesk and similar panels. Open the domain, then its PHP setting. Note the handler (FPM, CGI, or Apache module) and the full version string.
- SSH.
php -vis the command-line binary. It can be 8.3 while the website still runs 8.1, or the other way around. Use it as a clue, then confirm the site. - A private info page. A single PHP file that prints
PHP_VERSIONis enough. Do not link it from the menu, do not leave it up, and do not print the full environment on a public URL.
After the package install, restart PHP-FPM or Apache. Workers keep the old code until they exit. Check the web version again. If it still shows a build from before 21 October 2026, the restart did not pick up the new package, or the vhost points at a different PHP.
If you cannot patch in the next few hours
Take internet-facing PHP off the public network until the fixed version is what the website reports. That is the PHP project’s position, and it is CISA’s position for anyone who cannot update or who is stuck on PHP 8.1 or older.
The measures below are copied from the 21 October advisory as temporary exposure reduction. The same advisory says they do not make an installation safe. Apply them in php.ini, an FPM pool, or the Apache config, then restart every worker. ini_set() and a per-directory .user.ini are too late for these paths.
- CVE-2026-109618. Set
memory_limit=-1where the application cannot put a finite limit back (php_admin_valuein the FPM pool or Apache). An allocation failure underneath can still reach the bug. Prefer a smallpost_max_size(8M if you do not need uploads, 32M if you do) and keepupload_max_filesizebelow it. - CVE-2026-109619. Set
session.upload_progress.enabled=0. On PHP 8.5 only, also setfatal_error_backtraces=0. Each of those blocks one confirmed path, not every path. - Do not use
RLIMIT_ASorRLIMIT_DATAas a substitute. The advisory says those limits can cause the allocation failure the first bug depends on.
A web application firewall may catch some attempts while you patch. It is not a record that the server is clean, and it is not a substitute for 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
After the update
Patching stops the next request from using these two bugs. It does not tell you whether a request already succeeded. For each internet-facing site, review the window from 17 October 2026 (when one vendor reported a pre-release attempt) through the hour you restarted onto a fixed build:
- PHP or web-server processes starting a shell, or downloading a tool
- New admin users, new files in the web root, and scheduled tasks you did not add
- Outbound connections from the web user that the site does not normally make
As of this page’s first note on 22 October 2026, public reports do not share one exploitation tally. CISA said it had not observed exploitation at the time it published on 21 October. Other advisories the same week described a proof of concept in circulation and exploitation attempts, including activity dated 17 October, before the public release. Treat the bugs as already being tried. If the log review shows a shell or a new file you cannot explain, isolate that site before you put it back on the internet.
What PrecisionTech will do
For a server on our hosting, the work is the package, the restart, and a written version check. Email the domain to support@precisiontech.in. We work 11 AM–5 PM, Mon–Fri (excl. holidays).
For a server, panel, or container we do not operate, a version review and a patch plan are paid consulting, scoped before we start. The contact form is the place to ask. Our PHP development work is a separate service from this emergency package update.
Sources checked for this page
- PHP project, “Security advisory: Critical remote code execution vulnerabilities, update now”, 21 October 2026, on the PHP 2026 news archive (php.net).
- The PHP Foundation, “Today’s PHP Security Release”, 21 October 2026 (thephp.foundation).
- CISA, “Critical Vulnerabilities in PHP Require Immediate Patching”, 21 October 2026.
- Canadian Centre for Cyber Security, AL26-026, 21 October 2026.
Updates
When the facts change, we add a note at the top of this list. The heading is the date we wrote the note. Older notes stay, so you can see what we said at the time.
22 October 2026 — Short video
Added Sujit Manke’s YouTube short on this page: youtu.be/eAgQHJkSFAw. The player sits at the top. The version numbers in the video match this page.
22 October 2026 — Affected range
Google Cloud lists all PHP versions from 5.4 through 8.5.11. AWS lists PHP 5.4–8.1 with no upstream fix, plus the unfixed builds on 8.2, 8.3, 8.4 and 8.5. The version table and the PHP 8.1 FAQ on this page now say that. PHP 5.4 was released in 2012.
22 October 2026 — Page published
First write-up, from the PHP project releases of 21 October 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35), the PHP Foundation note the same day, the CISA alert, and Canadian AL26-026. Fixed-version table, the temporary settings, and the exploitation reports above match those sources as of this date. Nothing later has been added yet.
Frequently Asked Questions
1 What is PHP2Shell?
2 Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
3 Are PHP 8.1, PHP 8.0, PHP 7 and PHP 5 affected?
4 Does this affect WordPress, Laravel, or only a custom PHP app?
5 Will a firewall or memory_limit change make the server safe?
6 How do I know the live site is patched, not just the SSH prompt?
php -v over SSH often prints a different binary. Hosting panels can also show the selected version while an old pool is still in memory until you restart it.