October 2026 PHP vulnerabilities: affected websites and practical response

PHP runs code on the server hosting a website before sending the result to the browser. It can process a form or generate a page using a database. A company may therefore depend on it without seeing its name in its everyday tools. WordPress uses PHP, and the hosting environment determines the engine version.

On 21 October 2026, CERT-FR published an alert about CVE-2026-109618 and CVE-2026-109619. Its updated bulletin reports exploitation attempts against specific deployments. This warrants a prompt check, but does not establish that any particular website has been compromised.

For a small business, the first challenge is often responsibility. The agency editing the pages, the software vendor and the hosting company may be different organisations. Identify who can inspect and update PHP, then explicitly assign that person or organisation responsibility for following up this alert.

Remote code execution means an attacker can make a server run their instructions. In the scenarios covered here, a website account is not necessarily required. Exposure nevertheless depends on how PHP handles requests and on the application’s behaviour.

CVE-2026-109618 involves handling a shortage of memory. PHP may interrupt an operation while internal data is only partly prepared, then use that data during request cleanup. This memory corruption can enable code execution. With Apache and mod_php, the problem can occur before application code starts, limiting what a protection implemented only inside the application can achieve.

CVE-2026-109619 involves internal information that remains after its memory has been freed. A PHP process reused for another request may still act on this stale information. Conditions vary with configuration and the operations involved. An isolated crash therefore cannot diagnose this vulnerability.

CERT-EU lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected setups, and highlights the particularly high risk of mod_php. Using PHP-FPM does not remove the need to check patches. These distinctions help prioritise work; the server’s name alone does not establish that it is protected.

The table shows the first fixes for the two initial vulnerabilities in the maintained PHP branches listed by CERT-EU. Select the package appropriate to your environment, including security updates available when the work takes place.

Some providers backport fixes to older branches. Ask for their security advisory: the version number alone may be insufficient.

“We run PHP 8” is too vague: PHP 8.2.34 and PHP 8.2.35 have different status for these vulnerabilities. Request the complete number and, where applicable, the provider’s package revision. This table is not a general security guarantee and does not close the separate issue explained next.

PHP’s 23 October announcement adds CVE-2026-115560: it requires a session handler configured as php_binary or php_serialize, then switched to php at runtime, with upload progress tracking enabled. PHP considers this combination unlikely and plans a fix in its regular release cycle. The project suggests temporarily disabling session.upload_progress.enabled in affected cases.

In practice, ask the maintainer whether they assessed this additional issue even after patching the first two vulnerabilities. The configuration check should be done by someone who understands the application. Copying a setting without examining its context may change expected website behaviour.

Cybermalveillance.gouv.fr describes possible service interruption, data theft or destruction and, depending on the system’s connections, access to other systems. These are possible consequences of successful exploitation, not established damage to every PHP website.

To set priorities, ask a business question: what can this application reach? An ordering website, a portal holding client documents and an informational website have different stakes. Identify the data processed, technical accounts used and connected services. This helps decide urgency and any temporary access restrictions without waiting for a speculative estimate of financial losses.

Start with internet-accessible applications and continue the inventory of other PHP services. For each domain or application, record its host, technical owner, version and verification evidence. Include older websites that remain accessible: checking only the main website leaves the answer incomplete.

In WordPress, Tools → Site Health → Info provides technical information, including server details. It is a starting point for discussion with your provider. The hosting dashboard may also help; request confirmation for each environment actually in use.

PHP can load different configurations depending on its execution mode. The check must therefore identify the process serving the website: a terminal command or a check on staging does not, by itself, establish the production state. Our recommendation is to retain dated evidence identifying the domain, environment, active package and person responsible for checking it.

• Managed hosting: ask the provider for the specific website’s status, the patch reference and when it was applied.
• Company-managed server: have the administrator check each PHP service or container in use.
• Software delivered as a service: request the vendor’s confirmation of treatment; customers may not have access to the underlying engine.

The person responsible for hosting or the application should carry out the update. We suggest the following steps to organise the work. They distinguish an available patch, an installed patch and a service that has actually been checked.

If immediate updating is impossible, CERT-EU recommends considering isolation of exposed applications until the fix is applied and verified. The decision should account for operational needs and have a named owner. Temporary mitigations do not close the issue.

• Prepare: identify compatible components and have a usable backup before changing the environment. Test the migration on a copy where possible.
• Apply: install the provider’s fix or migrate to a maintained branch if needed. Updating the CMS and its plugins remains a separate operation.
• Reload: follow the provider’s procedure so active processes use the new files and settings; editing a configuration file does not prove that it has taken effect.
• Test: check the journeys that matter to the business, such as login, forms, uploads and a test order. A working homepage does not cover these uses.
• Record: note the active version, intervention time, tests completed and remaining exceptions. Assign a follow-up date to each unresolved item.

Fixing a vulnerability and handling a compromise are separate tasks. An update does not establish that no unauthorised access occurred earlier. If anomalies are found, ask the provider to examine the available evidence and state the period actually covered by their logs.

The NCSC incident response approach combines analysis, containment, threat removal and recovery. Keep a record of findings and decisions. An absence of alerts in incomplete logs does not establish an absence of intrusion; a restart alone is not an investigation either.

The consulted sources establish vulnerabilities and exploitation attempts. They do not identify your company as a victim or establish a data breach there. The final status should reflect the checks actually performed: resolved, not affected with supporting reasons, or still in progress with an owner and deadline.

Finish the exchange by requesting a short, verifiable account of the work. Another person should be able to take over without reconstructing the whole conversation. We recommend retaining the following information:

• Scope: which websites, applications and environments were checked? What remains to be examined?
• Fix: which version or package is active, and what evidence covers the two initial CVEs?
• Additional issue: has the configuration associated with CVE-2026-115560 been assessed?
• Verification: which journeys were tested, which logs were examined and what limitations remain?
• Follow-up: who owns the exceptions, and when will the status be checked again?