A small update. A critical difference.
Your website can look normal while the software running behind it needs an urgent security update. This briefing explains the October 2026 PHP vulnerabilities, the fixed releases, and what website owners should check with their hosting provider.
What happened in the October PHP security release?
On 21 October 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619. These could allow an attacker to execute malicious code on vulnerable servers without signing in. European cybersecurity authorities urged organisations to identify affected systems and apply the updates immediately. Read the ENISA security statement.
The vulnerabilities involve PHP’s handling of internal memory and request state. Under vulnerable conditions, attackers could turn that faulty handling into remote code execution.
This is a server-level problem. Updating website text, changing a password, or installing a theme update does not repair the underlying PHP runtime.
A successful server compromise could put website files, connected data, and business operations at risk. However, the existence of a vulnerability does not establish that a particular website has been compromised.
Which PHP versions contain the fixes?
The PHP security advisory names the following fixed releases. Your hosting provider may supply equivalent fixes through vendor-maintained packages, so ask about coverage for both vulnerabilities rather than relying only on a displayed version number.
PHP 8.1 and older no longer receive regular security releases from the PHP project. Some distributions and long-term-support vendors provide backported fixes; otherwise, migration to a supported branch is necessary. PHP also provided minimal source backports for older branches to assist maintainers. Check the official PHP security advisory.
These are the releases identified in the October advisory, not a promise that they will remain the latest versions. Use your provider’s current supported security packages.
What changed in the follow-up advisory?
PHP published guidance about an additional, unusual remote-code-execution path involving session upload progress. It requires a particular configuration and application behaviour, including changing the session serialization handler at runtime.
PHP recommends setting session.upload_progress.enabled=0 until the next regular bugfix release. Applications that never change the serialization handler at runtime can keep the feature enabled. Ask your developer or host to assess this guidance for your installation. Read PHP’s follow-up advisory.
Does this affect WordPress and WooCommerce?
WordPress runs on PHP, so its hosting environment needs attention. The WordPress project confirms that these vulnerabilities are not specific to WordPress and that no WordPress core update is required or planned to fix them. The PHP runtime needs the security update.
You can find the PHP version reported by WordPress under Tools → Site Health → Info → Server. Your hosting control panel may also show it. Confirm vendor patch status with your host. Read the WordPress security notice.
For a WooCommerce store, include checkout, payment callbacks, customer accounts, and order processing in your checks after the hosting update.
What should website owners do now?
Identify every PHP environment
Include your main website, subdomains, staging sites, older applications, and background services. Different sites under the same hosting account may use different PHP versions.
Confirm patch coverage with your host
Ask about the actual runtime serving your website, including vendor backports and the 23 October follow-up. A version available in the control-panel menu is not evidence that every website uses it.
Apply the supported update promptly
Coordinate with your provider or developer. Maintain a current backup and check compatibility while treating this as an urgent security update.
Test important business functions
Check forms, email delivery, sign-in, checkout, payment processing, uploads, bookings, connected services, and scheduled jobs. A homepage loading successfully is only one part of verification.
Review suspicious activity
Ask the responsible team to review unexpected file changes, unfamiliar administrator accounts, unusual redirects, and relevant logs. Patching does not automatically remove malicious files or undo an earlier compromise.
Where immediate remediation is not possible, ENISA recommends considering isolation of exposed applications from public networks until fixes can be applied. See ENISA’s response guidance.
Is a web application firewall enough?
A web application firewall can provide another layer of protection, but it should not replace the PHP update. Temporary controls need to match your hosting environment and application. Ask your provider to assess mitigations and their limits using the PHP advisory.
What does this mean for Nexstarc CMS?
For any Nexstarc CMS installation running on PHP, include the CMS server and supporting services in the review. Serving public pages as HTML does not establish that the whole hosting account is unaffected.
An administration area, form handler, integration, or another application on the same infrastructure may still depend on PHP. Check which parts execute PHP, whether relevant fixes have been applied, whether the follow-up advisory has been reviewed, and whether publishing, forms, and integrations still work after the update.
The answers should come from checking the actual installation. This article is not a security assessment of any individual website or CMS installation.
Common questions about the PHP update
Does changing my website password fix this vulnerability?
No. These issues concern the PHP runtime. Password hygiene remains useful, but it does not replace the server-level security fix.
Does an old version number always mean my host is unpatched?
No. Some vendors backport security fixes into maintained packages. Ask the provider to confirm coverage for both CVEs and the follow-up advisory.
Does installing the patch mean my website was never compromised?
No. An update addresses known vulnerable code paths. If compromise is suspected, the responsible team should also review the installation and investigate relevant evidence.
Make security maintenance part of website ownership
This incident shows why website care needs to include the software beneath the design. A maintained website needs someone responsible for runtime updates, supported versions, backups, monitoring, and checks after changes.
Clear ownership makes urgent security work faster and easier to verify.