Not Every Vulnerability Is Yours to Fix: A Real-World Lesson in Using AI

Today, my feed has been full of the same two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Everyone seems to be writing about them. So who am I to stay quiet?

I am not a security expert. I run my own website and blog on PHP, and when the alerts landed I had one practical question: is my site affected, and what do I need to change? I asked an AI coding assistant to help me investigate. What I learned was less about the vulnerabilities than about who owns which fix.

What the two CVEs say

Both are rated critical (CVSS 9.2) and can potentially allow remote code execution on a server running an affected PHP version. The records also rate the attack complexity as high, which is worth knowing, but a critical flaw is something I check rather than assume away.

In plain terms:

• CVE-2026-109618: when PHP runs out of memory, it can leave part of a request's memory uninitialized.
• CVE-2026-109619: some internal state can keep pointing at memory that has already been freed.

Both live in the PHP engine, not in any website built on it. The upstream fixes are published for the current PHP 8.2 to 8.5 branches, listed here by the first fixed version:

My first instinct was to open my own code and look for something to change. That was the wrong place to look. A flaw in the engine cannot be fixed by editing a website. The fix is a PHP update on the server, which belongs to whoever runs the server.

Not every vulnerability is yours to fix. The first job is working out whose it is.

***

The assistant could not look them up

The assistant could not find either CVE through web search, and its environment blocked the NVD and cve.org sites. It said so plainly and did not guess what the CVEs covered. I supplied the records myself, first as PDF printouts and then as pasted text. It even noticed that one of my PDF uploads was a duplicate of the first, rather than assuming it had both.

I found that more reassuring than a confident answer would have been. An assistant that says "I cannot verify this" is one I can work with.

***

My host had already acted

My hosting provider's notice said it had applied CloudLinux's updates, with firewall rules active from the afternoon of October 21 and its PHP packages patched. That created a small puzzle. cPanel still showed ea-php85 8.5.11, and the assistant's first advice had been to look for 8.5.12 or later. That was a reasonable upstream rule, but it was not the whole picture.

The notice itself explained the gap. It listed a CloudLinux build, ea-php85 8.5.11-2, as the corrected version, and said an apparently old number was expected. This is how a backport works: CloudLinux patches ea-php packages for security while keeping the older upstream number.

A version number shows where a package started, not necessarily what has been patched. Read the vendor's notice before drawing a conclusion.

I wanted to check this myself. My plan has no terminal, and the package manager is blocked in its restricted shell, so I could not read the package's changelog. Instead I confirmed in cPanel that my domains run ea-php85, then used a one-off scheduled job to ask PHP for its version. It reported 8.5.11, built on October 21, the day of the fixes. That fits my host's notice, but a build date is circumstantial evidence, not proof. I would rather say that than overstate what I verified.

Once my host's notice arrived, the assistant corrected its advice, including the PHP version floor recorded in my project and its release notes. I liked that it updated the record, not just its answer. I treat that as an example of checking vendor-specific patch information, not as proof that version numbers cannot be trusted.

What I did myself

The assistant helped me think and keep the project's records accurate. The consequential steps stayed with me:

• I supplied the CVE records the assistant could not fetch.
• I read my host's notice and applied the PHP 8.5 setting in cPanel myself.
• I tested the live site afterward.
• I published the release and ran the production deploy; the assistant did neither.

Honest limits

• I relied on my host's notice that the patches were applied. My own check fits the notice but does not prove the patch, and the vendor's own status page was still rolling out fixes that day.
• The assistant's first answer needed refining once real information arrived. That is the process working, not failing.
• If you run your own server, the PHP update is yours to apply, and checking the fixed version for your branch is the right test.

What to take from this

1. Understand what is affected before you change anything.
2. Ask who owns the fix: your application, your host or another vendor.
3. Check primary sources. If the AI cannot fetch one, supply it rather than accept a guess.
4. Treat AI as an assistant, not the final authority, and say plainly what you did not verify.
5. Keep release and deployment human.

Sometimes the most useful thing a technical problem teaches is not how to write more code. It is knowing when your code is not the problem.

This is the first article in my series "Behind the Build: My Website and Blog, with AI", where I share practical lessons from building and maintaining my own site.