Critical PHP flaws: patch WordPress and PrestaShop without losing control
Critical PHP flaws: patch WordPress and PrestaShop without losing control
PHP security updates are available. As of 21 October 2026, PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fix CVE-2026-109618 and CVE-2026-109619. If you run WordPress or PrestaShop, ask your hosting provider or maintenance team to verify and patch the PHP runtime, then test the journeys your business depends on.
The CMS update button can create a false sense of security. WordPress, PrestaShop modules and the PHP engine running them are separate layers. A shop can have up-to-date extensions while still relying on a vulnerable runtime.
Status checked on 21 October 2026 after 15:41 UTC, or 17:41 in Paris. This article reflects the official information available at that time, not an assessment of your individual hosting environment.
Has the update announced for Wednesday at 4pm been released?
The original notice scheduled the release for Wednesday, 21 October 2026 at 14:00 UTC: 16:00 in Paris, which was on UTC+2. That deadline has passed. The official PHP security advisory now announces the fixes and urges users to update immediately. Businesses should no longer be waiting for an upcoming disclosure before arranging maintenance.
Both vulnerabilities can allow unauthenticated remote code execution: an attacker could make the server execute code without having an account. The official advisories rate both at 9.2 out of 10 under CVSS v4.0. This measures technical severity; it does not tell you whether your shop has already been attacked.
- CVE-2026-109618: corruption associated with out-of-memory handling.
- CVE-2026-109619: reuse of invalid internal state across requests.
PHP describes a risk to installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team considers mod_php the highest-risk configuration and reports a demonstrated exploit that runs before application code. A CMS brand alone therefore cannot establish the exact exposure. The runtime, its version and the way it serves requests matter.
Which PHP version should you ask your host to install?
For supported branches, the announced fixed releases are 8.2.35 for PHP 8.2, 8.3.36 for PHP 8.3, 8.4.27 for PHP 8.4 and 8.5.12 for PHP 8.5. Earlier releases in each branch are affected according to the advisories. A vendor may instead supply a package with backported fixes. In that case, request the package reference and the vendor’s security notice rather than judging protection from the upstream version number alone.
Ask about the PHP process actually serving your website, not just the command-line interpreter. Multiple versions can coexist on one server. A screenshot of php -v does not, on its own, prove that the shop’s web workers have been patched and restarted.
PHP 8.1 and older no longer receive routine updates from the PHP project. PHP does, however, point to minimal source backports for 7.4, 8.0 and 8.1, and to possible fixes from long-term-support vendors. Those exceptional patches do not restore normal support for these branches. If you depend on one, obtain confirmation of actual vendor coverage and plan a move to a compatible, supported branch.
PHP 8.2 itself reaches the end of security support on 31 December 2026, according to the official support schedule. The urgent patch and the longer-term migration are separate jobs. Do not let the second unnecessarily delay the first.
How do you patch quickly without breaking payments or orders?
Consider a PrestaShop store whose checkout works before maintenance but whose payment module fails afterwards. This is an illustrative scenario, not a client case. It explains why “the server responds” is an inadequate acceptance test: the business also needs to complete an order.
- Name the owner. Does the hosting provider update PHP, or is that the maintenance team’s responsibility? Get a named contact, a deadline and written confirmation. On shared hosting, do not assume the patch has already been applied.
- Prepare a practical recovery route. Check recent file and database backups, whether they can be restored, and how orders arriving during the intervention will be handled. A rollback must preserve orders and must not leave a vulnerable runtime exposed indefinitely. A copy alone does not prove recovery. Our guide to restore testing and business recovery explains the distinction, which also applies to an online shop.
- Deploy a compatible security fix. Where the existing branch is supported and compatible with the application, prioritise its security update. An urgent alert is a poor time to combine a major runtime migration with a theme change and new extensions.
- Test the critical journeys. Check login, forms, basket, payment using the approved test mechanism, and order confirmation. Include scheduled tasks and ERP or fulfilment connections where they exist.
- Monitor after deployment. Review PHP errors, failed payments, missing orders and security logs. If there are signs of intrusion, start an investigation. Patching does not remove the effects of an earlier compromise.
If nobody can account for access, dependencies or backups, the weakness extends beyond this release. Our approach to taking over an existing web application safely helps establish that baseline before the next intervention.
Can a firewall or security plugin replace the PHP update?
No. PHP states that there are no complete mitigations and that updating is the only safe choice. Its temporary measures reduce specific attack paths without making an installation safe. The operator must assess them: copying configuration changes from the internet can introduce a separate availability problem.
A WordPress security plugin does not update PHP itself. A normally functioning website is not evidence that it is free of these vulnerabilities. Equally, running a vulnerable version does not prove an intrusion occurred. Exposure, exploitation and compromise are different findings.
What evidence should close the maintenance ticket?
A business owner needs a short record: the sites and environments covered, the patched version or vendor package actually serving web requests, the deployment time, restarted processes, business test results and the person responsible for monitoring. “We updated the website” is too vague to close this alert.
For Say Digital, controlled deployment here means connecting the security notice to evidence of a fix and a working business journey. Are your host and developer passing responsibility back and forth? Contact Say Digital to scope maintenance for your WordPress, PrestaShop or PHP application: ownership, access, tests and intervention boundaries.
