PHP vulnerabilities of October 2026: what a website risks and what to ask your host

Exposed

• 8.2, 8.3, 8.4 and 8.5 not yet updated
• 8.1 and earlier: no official updates

Updating WordPress, plugins or the theme changes nothing.

→ update PHP

Fixed (21 October 2026)

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

PHP must be restarted after the update.

What happened with PHP in recent days?

On 21 October 2026 the PHP project published an urgent security advisory with fixes for two flaws that allow remote code execution without authentication. PHP is the language behind WordPress, many web applications and a large share of company websites.

The two flaws were given the identifiers CVE-2026-109618 and CVE-2026-109619. A CVE is the catalogue number used to refer to a known vulnerability. Both score 9.2 out of 10 on the CVSS v4.0 scale, which measures severity: that is the critical range.

According to watchTowr, details circulated on social media on 20 October, before the planned disclosure date, and on 21 October the company observed exploitation attempts on its network of decoy systems. Rapid7, on 22 October, says it had not seen successful large-scale attacks but had received several reports of attempts. Public demonstrations already exist, each valid only for a specific combination of operating system, PHP version and web server.

What can these flaws be used for?

They let an attacker make the server run their own program, with the same rights as the website. From there they can read the site's files and database passwords, change pages or install malicious software.

The mechanism is technical, but you can picture it like this. PHP handles each visitor's request as a case file to open, work on and close, and tidies the desk when it closes.

• CVE-2026-109618: if PHP runs out of memory while it is still opening the file, it stops halfway. The final tidy-up then treats unprepared material as valid, and a well-built attack can exploit that. According to Rapid7, a request with many attachments (multipart) can exhaust memory even while respecting the configured limits.
• CVE-2026-109619: a piece of information from a case already closed stays on the desk and points to memory that has been freed. The next request, handled by the same process, can use it before it is cleared.

According to PHP's advisory, the highest risk is with Apache in mod_php mode, where a demonstrated attack succeeds before any site code runs. With PHP-FPM, the most common setup on recent servers, the advisory and Rapid7 report no complete exploit, but the code is still vulnerable.

Who is affected, and what about my site?

Every PHP installation that answers web requests is affected: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The most important point for a site owner: the flaw is in PHP, not in the site. According to Codeable, WordPress.org has stated that no WordPress update is required or planned. Updating WordPress, plugins or the theme changes nothing: PHP on the server must be updated.

Things differ a lot depending on where the site lives:

• Shared or managed hosting: PHP is updated by the provider for all customers together. SiteGround, for example, said it applied the fixes to all its servers on 21 October. Other providers have to be checked one by one.
• Virtual private server (VPS) or dedicated server: the update falls to whoever administers it, which may be your web agency or a freelancer. If nobody does it, nothing changes.
• Site on an old PHP version: PHP 8.1 and earlier no longer receive updates from the project. For 7.4, 8.0 and 8.1 PHP published minimal source-code fixes, and some Linux distributions offer adapted versions. For 7.3 and earlier there is no fix at all. Also, PHP 8.2 reaches end of support on 31 December 2026.

What should I ask whoever runs my hosting?

Ask precise questions and expect verifiable facts, not generic reassurance. If an agency or freelancer manages your site, these questions are for them; with shared hosting, they go to the provider's support.

1. Have you applied the 21 October 2026 fix to the server where my site lives? When, and from which package or version?
2. Which PHP version does my site use? The visible number can mislead: Linux distributions often fix the code without changing the number, so ask whether the fix is included in the package.
3. Was PHP restarted after the update? A process that is already running keeps using the old code until it is restarted.
4. If I use PHP 8.1 or earlier, what is the plan? Moving to 8.3 or 8.4 with a trial period, or a package with a fix adapted by a vendor.
5. Is there a filter in front of the site? A service such as Cloudflare can block part of the attacks, but Codeable warns it is no substitute for updating: an attacker can reach the server directly without going through the filter.
6. Can you check the logs of recent days for signs of intrusion? Rapid7 notes that the absence of errors in the logs does not prove the site was safe.
7. Who tells us, and how fast, next time? It is better to agree a maximum time for critical fixes, for example a few days.

What to do now, and what if you cannot update?

PHP's answer is clear: updating is the only complete remedy, and no setting makes an installation safe. Temporary measures only reduce exposure.

For a site on shared hosting:

1. Check the provider's status page or announcement and, if you find nothing, write to support with the questions above.
2. If the control panel lets you choose the PHP version and you are on 8.1 or earlier, plan the move to a supported version. Back up and test the site first.
3. Do not change server settings yourself: they belong to the provider.

For whoever administers a server:

1. Install the updated package and restart all PHP processes.
2. Until that is possible, PHP's advisory lists temporary measures: disable session.upload_progress.enabled in the server configuration (not with ini_set() or .user.ini, which act too late) and, on PHP 8.5, disable fatal_error_backtraces. Lower limits on request size are also needed, for example post_max_size at 8M if the site receives no files.
3. Where a server cannot be updated at once, restrict access from the Internet. Codeable reports that WordPress.org and the UK's NCSC suggest, for self-managed servers, taking the site offline as well.

session.upload_progress.enabled = 0

Frequently asked questions

Would I notice if my site had already been compromised?

Not necessarily. According to Rapid7, missing entries in the logs do not prove a site was safe. If your provider did not fix the server before 21 October, ask for a check of recently modified files and of new administrator accounts.

Is a firewall or a service like Cloudflare enough?

No. Codeable reports that Cloudflare enabled protection rules on all plans, and it can help as an extra layer. But PHP's advisory names updating as the only complete solution, and a server that can be reached directly stays exposed.

My site runs PHP 8.2: am I fine?

Only if the version is 8.2.35 or later, or if the provider confirms an equivalent fix. Keep in mind that PHP 8.2 reaches end of support on 31 December 2026, so it is worth planning a move to a newer version.

Do I need to update WordPress or plugins?

Not for these flaws: they are in PHP. Updating WordPress and plugins remains good practice, but it does not solve this problem.

Sources

• PHP.net: Security advisory, critical remote code execution vulnerabilities, update now (21 October 2026)
• Rapid7: CVE-2026-109618 and CVE-2026-109619, Critical Unauthenticated Remote Code Execution in PHP
• watchTowr: PHP2Shell FAQ, CVE-2026-109618 & CVE-2026-109619 Fixes
• Codeable: PHP Security Release on 21 October 2026, what WordPress site owners need to do
• SiteGround: critical PHP vulnerabilities, October 2026

Need a hand at your company?

I provide IT and AI consulting for small businesses and professionals, in Apulia and remotely.

Services

Article written with AI assistance from the sources listed and checked by me before publication.