PHP security update: check and fix your website

A PHP security update starts with identifying the runtime that serves your website, applying a verified fix and checking the business journeys that depend on it. Ask your hosting provider for evidence of the deployed package and running service. Record who will act on systems still awaiting a fix.

Which PHP vulnerabilities need attention now?

As of October 2026, checked on 23 October, CVE-2026-109618 and CVE-2026-109619 are critical PHP runtime vulnerabilities. They can permit unauthenticated remote code execution under relevant conditions. The first involves memory handling during an out-of-memory failure; the second involves internal state surviving beyond the memory it references. The PHP Foundation's incident explanation describes both mechanisms and the differing demonstrated attack paths.

An affected installation needs action, but its version alone does not establish that someone has accessed your data. Keep the remediation decision separate from any conclusion about compromise. Ask your operator to assess the actual configuration, exposure and available evidence.

Which releases contain the original fixes?

The PHP project advisory identifies these initial fixed upstream releases for the two CVEs:

These are reference versions, not instructions to downgrade a newer fixed installation. For distribution packages, obtain the vendor's advisory and package revision. PHP 8.1 and older lack normal upstream maintenance, although some vendors provide backports and PHP supplied limited source backports for 7.4, 8.0 and 8.1. Have a qualified maintainer verify that route and plan a supported-version migration.

What changed on 23 October?

PHP also published a session upload progress follow-up for an unusual configuration and application-code combination, associated with CVE-2026-115560. It recommends disabling session upload progress pending the next regular bugfix release; applications that never change their session serialisation handler at runtime can keep the feature enabled. Ask your maintainer to review that separate notice even after the original update, and retain an already-applied mitigation where the advisory says to do so.

How do you identify the PHP serving your website?

Build a small inventory with the operator before accepting an update confirmation. For each production hostname, record the hosting account, application, runtime source and responsible person. Add reachable staging sites, subdomains and older applications sharing the account. Mark unknown entries for investigation instead of guessing their status.

Use one row per deployed workload. A brochure website, staff portal and scheduled import may need different checks even when one supplier manages them. Ask whether the server uses distribution packages, a control-panel runtime or a container image, then request evidence for that installation method.

A terminal version check is one inventory item. Have the operator establish which runtime handles a request to the website and whether separate jobs use another installation. Request the deployed image reference for containers and the package revision for package-managed servers. Avoid publishing a diagnostic page that exposes configuration; obtain the evidence through the operator's controlled maintenance process.

Our Saudi website-hosting selection guide helps you separate hosting responsibilities from application maintenance. Use the inventory to name both owners and the person who can approve a service interruption.

What should you ask your hosting provider?

Ask for a written response covering the affected workloads, the fix and its activation time. “The website is updated” leaves the package source and running processes unanswered. Keep the provider's answer alongside the deployment record so another maintainer can check it later.

Here is a suggested request you can adapt:

Please confirm the PHP package or image serving each listed website, the vendor advisory that establishes the fix, and when the running processes started using it. Include separate background jobs, test results and any workloads still pending. Please review the 23 October PHP follow-up and state the next action and owner for each exception.

Give the provider your public website address and hosting reference through the normal support channel. Arrange any privileged access through an agreed secure process. The initial enquiry should contain no passwords, API keys or customer records.

If two suppliers share responsibility, ask them to agree the handover point. The host can supply runtime evidence; the developer can test application behaviour. The business owner decides the acceptable maintenance window and identifies the functions that must be checked before reopening.

Does a CMS or framework update resolve this incident?

The PHP runtime and your application have separate update paths. As of October 2026, WordPress's incident notice says no WordPress update is required or planned for these specific flaws. Its Site Health information can help identify the PHP version, but the host still needs to establish the applicable runtime fix.

Drupal's PHP notice likewise directs owners to update PHP themselves or coordinate with the host. Ask your maintainer to track application compatibility alongside the server change. Keep the incident ticket specific enough to distinguish PHP remediation from unrelated plugin, theme or framework maintenance.

For an older custom application, request two decisions: the compatible fix available now and the work needed to move to a supported runtime. Record any blocker, its owner and the next review. Our guide to staging an older system's replacement covers longer-term modernisation; an emergency update still needs its own bounded scope and acceptance checks.

How do you prepare the change and recovery plan?

Agree the update path, recovery preparation and customer checks before the operator changes production. This is a proposed work plan, not a claim that a particular hosting package includes every task.

1. Confirm the scope. List affected hosts and applications. Name the package or image source and the person applying the change.
2. Prepare recovery. Locate the backup, confirm access and write down how the responsible team would restore it. Identify which new orders or submissions could need reconciliation after a restore.
3. Check compatibility. Test the proposed runtime against the application's important functions in a suitable protected environment where feasible. Record any unavailable test explicitly.
4. Agree the interruption decision. Identify who may pause traffic, what customers will see and how the business team receives updates.
5. Deploy and verify. Collect running-runtime evidence and results for the agreed tests before closing the change.

A rollback decision also needs a security review. Returning to a vulnerable runtime may restore functionality while recreating the exposure. Agree whether the safer response is containment, a corrected deployment or recovery into a fixed environment. Do not describe an untested backup as a proven recovery route.

For a site whose maintenance ownership is unclear, the website scope and ongoing-cost guide provides questions to include in the next work order. Keep the immediate patch separate from a wider redesign discussion.

What if the fix cannot be applied promptly?

Escalate the unresolved exposure to the operator and a named decision-maker. As of October 2026, CERT-EU's remediation guidance recommends urgent updates and considering isolation of public-facing resources when immediate patching is not feasible. Its temporary measures address particular attack paths and do not replace the update.

Have the operator assess current official guidance against the actual system. A CMS maintenance screen may still invoke the application, so ask how any proposed containment prevents access to the affected runtime. Write down the control, the remaining exposure and the evidence required before removing it.

Avoid copying isolated configuration values from a social post. Ask the maintainer to assess the full advisory and its compatibility and availability implications. Record a deadline for the next status review and an escalation contact if the agreed action has not happened.

What evidence should close the update ticket?

Close the change when the team can show both runtime remediation and application checks, with remaining work assigned. The following table is a suggested acceptance record. It describes checks to request, not results from a customer system.

Choose tests that reflect how customers use the site. Submit an Arabic contact form and verify its arrival in the agreed inbox, then repeat the relevant English flow. For a store, use an authorised test purchase and check the order, payment confirmation and stock handling. Test an ordinary account as well as an administrator where access rules matter.

Record the test time, role, expected outcome and observed result. A successful homepage request cannot demonstrate checkout behaviour. After the change, agree who reviews application errors and failed jobs, and when they will report. Describe an untested function as pending so the next person knows where to continue.

How should you respond to suspected compromise?

Preserve evidence and involve the responsible security specialist before treating the issue as routine maintenance. NCSC's PHP response guidance recommends assessing for compromise when an affected system could not be promptly updated or disabled. Patching alone does not establish that a previously compromised installation is clean.

Ask the specialist to evaluate unexpected administrator accounts, changed files or unexplained connections in context. These are reasons to investigate, not proof of this particular exploit. Retain relevant logs and change records, control access to them and avoid deleting evidence to make a dashboard appear normal.

Agree investigation, credential changes, recovery and reopening with the incident lead. Keep those decisions separate from the routine update ticket. Any customer or regulatory communication needs the business's own authorised review of the findings; this guide makes no finding about your website.

What should you do next with TecnoStack?

Start with a named owner and a verifiable change record. Gather your website address, platform, hosting provider and PHP version if known. Identify the business functions that need testing and tell us if you suspect compromise.

TecnoStack can help assess the installation, agree the work, apply a compatible fix or plan the necessary upgrade, verify the active runtime and test important functions. Our website hosting and maintenance discussion also establishes which maintenance responsibilities belong to your hosting plan. We document the changes and agree any further hardening and follow-up.

Request a PHP security assessment with those details. We confirm scope, timing and price after review; investigation, malicious-code cleanup, major application changes and ongoing maintenance need separate agreement where required.