Security Guides
[Breaking] Two critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619), Japan's IPA and JPCERT/CC issue alerts: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical RCE flaws (CVE-2026-109618, CVE-2026-109619). IPA, JPCERT/CC and CISA have issued alerts. What to update, and where shared-hosting providers stand.
Who this is for: anyone running a website on PHP (own server, VPS, cloud, Docker or shared hosting) and anyone building sites with WordPress, Laravel, EC-CUBE and similar. This article is based on the PHP security team's official announcements and statements from public bodies and providers. It does not cover how to attack anything.
Developing: this page will be updated as more is published
As of 04:45 UTC, October 22, 2026Not yet known
- Exploitation in the wild (official view)
- Remaining OS package streams (RHEL 9 php:8.4, Debian forky and sid)
- Hosting providers that have not announced completion (KAGOYA, ConoHa WING, Onamae.com, CPI and others)
The PHP security team released the fixes on October 21, and Japan's IPA and JPCERT/CC issued alerts on October 22. Many shared-hosting providers have announced that the fix is applied. This page will be updated as the remaining OS packages and providers are confirmed.
The fixed versions and the vulnerabilities (from php.net)
On October 21, 2026, the PHP security team published a security advisory on php.net ("Critical remote code execution vulnerabilities, update now") and announced the fixed release for each branch.
- Fixed versions
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- CVE-2026-109618
- Out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat the invalid data as valid. Leads to remote code execution (RCE)
- CVE-2026-109619
- Request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before initialization resets it. Leads to remote code execution (RCE)
- Severity
- Both CVSS v4.0 9.2
- Who is at risk
- All PHP installations serving web requests (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). mod_php is the highest risk, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs
- 8.1 and older
- No update from the PHP project. Minimal source backports were provided for 7.4, 8.0 and 8.1
- Distributions
- Linux distributions and LTS vendors received the patches in advance; check your vendor for updated packages
- Mitigations
- No complete mitigation; updating is the only safe choice (temporary measures if you cannot update yet are in the box below)
Temporary measures if you cannot update yet (from the advisory; they do not make you safe)
The PHP team lists settings that reduce specific attack paths until you can update, but says none of them make an installation safe. The main ones are reviewing memory_limit and request size limits such as post_max_size, disabling session.upload_progress.enabled and restarting workers, and on PHP 8.5 disabling fatal_error_backtraces. The conditions matter, so read the official advisory before changing anything, and prioritise the update.
After the release (as of 04:45 UTC, October 22, 2026)
- Release time
- The GitHub security advisories were published at about 13:34 UTC (22:34 JST), about 30 minutes ahead of the 14:00 UTC schedule
- Affected versions
- Per the official GitHub advisories, versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The CVE records list 8.2 to 8.5 and say nothing about 8.1 and older (the team provided source fixes for 7.4, 8.0 and 8.1)
- Confirmed impact (from the advisories)
- CVE-2026-109618: unauthenticated remote code execution confirmed on mod_php; PHP-FPM may be affected per source analysis, but a full exploit has not been demonstrated. CVE-2026-109619: remote code execution confirmed on mod_php; also validated on PHP-FPM via the session upload progress path, which depends on a suitable application operation
- Japanese public bodies
- On October 22, IPA published "PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)" (Measures for the PHP vulnerabilities, Japanese), a follow-up to its October 21 advance notice. It asks users to update to the fixed versions (8.2.35, 8.3.36, 8.4.27, 8.5.12). For end-of-life 8.1 and older, it asks users to move to a supported PHP or to a product or service that has been fixed. If effective interim measures are hard, it asks organisations to judge whether they need to block outside access or temporarily stop the service. It also cites the view of a security company involved in the research that PHP 5.4 and later are affected by at least one of the flaws (that company's view, not a statement from the PHP team). JVN published JVNVU#99905564 at 10:30 JST (01:30 UTC) the same day, asking users to apply the patches. JPCERT/CC issued an alert (JPCERT-AT-2026-0033) the same day, urging prompt updates and checks for signs of compromise. It also sets out what to look for when checking for compromise
- CISA
- CISA issued an alert on October 21 urging organisations to patch immediately. It says it "has not observed exploitation of these vulnerabilities as of the time of publication". It tells organisations that cannot update immediately, or that still run PHP 8.1 or older, to take PHP-based systems offline until they can be patched or updated. The flaws are not in the Known Exploited Vulnerabilities catalog (October 21 edition)
- Exploitation in the wild
- No statement from the PHP team, and CISA says it had not observed exploitation as of its publication. Several security companies and a CDN provider report observing attack or probing traffic (CDN provider, news summary). According to news reports, one company said it is "exploited in the wild at scale" without giving numbers, while another says no attempt has succeeded so far. Another security company says it has not observed in-the-wild exploitation on partner systems (as of October 21). A WordPress security firm said in its own post that it has "no hard evidence of breaches". No confirmed break-in had been announced as of 04:45 UTC on October 22
- OS packages
- Ubuntu has fixed all releases (USN-8948-1, USN-8948-2). Debian has fixed 13 (DSA-6574-1) and 12 (DLA-4848-1), and fixed packages for the development branches (forky and sid) have not been built yet. Red Hat has fixed many RHEL 8–10 streams (rated Important, access.redhat.com) and added RHEL 8 php:8.2 on October 21 (RHSA-2026:87073). RHEL 9 php:8.4 is still pending, and RHEL 6 and 7 are now "under investigation" for CVE-2026-109618. Alpine has fixed 8.5, 8.4 and 8.3. If PHP comes from OS packages, apply your vendor's update now
- Docker official images
- The latest, 8.5, 8.4, 8.3 and 8.2 tags (including the -apache and -fpm variants) all point to the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35) (hub.docker.com). The end-of-life 8.1 and older tags have not been updated. The fix only takes effect after you pull the image again and recreate the containers
- NVD
- NVD's own score for both is CVSS 3.1 9.8 (Critical); the PHP team's score is CVSS v4.0 9.2 (nvd.nist.gov)
- Claim that the fix is incomplete
- A post on a vulnerability mailing list said the 8.5.12 fix "may be incomplete"; this is unconfirmed, and another post relays that PHP called it unrelated (secondhand). As of 04:45 UTC on October 22, the PHP team had still made no official statement on it
- Windows
- Windows builds of the fixed versions are available
- remirepo
- The PHP team says the volunteer-run rpms.remirepo.net will not have updates today and urges switching to distribution packages or building from source
The advance notice (October 20)
A day earlier, on October 20, 2026, the PHP security team posted a notice on php.net titled "Upcoming Critical PHP Security Release". It said the following.
- Release time
- Wednesday, October 21, 2026, 14:00 UTC (23:00 in Japan)
- Scope
- Two critical vulnerabilities
- Severity
- Both rated 9.2 under CVSS v4.0
- Request
- All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available
- Earlier release
- The team may release earlier if details of either vulnerability become public or evidence of active exploitation appears
- Not yet published
- Full details, affected versions and fixed versions, all due with the release
- Latest versions at the time
- 8.5.11, 8.4.26, 8.3.35 and 8.2.34 (security releases of September 24, 2026)
CVSS rates a vulnerability's severity from 0 to 10, and 9.0 or higher is the top "Critical" band (see What is CVSS). Japan's IPA also published a "please prepare in advance" notice on October 21 asking organizations to inventory programs that use PHP. IPA points out that PHP can also run inside software products and network devices, not only web applications.
Who updates PHP: it depends on your setup
Any site running on PHP may be affected, but who actually updates PHP differs by environment. Getting this wrong leads to gaps such as "I thought the provider did it" or "I updated a different PHP than the one serving the site".
Own server, VPS, cloud
You update it (upgrade packages, then restart)
Docker (official image)
You rebuild once new tags are out
Distro packages (Debian, Ubuntu, RHEL …)
The distro backports the fix, you apply it. Version numbers differ from upstream
Shared hosting
The provider updates PHP. You check which version you selected
| Environment | Who updates PHP | What you do |
|---|---|---|
| Own server, VPS, cloud server | You | Install the fixed version (or the distro's fixed package) and restart PHP-FPM or Apache |
Docker official image (php:8.4-fpm and so on) | The image maintainers and you | When the fixed tag is published, pull it, rebuild your image and replace the containers. Do not reuse a cached old base image |
| Distro packages (Debian, Ubuntu, RHEL family) | The distribution and you | Check the distribution's security notices for the fixed package and apply it. Distributions backport only the fix, so their version numbers will not match PHP's upstream numbers |
| Shared hosting | The provider | Check each site's PHP version in the control panel, plan a switch if it is 8.1 or older, and read the provider's notices on its official website |
| PHP embedded in products or devices | The vendor | Check the vendor's security notices (you may not be able to see the PHP inside) |
The update button in WordPress or Laravel does not update PHP itself. Updating your application and updating PHP are separate tasks.
How to check your PHP version safely
If you can log in to the server, use the command line
If you have shell access, this command shows the PHP version.
php -vThis is the version of the command-line (CLI) PHP, though. The PHP serving your website (PHP-FPM or the Apache module) can be a different version. It is common for one server to have both 8.2 and 8.4 installed. Check the web side with the methods below or by the PHP-FPM service name (for example php8.4-fpm).
In WordPress, use Site Health
In the WordPress dashboard, open Tools, then Site Health, then the Info tab, and expand "Server". It shows the PHP version actually running the site, so anyone with admin access can check without logging in to the server.
On shared hosting, use the control panel
On shared hosting, the control panel's PHP version settings show the version selected for each domain. Many providers let you choose a different version per domain, so check every domain.
Do not leave a phpinfo() page online
One way to see the version is to put a file calling phpinfo() in the public directory, but that page lists PHP's version, configuration and internal server details. It gives an attacker useful targeting information, so delete it as soon as you are done. If the three methods above are enough, do not create one at all. How to find forgotten files is covered in Secret files left in public directories.
Before you update
List your sites and servers
For each site, write down which server it is on, the PHP version (CLI and web), who updates PHP (you, the provider or a contractor), and the owner's contact details, in one table. Include staging sites and forgotten sites that are still public. Forgotten sites are the ones that miss updates. A method is in the security inventory checklist.
Take backups
Back up files and databases so you can roll back if the update breaks the site. Store the backup off the server and confirm you can restore it (backup and recovery essentials).
Set a maintenance window and steps
Decide when you will update (including late-night slots), who will do it, and how you will inform people. For your own servers, write down the update commands, the services to restart and how to confirm the result. If a contractor or agency manages the server, confirm today who updates it and when.
On an end-of-life branch, plan the migration
According to php.net, support for PHP 8.1 ended on December 31, 2025, as it has for 8.0 and older. Under the PHP project's support policy, end-of-life branches do not get security releases. No official release was issued this time either (only minimal source backports for 7.4, 8.0 and 8.1); plan a move to a supported version, 8.2 to 8.5. Security support for 8.2 also ends on December 31, 2026, so 8.3 or later is the safer target if you are moving now.
Do not rush to unofficial 'fix' plugins or configuration workarounds
Before a fix ships, unofficial plugins and configuration changes that claim to block the issue tend to circulate. Methods not in the official advisory cannot be verified. The only real fix is PHP's fixed release (or your distribution's fixed package). WAF (web application firewall) rules can buy time, but they do nothing for traffic that reaches the server without passing through the WAF.
Updating to the fixed version
The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (released October 21, 2026). If you installed PHP from your OS packages, use the updated packages your distribution ships.
Upgrade to the fixed version for your branch
Check the php.net release announcement and ChangeLog for the fixed version of your branch (8.2, 8.3, 8.4 or 8.5) and update to that version or later. If you use distro packages, check your distribution's security notices (Debian, Ubuntu, Red Hat and others) for the fixed package version. For Docker, pull and rebuild once the fixed tags are published.
Restart PHP-FPM and Apache
Upgrading the package does not change PHP processes that are already running. Restart PHP-FPM (for example php8.4-fpm), or Apache if you use its PHP module, so the new PHP is loaded.
Confirm the version on both CLI and web
In addition to php -v, use WordPress Site Health or the PHP-FPM service status to confirm that the PHP serving the website is now the fixed version. On servers with several PHP versions installed, check all of them.
Check that the site works and nothing looks wrong
Check key pages, login, contact forms and payments. If you are worried the site was attacked before the fix, look for unknown files, extra admin accounts and defacement. How to check is covered in How to check whether your website or server was compromised.
For shared-hosting users
On shared hosting, the provider installs and manages PHP on the server. Users cannot install the fixed version themselves.
What the provider does
- Updates the PHP installed on the servers to the fixed version
- Applies temporary protections or emergency maintenance if needed
- Posts status updates on its official website and social media
What you do
- Check the PHP version selected for each domain in the control panel
- If it is 8.1 or older, test and then switch to a newer version
- Read provider notices on the official website, not through email links
- Keep WordPress core, plugins and themes up to date as well
Emergency maintenance on the provider's side can make the control panel unavailable for a while. Finish your checks early so you are not stuck needing to switch PHP versions during that window.
Provider responses (confirmed by this site as of 04:45 UTC, October 22, 2026)
Many providers say they have finished applying the fix. As of 04:45 UTC (13:45 JST), KAGOYA, ConoHa WING, Onamae.com, CPI, Lolipop, Rakko Server and WADAX had not announced completion. Times below are JST.
| Provider | Official notice | What it says |
|---|---|---|
| Xserver (Japan) | Notice of temporary suspension of official websites and control panels as a preventive safety measure (last updated 13:15 Oct 22, Japanese) | At 06:45 Oct 22, finished applying the patches for PHP 8.2–8.5 to all target servers. For older versions, it is applying patches in turn as each is verified, and work on the rest continues. At 09:30 it reopened the account panel and other functions except Shin Cloud services, and at 13:15 Shin Cloud reopened too (some functions still under maintenance). The official websites are expected back within the day; webmail, the API/MCP and the contact form are still stopped. It may ask customers for further steps after the panels reopen. It says the action is not due to unauthorized access |
| Sakura Rental Server (Japan) | Status of the response to the PHP vulnerabilities (Oct 22, Japanese) | Fix applied to every PHP version selectable in the control panel; no urgent customer action needed. It also suggests moving to the latest supported PHP. phpMyAdmin and webmail used by some services are still in progress. The emergency maintenance from Oct 21 (n-2697) finished at 22:30 Oct 21 |
| mixhost (Japan) | [Completed] Response to the critical PHP vulnerabilities (Oct 22, Japanese) | Fix packages applied on all servers at about 10:18 Oct 22, covering PHP 5.2–8.5. Version numbers do not change (for example, 8.4.26 stays 8.4.26). No customer action needed. The My Page maintenance from 22:10 Oct 21 is also over |
| ColorfulBox (Japan) | Notice (Oct 22, Japanese) | Advance protections and the update to fixed versions were all completed on every server (shared, business, Tada Server and dedicated) by the morning of Oct 22, including 7.4, 8.0 and 8.1. Updated in place, keeping the PHP version you use; no customer action needed |
| XREA, VALUESERVER, CORESERVER, One Rental Server (Japan) | XREA, VALUESERVER, CORESERVER V1 / V2, One (Japanese) | All five completed. XREA, VALUESERVER and CORESERVER V1 completed at 00:50 Oct 22 and say PHP 7.4 and later (7.4–8.5) are fixed. One Rental Server completed at 10:20 (PHP 8.0 and later) and CORESERVER V2 at 11:13 (all PHP versions offered). Users of the covered versions do not need to change PHP versions |
| Heteml (Japan) | [Partly completed] Maintenance as a precaution against the PHP vulnerabilities (updates at 12:18 and 13:20 Oct 22, Japanese) | At 12:18, customer sites, the service site, control panel, heteml FTP and hetemail were back. PHP 8.x and 7.4 got the official fixes; other versions got the provider's own fixes based on the official ones. On PHP 8.1 and below, some features (such as session.upload_progress) are disabled by this measure, and customers are asked to check that their sites work and respond. phpMyAdmin was back at 13:20 |
| Lolipop (Japan) | Maintenance as a precaution against the PHP vulnerabilities (Oct 21, Japanese) | Stopped its service site, user pages and more as a precaution. The service site was back on Oct 22, but no completion notice was found |
| KAGOYA (Japan) | Impact of the PHP vulnerabilities on its services (updated 10:35 Oct 22, Japanese) | For PHP 8.2–8.5 on its rental servers, it says it is "arranging" the update to the fixed versions; completion has not been announced. For managed dedicated, shared and WordPress plans, the permanent fix is still being arranged, and it asks customers to consider taking sites offline (switching to a maintenance page) or restricting access as an interim measure. It says no damage such as attacks or data leaks has been confirmed |
| ConoHa WING (Japan) | Response to the PHP vulnerabilities, Suspension of the file manager and webmail (Oct 22, Japanese) | Says the emergency maintenance since Oct 21 is for these vulnerabilities and that security patches are being applied to servers in turn, keeping each customer's PHP version; customers do not need to change versions. The file manager and webmail are suspended as a precaution. Websites and mail work as usual |
| Onamae.com Rental Server (Japan) | Response to the PHP vulnerabilities, Suspension of the file manager and webmail, Server maintenance (Oct 22, Japanese) | Security patches are being applied to servers in turn, keeping each customer's PHP version, but users of PHP 5.x or 7.x may need to change versions in some cases. The file manager and webmail are suspended as a precaution (mail and FTP clients still work). Server maintenance with host reboots runs 12:00–21:00 Oct 22, with a few minutes to a few tens of minutes of downtime per host |
| CPI (Japan) | Notice on suspending its service site and control panels for the PHP vulnerabilities (updated 21:45 Oct 21, Japanese) | Control panel, My Page and more stopped from 21:00 Oct 21 for the PHP vulnerabilities. Reopening still not set as of 13:45 Oct 22. Says customer servers will not stop |
| Rakko Server (Japan) | Official website (Japanese) | Its service site was stopped from 19:00 Oct 21 as a precaution (it said no unauthorized access was found). The site is back, but no notice about PHP was found |
| WADAX (Japan) | Notice on its website (checked Oct 22, Japanese) | Whole site suspended for security until safety is ensured; unchanged as of 13:45 Oct 22. The notice does not mention PHP |
Providers word their completion notices differently. Check in your provider's notice which PHP versions are covered and whether you need to do anything. Other providers' notices will be added once confirmed.
Watch for fake emails pretending to be your host
When a vulnerability or emergency maintenance is in the news, fake emails claiming to be from hosting or domain providers ("log in again for urgent maintenance", "your account will be suspended") become more common. Do not log in through email links. Check through the official website you bookmarked yourself or the provider's official social media account. How to spot them is covered in What is phishing. How to prepare for a breach at the provider itself is in When your hosting provider is breached.
Reports from before the release
The official announcement of October 21 confirmed the CVE IDs (CVE-2026-109618, CVE-2026-109619) and that both are remote code execution (RCE) vulnerabilities. The table below shows what was reported before the release; exploitation in the wild is still not officially confirmed.
Before the release, media and security companies passed on several claims. None of them were official statements from the PHP security team. This site has not changed its recommended steps based on them.
| Claim | Source | Status |
|---|---|---|
| Details of the flaws leaked before the scheduled release | A security company (speaking to a news outlet) | Unconfirmed |
| Both are remote code execution (RCE) flaws | Security companies, and CERT-EU (the CSIRT for EU institutions) | Confirmed by the October 21 announcement |
| CVE IDs (CVE-2026-109618, CVE-2026-109619) | Security companies, media, CERT-EU | Confirmed by the October 21 announcement |
| A wide range from PHP 5 onward is affected | Security companies, CERT-EU | Unconfirmed (the GitHub advisories cover versions before each fixed release with no lower bound stated; backports provided for 7.4/8.0/8.1). IPA's October 22 alert cites a security company involved in the research as saying PHP 5.4 and later are affected |
| No exploitation observed | A security company (speaking to a news outlet) | The source's own view |
| Signs of attacks observed | An executive at a CDN provider, and another security company (citing reports from hosting partners) | A CDN provider said in its 13:56 UTC post that it observed attack traffic (see "After the release"). No public body has confirmed it |
Views on exploitation differ by source. In its October 21 advance notice, IPA said it had not confirmed attacks exploiting the flaws at that point. CISA also said in its October 21 alert that it had not observed exploitation as of publication. Whether or not exploitation has started, the action is the same: update to the fixed version now.
This site's view: what you decide today is who updates, and when
The fixed versions are out. What remains is deciding who updates, and when, and doing it. The usual gap is not technical but ownership. A site an agency built, a VPS set up by someone who has since left, a test server nobody remembers: PHP without a named owner is what stays old the longest. How to judge severity is covered in How to prioritize vulnerabilities (CVSS, EPSS, KEV), and the steps after disclosure in What to do when a vulnerability is published.
Timeline
September 24, 2026
PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34 released as security releases (the latest versions at the time of the notice).October 20
The PHP security team announces on php.net a security release for 14:00 UTC on October 21. Both vulnerabilities are rated 9.2 under CVSS v4.0. The same day, a security company is reported telling a news outlet that the details had leaked.October 21
IPA publishes its "please prepare in advance" notice. Xserver suspends access to its official websites and control panels from 16:00 JST.October 21
The PHP security team releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and a security advisory. It says CVE-2026-109618 and CVE-2026-109619 can both allow unauthenticated remote code execution and urges everyone to update immediately.October 21
CISA issues an alert urging immediate patching and says it has not observed exploitation as of publication.October 22
Xserver (8.2–8.5), Sakura, mixhost, ColorfulBox, the Value Domain group services, Heteml and others announce that the fix is applied. JVN publishes JVNVU#99905564, IPA issues its alert on measures for the PHP vulnerabilities, and JPCERT/CC issues its alert (JPCERT-AT-2026-0033).
Sources (public record)
The facts in this article are based on the public information below. Items PHP has not officially published (such as exploitation in the wild) are attributed to media or security companies and marked as unconfirmed.
- PHP security team, "Security advisory: Critical remote code execution vulnerabilities, update now" (October 21, 2026) — php.net
- GitHub security advisory for CVE-2026-109618 — github.com
- GitHub security advisory for CVE-2026-109619 — github.com
- ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35) — php.net
- PHP, "Upcoming Critical PHP Security Release" (October 20, 2026) — php.net
- PHP home page (latest versions at the time: 8.5.11, 8.4.26, 8.3.35, 8.2.34) — php.net
- PHP, "Supported Versions" — php.net
- PHP, "Unsupported Branches" (8.1 end of life: December 31, 2025) — php.net
- php-src security advisories (GitHub) — github.com
- IPA, notice asking for advance preparation for the PHP security release (October 21, 2026, Japanese) — ipa.go.jp
- IPA, "PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)" (October 22, 2026, Japanese) — ipa.go.jp
- JVN, JVNVU#99905564 on multiple PHP vulnerabilities allowing arbitrary code execution (October 22, 2026, Japanese) — jvn.jp
- JPCERT/CC, alert on multiple PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619) (JPCERT-AT-2026-0033, October 22, 2026, Japanese) — jpcert.or.jp
- CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (October 21, 2026) — cisa.gov
- Xserver Inc., notice of temporary suspension as a preventive safety measure (last updated 13:15 JST, October 22, 2026; shown on the official website's pages while they are suspended, Japanese) — xserver.ne.jp
- CERT-EU, "Security Advisory 2026-018: Critical Vulnerabilities in PHP" (source for unconfirmed claims) — cert.europa.eu
- Media report: a security company's account of the leak and its view that no exploitation was observed (BleepingComputer, October 20, 2026) — bleepingcomputer.com
- Security company alert: reports of attacks from hosting partners (October 21, 2026) — patchstack.com
- Post by a CDN provider's executive: early attacks and WAF rules (October 21, 2026; quoted in the alert above) — x.com
- Security company rapid response: no in-the-wild exploitation observed on partner systems (as of October 21, 2026) — huntress.com
- Security company write-ups (reported CVE IDs, type and scope) — sansec.io / tenable.com
- Distribution security notices: Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com (RHEL 8 php:8.2: RHSA-2026:87073)
- Docker official image (php) — hub.docker.com
Update history
2026-10-22 (04:45 UTC): Changed the title to a breaking-news format and added IPA's alert, JPCERT/CC's alert (JPCERT-AT-2026-0033), JVNVU#99905564 and CISA's alert. Updated exploitation reports (still no confirmed break-in), OS packages (RHEL 8 php:8.2 added; RHEL 9 php:8.4 and Debian's development branches pending), Docker official images, and shared-hosting completion status (Xserver, Sakura, mixhost, ColorfulBox, the Value Domain group services, Heteml and others).
2026-10-21 (21:30 UTC): Updated exploitation reports (attempts observed, no confirmed break-in), OS vendors' fixed packages, Docker official images now fixed, NVD's score, an unconfirmed claim that the fix is incomplete, and hosting updates (Xserver began applying fixes, WADAX added).
2026-10-21 (14:30 UTC): Added a CDN provider's report of observed attack traffic, Ubuntu's fixed packages (USN-8948-1), the NVD entries and the status of Docker official images.
2026-10-21 (14:10 UTC): Added the post-release status (release time, affected versions, impact confirmed in the advisories, no official word on exploitation, OS packages, Docker official images, remirepo) and hosting updates after 21:00 JST (CPI and mixhost added, Xserver FAQ, Sakura completion).
2026-10-21 (after the release): Reflected the PHP security team's October 21 announcement (fixed versions, CVE IDs, what the flaws are, who is at risk, how 8.1 and older are handled, temporary measures) and rewrote the title and takeaway.
2026-10-21: First version, based on the PHP security team's notice of October 20, IPA's advance-preparation notice and Xserver's notice. CVE IDs, affected versions and fixed version numbers will be added after the release.
Read next
- Was your site attacked: How to check whether your website or server was compromised
- When the provider is breached: When your hosting provider is breached / Unauthorized access at ConoHa WING
- Shared-hosting settings: Protecting .env on shared hosting
- WordPress and Laravel: WordPress security / Laravel security
- Preparation: Backup and recovery essentials / Security inventory checklist
- Terms: What is RCE (remote code execution) / What is CVSS
FAQ
QWhat happened?
On October 21, 2026, the PHP security team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution (CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2), and urged all users to update immediately. It had announced the release a day earlier, on October 20.
QIs my site affected?
The PHP team says all PHP installations serving web requests are at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php the highest risk. For sites running on PHP (WordPress, Laravel, EC-CUBE and others), check the PHP version and update if it is older than the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35).
QI use shared hosting. Do I need to do anything?
On shared hosting, the provider updates the PHP binary itself, and providers are rolling out fixes through emergency maintenance and similar steps. Your part is to check which PHP version each site uses in the control panel, plan a switch if you are on 8.1 or older, and read your provider's notices on its official website. Do not log in through links in emails that claim to be from your provider.
QI run end-of-life PHP 8.1 or older. Will there be a fix?
The PHP team has not released official updates for 8.1 and older. Given the severity, it provided minimal source backports for 7.4, 8.0 and 8.1, intended for people who build from source. Distributions and long-term-support vendors may ship their own fixes, so check with your vendor, or move to a supported version (8.2 to 8.5). Support for 8.2 also ends on December 31, 2026.
QAre attacks already happening?
The PHP team cites a demonstrated exploit against mod_php in which an unauthenticated request triggers the attack before application code runs, but its announcement does not say whether exploitation has been seen in the wild. CISA said it had not observed exploitation as of its publication. Security companies and a CDN provider differ on whether they are seeing attacks. This site treats exploitation as unconfirmed.