PHP’s Critical Security Release (October 2026): Two Unauthenticated RCE Flaws, What They Hit, and What a UAE Business Must Do

Most business websites in the UAE run on PHP, whether the owner knows it or not: WordPress, WooCommerce, Laravel, Magento, Joomla and most hosting control panels all depend on it. On 21 October 2026 the PHP project shipped an emergency security release for two critical flaws that let an attacker run code on a web server without logging in. The hosting world is still catching up: distribution and control-panel packages are arriving at different speeds, and exploitation attempts have already been reported. This article explains what the flaws are, which servers are most exposed, and what a UAE business should do today, in plain language and without exploit detail.

Quick Answer

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Both can allow unauthenticated remote code execution, and the PHP team states there are no complete mitigations other than updating. Every PHP installation that serves web requests is at risk; Apache with mod_php is the highest. PHP 8.1 and older are out of support and need a vendor backport or a migration. If you are on our shared hosting, we handle it. If you run your own VPS or dedicated server, patch it today or ask us to.

What the two flaws are

CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory, it aborts the current request by jumping straight out of whatever it was doing. In some situations that jump happens while the request’s internal memory is only partly set up. PHP then runs its normal clean-up on that half-built state, and the clean-up can be steered into executing code. The practical trigger is a specially shaped multipart (form upload) request that pushes PHP to its memory limit while staying within the usual post_max_size. On Apache mod_php this happens before any application code runs, so no plugin, theme or framework can protect you. The advisory confirms full unauthenticated remote code execution against mod_php with default limits; PHP-FPM is susceptible by source analysis, and FrankenPHP and LiteSpeed’s LSAPI are likely affected.

CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp). A PHP worker process serves many requests in a row. Some internal state belonging to one request (error details, session upload data, extension state) is supposed to be reset before that request’s memory is freed. If the request is cut short by a fatal error, a timeout or an out-of-memory condition, the reset is skipped. The next request on the same worker can then touch that freed memory before normal initialisation replaces it, a classic use-after-free. Two early “consumers” are confirmed: configuration warnings raised before request start-up (for example from .htaccess php_value lines on mod_php) and the session upload progress feature, which is on by default. Remote code execution is confirmed on mod_php (via PHP 8.5’s fatal error backtraces) and on PHP-FPM (via session upload progress).

What they have in common. Both are flaws in PHP’s core, not in any application, and both affect every version below 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The ChangeLog records a single core fix for both, “Avoid state corruption via bailout”. The advisories are explicit that hiding errors with error_reporting, display_errors or the @ operator does not help, because the dangerous state is touched before PHP decides whether to show the error.

Who is exposed

PHP’s own advisory lists all installations serving web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is not equal across them.

Shared hosting versus your own server. On a managed shared plan, the hosting company owns the PHP build and must patch it. On a VPS or dedicated server the responsibility is yours, even if the panel was installed by someone else. If you are not sure which you have, our guide to WordPress hosting versus cPanel hosting explains the difference.

PHP 8.1 and older. PHP 8.1 reached end of life on 31 December 2025; 8.0 and 7.4 ended years earlier. PHP provided minimal source backports for 7.4, 8.0 and 8.1 because of the severity, but those are for people building from source. If your site still runs on these, ask your vendor for a backported package today and plan the migration this quarter. PHP 8.2 itself reaches end of life on 31 December 2026, so 8.3 or 8.4 is the sensible target.

Is it being exploited? Qualys reports that Amazon Threat Intelligence and Cloudflare have observed attack traffic targeting these flaws, and that Patchstack has received exploitation reports from hosting partners. Treat this as active, not theoretical.

What to do today

1. Find every PHP that serves web requests. Running php -v on the command line often shows a different binary from the one your web server uses. Check the handler in your panel (cPanel MultiPHP Manager, Plesk PHP settings) or a phpinfo page, and remember that a server can run several PHP versions at once. Count each one.
2. Update to the fixed version or the vendor backport. The targets are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution and LTS vendors received the patches in advance, so a backported package may keep an older version number; check your vendor’s advisory rather than the number alone. On cPanel and CloudLinux servers, for example, the fix shipped on 21–22 October as a backport that keeps the old version number (CloudLinux advisory), so verify with the package changelog (rpm -q –changelog on the PHP package, looking for the CVE ids) rather than with php -v; CloudLinux also pushed Imunify360 rulesets 8.83–8.85 that block the public exploit traffic as a virtual patch, which is not a substitute for the update. The PHP team also asks users of the volunteer remirepo packages to switch to distribution packages or source builds, since that repository did not have updates on release day.
3. Restart every PHP worker. A new binary on disk changes nothing until Apache, PHP-FPM or LiteSpeed is restarted. Restart all pools, not just one site.
4. If you cannot patch yet, apply the interim mitigations. They reduce exposure but do not make the server safe. For CVE-2026-109618: set memory_limit=-1 administratively (php_admin_value in the FPM pool or Apache config) so no site can set a finite limit back; keep post_max_size low (8M where uploads are not needed, 32M where they are) with upload_max_filesize below it; limit request size, field count, multipart parts and headers at the web server or proxy; do not use RLIMIT_AS or RLIMIT_DATA. For CVE-2026-109619: set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, both in startup configuration (not ini_set or .user.ini), then restart workers; remove invalid or deprecated INI directives applied per request; optionally set pm.max_requests=1 on FPM if performance allows.
5. Verify. Load a phpinfo page or check the handler for each site and confirm the version string is one of the four fixed versions, or the vendor’s patched build. Confirm the workers restarted after the update.
6. Restore memory_limit after patching. memory_limit=-1 is a stop-gap. Once the patched build is live, put a sensible limit back so one runaway script cannot take down the server.
7. Look for signs of compromise. Unknown files in upload folders, new admin users, cron jobs you did not create. Our checklist of signs your website is hacked covers what to check and in what order.

What BIGBANG ITS is doing

Our shared and managed servers run cPanel EasyApache and CloudLinux PHP builds. On the morning of 22 October 2026 the vendor packages carrying the fixed versions were not yet available, so we applied the interim mitigations that are safe on shared servers (disabling session upload progress and fatal-error backtraces) on every PHP build on 22 October and restarted all PHP workers. By midday the cPanel EasyApache builds on our main shared server had received the backported fix (verified in the package changelog) and were restarted; the remaining builds stay under the interim mitigations until their packages arrive, and our team is checking the vendor channels hourly. Customers on our shared and managed plans need to do nothing. Customers running their own VPS or dedicated server must patch themselves; if you would rather we did it, our annual maintenance contract covers exactly this kind of emergency work, including the verification step.

Three decisions to make this week

• Who owns PHP on each of your sites? Write it down: provider-managed, your own server, or an agency’s server. Anything without a clear owner is the first thing to fix.
• Do you still run PHP 8.1 or older? If yes, the backport is a bridge, not a destination. Schedule the upgrade to 8.3 or 8.4 before year end.
• Could you rebuild if a server were compromised tonight? A patched server is the goal, but a tested backup is the safety net. Our website backup and recovery plan explains what a usable backup looks like.

Frequently Asked Questions

My site is on WordPress. Does updating WordPress fix this?

No. Both flaws are in the PHP engine, not in WordPress, its plugins or its themes. On mod_php the attack completes before WordPress even loads. The fix is a new PHP build on the server, installed by whoever manages that server. Updating WordPress remains good practice, but it does not close these two holes.

My hosting panel shows PHP 8.3.35. Is that safe?

Not by itself. The fixed version for the 8.3 branch is 8.3.36. However, some distributions and control-panel vendors ship backported fixes under an older version number, so check the vendor’s own advisory or package changelog. If the package was built before 21 October 2026, it does not contain the fix.

Is a firewall or WAF enough while I wait for the patch?

It helps but it is not enough. Cloudflare has reported attack traffic including attempts to evade its protections, and the PHP team says only updating is a complete fix. Use the WAF to block multipart requests on sites that do not need uploads, apply the interim mitigations, and patch as soon as packages arrive.

Sources

• CloudLinux: PHP CVE-2026-109618 and CVE-2026-109619 — package status, Imunify360 rules and verification (accessed 2026-10-22)
• php.net: Upcoming Critical PHP Security Release, 20 Oct 2026 (accessed 2026-10-22)
• php.net: Security advisory, critical remote code execution vulnerabilities, 21 Oct 2026 (accessed 2026-10-22)
• php.net: active releases (8.2.35, 8.3.36, 8.4.27, 8.5.12) (accessed 2026-10-22)
• php.net: PHP 8 ChangeLog (accessed 2026-10-22)
• php.net: Unsupported branches (accessed 2026-10-22)
• GitHub advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618) (accessed 2026-10-22)
• GitHub advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619) (accessed 2026-10-22)
• Qualys: PHP announces critical security release for two vulnerabilities (accessed 2026-10-22)

Where We Are

BIGBANG ITS has planned and run technology for UAE businesses since 2003, headquartered at the Sharjah Research, Technology and Innovation Park with a branch in Business Bay, Dubai. Support runs 24/7 and the office is open Saturday to Thursday, 09:00–18:00 Gulf time. If you are not sure which PHP build serves your site, contact us or message us on WhatsApp.