kafkai.com does not use PHP in its core services. The two critical PHP vulnerabilities disclosed on 21 October 2026 do not affect our platform, and they do not affect your data.

There is nothing you need to do. Keep using Kafkai as normal.

What Happened

On 21 October 2026, the PHP project released emergency fixes for two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619. Researchers have grouped the pair under the name PHP2shell. Both are rated 9.2 out of 10 under CVSS 4.0, and both let a person who has not logged in run code on a vulnerable server.

CERT-EU named the fixed releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its advisory also warns that every PHP installation serving web requests is at risk, that proof-of-concept exploits were already spreading on the day the fixes shipped, and that PHP 8.1 and earlier will not be patched at all.

Both flaws sit in the PHP engine itself, underneath whatever application runs on top of it. A site with clean code was still exposed. The reach is wide because PHP usually runs under a CMS that the site owner did not write. VirusTotal counted 5.1 million IP addresses serving PHP, and Cloudflare reported attempted exploitation on the day of release.

W3Techs puts PHP on about 70 percent of the websites whose server-side language is known, WordPress included. So this was never a problem for a handful of sites. Hundreds of websites were taken offline on the day the patches shipped, as companies and governments stopped work to update.

Why We Are Not Affected

Kafkai is built mainly on Python. Our core services contain no PHP, which means there is no code to patch and no PHP version to update.

We checked after the fixes came out, the way we check every advisory that lands. The check covered the parts you touch: the web application you log into, the API your agent connects to, and the background jobs that keep your data current. All of it runs Python. None of it passes through a PHP runtime on the way from your browser to your data.

The result was the one we expected. If any part of that path ever changes, this post is where we will say so.

A Word About PHP

PHP is a good language, and it is still fine to use.

We build on Python because it suits what we make and we're close to the community, not because PHP is the wrong choice. Every language has a purpose and a place in this industry. As people working in the same industry, we do not talk down other people's tools. A security notice is not the place to score a point against a language. Software used this widely will pick up vulnerabilities sooner or later. What matters is how fast a fix ships, and how fast it is applied.

Why This Is Not Someone Else's Problem

One of the two flaws was found by an AI model. OpenAI says the security firm Calif found it using GPT-5.6 Sol, and that Google's Wiz independently found and reported both, using models of its own. Frontier AI reached the flaws before attackers did this time, which gave defenders a window to prepare.

OpenAI also said plainly that the same capability helps attackers build exploits faster. So that window is a gift, not a permanent advantage.

The gap between a patch and an attack is now measured in hours, not weeks. Attackers read the same advisories we do, and AI shortens the work between reading one and having something that runs. Every service, in every language, has to stay ready for that.

I say this as someone whose stack came through this round untouched. Next time it may be a library, a dependency, or a package that we do use. That is why we keep watching instead of declaring victory.

How We Handle Your Data

We do not collect data we do not need to run the service. Data we never hold cannot leak. That rule is older than this week's news, and it is why somebody else's PHP flaw is not a data risk for you here.

What we do keep is a short list. Your account email address, the projects and competitors you set up, and a record of what was published where. We do not write or store your articles, so there is no library of your content sitting on our servers.

We also keep our dependencies current and read the security advisories for the components we rely on. I wrote about that habit after the Japanese data breaches earlier this month. Cheap to Attack, Expensive to Defend looks at what those breaches cost and what the same rules mean for a small business. The short version: list every field you collect, and delete the ones you cannot justify.

Open Source Is Paid For by Someone

The fix for this flaw was written by people, not by a company with a support contract. PHP has no owner. The PHP Foundation exists so that businesses which depend on PHP can pay the developers who maintain it and keep it secure (The PHP Foundation).

That only works while businesses put money in. PHP is free to download. It is not free to maintain.

I have spent the same years in the Python community. I am a Fellow of the Python Software Foundation, and in 2024 the PSF gave me its Community Service Award for work across Asia-Pacific, including PyCon Malaysia, PyCon APAC and PyCon Japan. I helped set up the non-profit behind PyCon JP in 2013. In 2024 I became a founding member of the Python Asia Organization, which now holds the name and infrastructure of the regional conference and pays an executive director, because volunteer goodwill alone was not enough.

A company can give three things:

  • Money. Sponsor a conference, sponsor the PSF, or pay a maintainer's salary.
  • Infrastructure. Hosting, CI time, a venue, travel grants.
  • Assets. Design, translation, legal review, and your engineers' hours.

None of that is charity. It is upkeep on something your business already depends on.

Nothing to Do on Your Side

Your Kafkai account, projects, and data are unaffected. No patch, no re-login, no password change is required.

If you do not run a website of your own, there is nothing for you to check here. If someone else runs your site, forward this post to them.

If you do run PHP, patch it now, and check which branch you are on before you assume an update exists. OpenAI published a checker on GitHub that reports whether a site or a server is running an affected version. Do not leave it for the weekend.

We will keep watching. If a future issue ever touches our service, we will tell you promptly and clearly, the same way we handled the phishing emails that used our domain in July.

For any question about this post, write to [email protected]