PHP released emergency security updates on 21 October for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0, and PHP says there are no complete mitigations: updating is the only safe choice.
India’s CERT-In rated the flaws critical on 21 October and, a day later, issued an advisory to MSMEs saying multiple reports confirm large-scale exploitation in the wild. On 26 October, CISA added both flaws to its Known Exploited Vulnerabilities catalog.
The patch exists for four PHP branches, but a large share of the web runs older versions that the project no longer updates.
What happened, and when?
The flaws moved from advance notice to confirmed exploitation in six days. Here is the sequence, with each step’s source:
- 20 October: PHP gave advance notice of a critical release for 21 October. The same day, details of the flaws leaked online, and watchTowr confirmed remote code execution.
- 21 October: PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory. CERT-In published vulnerability note CIVN-2026-0510, rated critical.
- 22 October: CERT-In issued advisory CIAD-2026-0052 to MSMEs, stating that multiple reports confirm large-scale exploitation in the wild.
- 23 October: Beazley Security reported broad exploitation attempts. It also relayed VulnCheck’s report of a working exploit that bypasses ASLR on x86-64 systems against unpatched PHP 8.4 releases.
- 23 October: PHP published an informational advisory on session upload progress, a related issue (CVE-2026-115560) with a full advisory due at the next release.
- 26 October: CISA added both CVEs to its catalog. The same day, PHP published updated Windows builds with a Brotli fix for a separate vulnerability, CVE-2026-111497.
Who is affected?
PHP says the risk applies to all installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where it has demonstrated an exploit that triggers before any application code runs.
Because the flaws sit in the PHP engine, Magento, Shopware and WooCommerce stores are affected even when their own code is clean. CERT-EU’s operational notes add that PHP is also embedded in appliances, network devices and management interfaces, where administrators may not be able to update it directly.
The scale is large. PHP is used by 69.2% of websites with a known server-side language. Among PHP sites where a version is detected, 26.6% run PHP 7, 7.7% run PHP 5 and 0.1% run PHP 4, which together are about a third. The project no longer updates these versions.
What are the update options?
Only four branches have an official fix. The table shows the status of each:
| PHP version | Status | Action |
| 8.5 | Fixed in 8.5.12 | Update |
| 8.4 | Fixed in 8.4.27 | Update |
| 8.3 | Fixed in 8.3.36 | Update |
| 8.2 | Fixed in 8.2.35, end of life on 31 December 2026 | Update, and plan a move to a supported branch |
| 8.1, 8.0, 7.4 | No official release; the PHP team published minimal source backports | Use a distribution or LTS vendor package, or the backports |
| 7.3 and older, including PHP 5 | No fix available | Upgrade to a supported version |
Linux distributions have shipped fixed packages. On Debian, Ubuntu and RHEL-family systems, the vendor usually keeps the upstream version number and raises only the package revision, so the version string alone does not show whether a server is patched. Reloading PHP-FPM or restarting Apache is needed for the fix to take effect.
Which stopgaps does PHP list?
For teams that cannot update at once, PHP lists measures that reduce exposure to specific attack paths but do not make an installation safe:
- Disable session upload progress: set session.upload_progress.enabled=0 and restart every worker
- Limit memory failures: set memory_limit=-1 in a way applications cannot override, and keep post_max_size low
- On PHP 8.5: set fatal_error_backtraces=0
What does it mean for businesses in India?
CERT-In directed its advisory at small businesses. Its MSME advisory asks organizations to take three steps:
- Identify PHP use: check whether the website, hosting account, content management system or business application uses PHP, and ask the hosting provider or software vendor if the version is unknown
- Apply updates: move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the vendor’s fixed package
- Address unsupported versions: PHP 8.1 and earlier no longer receive updates from the PHP project
The duty to patch sits with whoever runs the server. On a self-managed server, that is the customer. On a hosting plan with management, it depends on what the plan covers, so the scope is worth confirming in writing.
Indian rules raise the cost of leaving a server exposed. DPDP requires a data fiduciary to take reasonable security safeguards to prevent a personal data breach, and most obligations start on 13 May 2027.
CERT-In’s 2022 directions require covered entities to report listed cyber incidents within six hours and to keep logs for 180 days within India. Whether a particular compromise triggers either rule depends on the facts.
What to watch next
Four developments will show how far the exposure spreads:
- The full advisory for CVE-2026-115560, which PHP will publish with its next regular release
- Exploitation reports. Whether attackers move from attempts to widespread compromise of unpatched servers
- Older-version fixes. How quickly distributions and LTS vendors cover PHP 7.4, 8.0 and 8.1, and what happens to PHP 7.3 and older
- PHP 8.6. Release candidate 5 is planned for 5 November, and the fixes are already in RC4
For now, the picture is split. Supported PHP 8 versions have a clear fix, and a large part of the web does not. The practical question for any team is which version each server runs and who is responsible for updating it.
