How to Protect Your Website From AI-Found Security Bugs

If your website runs on PHP, this week matters to you. On October 21, 2026, the PHP project released emergency fixes for two critical flaws that could allow remote code execution without logging in. The security firm that found them says it used AI models in the work. Whether or not you care about the AI angle, the practical question is the same: is your site running a fixed version of PHP?

This guide explains what happened, who needs to act, and a step-by-step checklist you can follow even if you are not a developer. It is general information, not a substitute for your host’s advice or a security professional, especially for a business-critical site. I also include the GitLab emergency patch from the same period, because it is relevant if you host your own code.

What Happened: The PHP Flaws

The PHP project’s release announcement says it fixed two vulnerabilities that can allow unauthenticated remote code execution:

CVE-2026-109618: remote code execution through out-of-memory corruption. An interrupted memory failure can leave request data partly initialized, and cleanup may treat it as valid.
CVE-2026-109619: remote code execution through stale global state, where request data can outlive its freed memory and be used by a later request on the same worker.

Both were rated 9.2 on the CVSS v4.0 scale in the advance notice on October 20. The PHP team says the risk is highest for mod_php, where an unauthenticated request can trigger the attack before your application code runs. Security firm Wiz, which reported the flaws and calls them PHP2Shell, says they are in PHP’s core engine, so a secure application can still be exposed, and even a minimal “Hello World” app on an affected version can be vulnerable.

Fixed versions

According to PHP’s announcement:

PHP branch	Fixed version	Note
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Reaches end of life on December 31, 2026
8.1 and older	No upstream updates	Minimal backports exist in source for 7.4, 8.0, and 8.1, or ask your vendor

Linux distributions and long-term-support vendors received patches in advance, so your server’s package manager may already offer the fix.

Was AI involved?

Wiz says it used its own platform together with Gemini 4 Argon and GPT-5.6 Sol, and that the AI helped with discovery, exploit development, attack detection, and patch validation. That is the finder’s own account, and I could not verify it independently. It also says the flaws had existed for more than a decade. Wiz says every PHP version released in the last decade is affected by at least one of them, going back to 5.4.

How bad is it, and is it being attacked?

Reports disagree on the timeline, so be careful with strong claims:

ITdaily reports that details leaked on October 20, ahead of a planned coordinated disclosure, and that Cloudflare’s chief technology officer reported the first attacks on the morning of October 21. PHP released patches the same day.
One newsletter summary this week said attackers exploited the bug four days before the patch. I could not support that: the sources I read describe a leak on October 20 and first attacks on October 21, which is much shorter. Treat the “four days” claim as unconfirmed.
Wiz says it demonstrated remote code execution against the then-latest WordPress, Drupal, and Joomla container images in testing. It does not say whether attacks have been seen in the wild.
A security news summary says CISA told organizations running PHP-based sites to apply the patches right away.
The widely repeated “70% of websites” figure comes from Wiz’s description of PHP’s reach, and TidBITS repeats it without independent verification. It describes how many sites run PHP, not how many are exposed.

The safe reading: patches exist, attacks have been reported, and waiting has a cost.

Do You Need to Act? Start Here

Your setup	What to do
Managed WordPress or shared hosting	Ask your host to confirm the PHP security update is applied, and check your PHP version afterward
Your own server or VPS	Update PHP yourself and restart the services
Site on PHP 8.1 or older	No official update exists. Ask your vendor and plan an upgrade
Site not built on PHP	These flaws do not apply, but keep everything else updated
Developer running self-hosted GitLab	See the GitLab section below

The Checklist

Step 1: Find your PHP version

Your hosting control panel usually shows it. In WordPress, the Site Health screen under Tools has an Info tab that lists server details including the PHP version. If you manage the server, run php -v for the command-line version, and remember that the web server may use a different one.

Step 2: Compare it with the fixed versions

If you are on 8.5, 8.4, 8.3, or 8.2, you need at least the version in the table above. If your version number is lower than the fixed one on the same branch, update.

Step 3: Update, then restart

On shared or managed hosting, your provider handles this. TidBITS reports that DreamHost had applied the updates across most of its network and was still testing the rest, with existing mitigations in place. That is one host’s status, so ask yours. On your own server, install the update through your package manager or your host’s tools and restart PHP as your platform requires.

Step 4: Confirm the update actually took effect

Check the running version again after the update. Reports from site owners describe confirming the version after the host’s rollout. An updated package that was never loaded protects nothing.

Step 5: If you are on PHP 8.1 or older

Upstream does not offer updates. Options include asking your vendor for a patched build and moving to a supported branch. PHP’s supported-versions page, as of October 23, 2026, lists 8.4 and 8.5 as actively supported, and 8.2 and 8.3 as receiving security fixes only. Per that page, security support runs until December 31, 2026 for 8.2, 2027 for 8.3, 2028 for 8.4, and 2029 for 8.5. Moving to 8.4 or 8.5 gives you the longest runway.

Step 6: If you cannot update right now

PHP’s advisory lists measures that reduce exposure, and it states that they do not make an installation safe. In summary, they include:

For CVE-2026-109618, setting a limit on request size (post_max_size to 8M, or 32M if you need file uploads), and setting memory_limit to -1 in a way that applications cannot override, such as in the server or pool configuration.
For CVE-2026-109619, disabling session.upload_progress.enabled in the main configuration, then restarting all workers.
On PHP 8.5 only, turning off fatal_error_backtraces.
Do not use operating-system address-space limits as a substitute for the memory setting, because they can trigger the vulnerable failure.
Add request-size limits at the web server or proxy.

My note: unlimited memory per request has its own downsides, so treat this as a short-term step. Read the advisory itself on php.net before changing a production server.

Step 7: Consider a firewall as a stopgap

Wiz says several providers, including Cloudflare, Fastly, and Vercel, published guidance and mitigations. ITdaily describes Cloudflare rules as a stopgap, not a fix. TidBITS notes that commenters recommend a WordPress firewall plugin as an extra layer; that is reader advice rather than the article’s claim. Use a firewall to buy time, not to avoid patching.

Step 8: Look for signs of attack

After patching, check whether anything happened before you did. Wiz suggests watching for:

unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses,
unexpectedly large or malformed session cookies,
unexplained churn in PHP worker processes.

ITdaily notes that some sites were taken offline as a precaution and advises checking for compromise after patching. If you see signs of intrusion, restore from a clean backup, change administrator passwords and keys, and ask your host or a security professional for help.

Step 9: Make the next patch easier

Keep a recent offline backup, turn on automatic security updates where your host or platform supports them, and subscribe to your host’s status page and the PHP announcements. For small sellers who depend on a site for income, see our guide to tools for creating and selling digital products, which includes platforms that handle hosting for you.

The Same Week: GitLab’s Critical Patch

If you run your own GitLab, there was a separate emergency fix. GitLab’s patch release notes describe CVE-2026-97229, rated CVSS 10.0, an integer overflow in the CI/CD regular expression compiler. Under certain conditions, an unauthenticated user could execute arbitrary code on the server using a crafted regular expression in a CI/CD configuration.

Affected: GitLab CE and EE from 19.2 before 19.2.8, from 19.3 before 19.3.5, and from 19.4 before 19.4.2.
Fixed in: 19.2.8, 19.3.5, and 19.4.2.
Who must act: self-managed installations. GitLab says GitLab.com is already patched and that all Dedicated tenants were patched before release.
Exploitation: the page does not state that exploitation has been observed. GitLab released six threat detections to help spot attempts.
Downtime: single-node instances should plan for it, because migrations must finish before GitLab starts.

This one is not described as AI-found. DevOps.com credits the report to a researcher who submitted it through GitLab’s bug bounty program. Some summaries this week grouped it with the AI-found PHP bugs, so keep the two stories separate. The same release fixed 24 vulnerabilities in total.

Why “AI-Found” Matters, and Why It Does Not Change Your Checklist

If AI makes it faster to find serious bugs, then serious bugs may be found, disclosed, and exploited faster. That is a reasonable concern, and it is the claim of the finders here rather than a measured trend. For a site owner, it points to the same advice as before, with a tighter schedule: know what you run, update quickly, and have a plan for software that no longer gets updates.

Common Mistakes to Avoid

Assuming your host did it. Ask, then verify the version.

Updating the wrong PHP. The command line and the web server can run different versions.

Treating a firewall as a patch. It reduces risk but is not the fix.

Staying on end-of-life PHP. No upstream updates means no official fix next time either.

Patching and forgetting to check for compromise. Look at logs after the update.

Copying server settings without understanding them. Use the advisory’s guidance as a short-term step and plan to patch.

Believing the loudest numbers. “70% of websites” describes PHP’s reach, not confirmed victims.

Frequently Asked Questions

Is my WordPress site affected? WordPress runs on PHP, so it can be if its PHP version is unpatched. Ask your host or check your PHP version in the Site Health screen.

Which PHP versions are fixed? 8.5.12, 8.4.27, 8.3.36, and 8.2.35 according to PHP’s announcement. 8.1 and older receive no upstream updates.

Were the bugs really found by AI? Wiz, the reporter, says it used AI models alongside its own platform. That is its own account.

Are attacks happening? Reports say first attacks were seen on October 21, but accounts differ on the timeline.

Is GitLab affected too? Only if you run a self-managed GitLab CE or EE in the affected version ranges. GitLab.com is already patched.

Can a plugin protect me? A firewall plugin can add a layer, but patching PHP is the real fix.

The Bottom Line

The practical steps are short: find your PHP version, move to a fixed release or a supported branch, confirm the change took effect, and look for signs of earlier attack. If you are on managed hosting, one email to your provider may be all it takes. If you run your own servers, do it today rather than this weekend. For the AI angle, the lesson is not to panic about machines finding bugs, but to treat patching as routine work with a shorter fuse. If your day-to-day work involves AI assistants, our look at ChatGPT’s Locked Chats covers one more privacy habit worth building.