October 2026 PHP Security Update: What Website Owners Should Check

The short answer

• Ask your host or server administrator to verify the PHP build actually serving your website and whether it contains both fixes.
• Where an update is needed, agree the change, compatibility checks and deployment plan promptly.
• Confirm the updated runtime is active and test the important journeys afterwards.
• If there are signs of compromise, investigate that separately. A successful patch does not prove the site was never compromised.

Ask your responsible hosting provider or administrator to apply the official fix promptly; do not wait for a sales enquiry or a broader migration plan.

Need help turning the warning into a plan? Request a scoped PHP security assessment. Assessment findings and any remediation work are agreed separately.

Which PHP versions contain the fixes?

The first fixed releases in the supported upstream branches are:

A distribution or long-term-support vendor may provide a backported fix under a different package version. Ask for the applicable vendor bulletin and package evidence. PHP 8.1 and older are outside normal upstream support; an exceptional patch does not restore ongoing support. PHP’s release guidance.

PHP 8.2: separate the immediate patch from end-of-life planning

PHP 8.2 reaches the end of upstream security support on 31 December 2026. Applying its current security fix and planning a move to a supported branch are separate decisions. Do not postpone the immediate fix while designing a larger migration; agree both priorities with the responsible operator. PHP supported-version schedule.

What does PHP2Shell mean in plain English?

Both issues involve PHP’s handling of internal memory during exceptional request processing. Under applicable conditions they can permit remote code execution.

CVE-2026-109618 concerns interrupted initialization during an out-of-memory condition. The official advisory describes a demonstrated mod_php path that runs before application code. Other deployment paths have different prerequisites. PHP OOM advisory.

CVE-2026-109619 concerns a worker retaining references to request memory after it has been released. A later request can encounter that stale state. Configuration and reachable application behavior affect the relevant paths. PHP stale-state advisory.

These details are a reason to examine the runtime and deployment, rather than trying to infer exposure from a homepage or a platform name.

Does this affect WordPress, WooCommerce or Laravel?

These applications commonly run on PHP, so the server runtime needs attention alongside the application. Updating WordPress, a plugin or a Laravel dependency does not, by itself, establish that the PHP runtime has received these fixes.

Cloudflare’s report makes the distinction explicit: the underlying PHP software must be updated by the responsible administrator or hosting provider. Cloudflare’s PHP2Shell guidance.

For a WordPress or WooCommerce site, identify the hosting account and runtime used by that site. For Laravel or custom PHP, include separate workers or deployments that form part of the application. A React frontend can also call a PHP backend; the visible frontend alone does not settle the question.

Has it been exploited?

AWS reports exploitation attempts in its MadPot telemetry from 17 October 2026, before public disclosure, followed by broader exploitation activity. It also says the success of those early attempts against real-world systems was unclear. AWS threat-intelligence report.

Observed attacks warrant timely action. They do not establish that your business, your host or a named website has been compromised. Do not substitute a general headline for evidence about your own environment.

Five questions to send your hosting provider

You do not need to guess your PHP configuration. Ask for a response that your developer can check:

1. Which PHP package and build currently serve web requests for our domain and relevant subdomains?
2. Does that build include the fixes for both CVE-2026-109618 and CVE-2026-109619? Please identify the vendor advisory or package release.
3. Which environments and components are covered, and which remain our responsibility?
4. Has the update been activated across the relevant workers or instances, rather than only made available in the control panel?
5. Are there compatibility concerns or actions we must take, and what evidence confirms the deployment?

A statement such as “the latest version is available” does not answer whether your particular website is using it. Keep the response with your maintenance records and follow up on any missing component.

Also ask where the provider’s responsibility ends. For example, hosting provider Prostack’s incident guidance separates its PHP updates from customers’ responsibility for application, theme and plugin compatibility. Your own provider’s scope may differ. Prostack’s hosting guidance.

Before changing PHP in a hosting control panel

A version selector is a deployment action, not a compatibility assessment. Your existing developer or provider should agree a short change plan:

• Confirm the intended patched package and the person responsible for applying it.
• Check application, framework and extension requirements against the proposed change.
• Establish the backup and recovery route, including who can restore it if needed.
• Use a representative test environment where available and define the production change window.
• Decide what will be checked immediately afterwards and who accepts the result.

Do not assume that selecting a higher version automatically fixes every component or that a backup has been tested merely because a backup job ran. Record those distinctions in the plan.

What should you test afterwards?

Choose checks that reflect the business, rather than relying on the homepage loading:

• For an online store: product selection, cart, sandbox payment, confirmation and relevant order integrations.
• For a lead-generation website: enquiry forms, validation, notifications and the destination of a successful submission.
• For an account-based application: permitted test logins, account recovery and representative role-specific actions.
• For a custom backend: agreed API operations, background jobs, scheduled tasks and integration error handling.

Use test data and approved sandbox methods. Do not charge a real customer or expose their information to verify a flow. Keep results against the agreed scope, including failures and anything that could not be checked.

Can a WAF replace the PHP update?

No. Cloudflare describes its WAF protections as an additional defensive layer and still advises customers to patch PHP. Coverage also depends on the actual request path and configuration. Cloudflare’s protection notice.

Configuration workarounds have limits and can affect availability or functionality. Have the responsible operator review any temporary control against the current advisory and your application. Avoid copying emergency settings into production without understanding their consequences.

When patching needs a separate investigation

Unexpected files, unusual process activity or other suspicious evidence require a different conversation from a routine compatibility update. AWS recommends reviewing history from at least 17 October for this incident, extending the period where evidence warrants it. AWS investigation guidance.

Agree how to preserve relevant evidence and who will investigate. Missing logs or a clean sample limit what can be concluded. A completion note should distinguish “the agreed runtime is patched” from “we investigated suspected compromise”; those are different findings.

Frequently asked questions

Is PHP-FPM unaffected?

No. Do not use the deployment name as an exemption. The technical sources describe different FPM attack paths and levels of validation. The PHP Foundation reports application-level FPM remote code execution, while the OOM advisory qualifies the demonstration for that specific SAPI. The responsible administrator should use the current advisories for the actual environment. PHP Foundation explanation.

Does a newer version shown in a terminal prove the website is patched?

Not necessarily. A command-line runtime and the web-serving runtime can be different. Ask for evidence tied to the actual site and deployment rather than a version screenshot with no context.

Does the “70% of websites” headline mean those sites are compromised?

No. Technology-usage estimates are not measurements of compromise. A website’s actual configuration, patch status and evidence must be checked individually.

Should I rebuild my website because of this disclosure?

A rebuild should follow from specific application constraints, not a security headline. First establish whether the needed work is a provider patch, a supported runtime update, compatibility repairs or a more substantial migration.

Get a clear next step for your website

If you cannot get a clear answer about your runtime, or need help planning an update around your application, request a PHP security assessment.

Share the website, hosting provider if known, and the concern you want checked. CV Infotech will discuss scope and price before assessment work begins. Any implementation, testing or incident investigation needs an explicitly agreed scope.

Please do not send passwords, API keys, customer records or raw logs through the enquiry form.

Research note: This article reflects the primary sources checked on 22 October 2026. Advisories can change. It is general guidance, not a finding that your website is affected, safe or compromised.