PHP security update (21 October 2026): what to do this week
Two critical PHP flaws were fixed on 21 October 2026. What to check on your website, what to ask your host, and two free guides you can download. English and Deutsch.
Read this in German: Deutsche Version dieses Artikels.
Two critical PHP flaws were fixed on 21 October 2026. Both can let someone run code on your server without logging in. If your website runs on PHP, it needs the patch. That includes WordPress, Joomla, Drupal and most online shops.
Sources: PHP project security advisory, 21 October 2026 and CERT-EU Security Advisory 2026-018.
Not sure whether your site uses PHP? Ask your host. Most do.
What to do this week
- Name one person who owns this. Usually the owner, or whoever looks after the website. That person opens an urgent ticket with the host and follows up by phone if nobody replies.
- Check your PHP version. In WordPress, go to Tools > Site Health > Info > Server (WordPress guide). Write down the full version number.
- Ask for the patched release. Fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or a later release from the same branch. A vendor backport covering both CVEs (CVE-2026-109618 and CVE-2026-109619) also counts. If you run PHP 8.1 or older, ask the host for a vendor fix or an upgrade to a supported branch.
- Confirm the patch is live. Installed and running are different things. Ask the host to confirm in writing that the live site runs the fixed version.
- Update WordPress, your theme and your plugins too. This does not replace the PHP patch.
- Look for signs of a break-in. Unknown admin accounts, changed files and scheduled tasks you did not set up. A patch does not remove an intrusion that already happened.
If you can't patch today
Ask the host to block public access to the site until the patch is in. A maintenance plugin or a firewall rule on its own is not enough protection.
Free guides
I wrote two short guides you can send to your host or keep for your records. Both include a support ticket you can copy and send.
AI prompt: get help with the fix
Want a second pair of eyes? Copy this prompt into Claude or ChatGPT and fill in the brackets. The AI can guide you through the steps, but it cannot update your server itself, and it cannot check your site without access. Never paste passwords or API keys into the chat.
Help me secure my own WordPress/PHP installation against CVE-2026-109618 and CVE-2026-109619. Explain the steps clearly and guide me through verified remediation.
Website(s): [domains]
Application: [WordPress / other / unknown]
Hosting and operating system: [provider / system / unknown]
Access: [WordPress admin / hosting panel / SSH / containers / MCP / none]
Backup status: [date / unknown]
1. Check current primary sources first: https://www.php.net/ and https://cert.europa.eu/publications/security-advisories/2026-018/ plus my vendor's advisories. As of October 22, 2026, fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or later fixed releases in the same branch. Accept documented vendor backports covering both CVEs. If you cannot browse, say so and ask for the current vendor advisory.
2. Begin read-only. Ask for missing details and use only available, authorized tools. Identify the web PHP runtime, installation method and every affected environment. Distinguish CLI PHP from web PHP. For WordPress: Tools > Site Health > Info > Server. Without access, write a specific hosting support ticket. Never claim to have performed checks you could not run.
3. Present a short patch plan covering backups, recovery and functional checks. Show exact commands or panel steps matched to my installation and explain their effects. Ask for approval before production changes or downtime. Prefer a patch in the existing supported branch; for obsolete branches, plan a compatible migration or documented vendor fix.
4. After approval, make only agreed changes, restart affected services or replace containers, and verify every instance. Do not claim that plugin updates, WAF rules or a maintenance plugin fix PHP itself. Do not run exploit tests or apply blanket memory-limit workarounds. Never ask me to paste passwords, API keys or complete configuration files into chat.
5. Prove the fix is active in web PHP. Test pages, forms, email delivery, login and checkout where applicable; agree on a test before sending real messages or placing orders. Review logs and files for signs of compromise. If suspicious activity is found, preserve evidence and involve specialists.
6. If immediate patching is impossible, propose controlled isolation from the public internet. Finish with each environment's before/after state, evidence, test results, unresolved items and owner. Use only these statuses: "confirmed patched", "demonstrably not affected" or "unverified". A reachable website or green WordPress status is not proof of patching.