The 9.2-Rated PHP Flaw AI Found: Is Your Site Exposed, and Should You Patch or Move?

Introduction: the day websites around the world switched off

On 21 October 2026 the PHP development team shipped emergency fixes for two vulnerabilities now known together as PHP2Shell. The same day, government websites in several European countries went offline for emergency maintenance, CERT-EU advised taking unpatched sites down, and Cloudflare reported early attempts to exploit the flaws.

The next morning the story reached Thailand. The Deputy Prime Minister, who also leads the Ministry of Higher Education, Science, Research and Innovation, ordered universities, hospitals and medical schools under the ministry to check their systems urgently, starting with patient records and student databases.

If you own a business with a website, the question to ask today is not “will we be hit?” It is “what is our website running on, and who is responsible for updating it?”

PHP powers close to 70% of websites whose server-side language can be identified, according to the W3Techs figure the PHP team cited. That includes WordPress, WooCommerce, Joomla, Drupal, Magento, Laravel, and a great many custom back-ends that Thai web agencies have built over the years. Company sites, online shops, clinics, schools and news sites run on PHP, often without their owners ever knowing.

This article is not for the engineer reading every line of the CVE. It is for owners, managers and decision-makers who must decide how to spend money on a website in an era when AI finds vulnerabilities faster than people can.

It covers the news, the costs that are easy to overlook, and our own experience, because kooru.com was hacked too and we rebuilt it from scratch.

What is PHP2Shell, and how serious is it?

PHP2Shell refers to two flaws in the PHP language itself, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 under CVSS v4.0, which is critical, because an attacker may be able to execute code on the server remotely (Remote Code Execution) without an account or password.

In business terms, a stranger may be able to walk into your server room without a key. Once inside, they can read your customer database, change your pages, plant links, or use your server to attack others.

Facts confirmed as of 22 October 2026

Sources: Post Today, Bangkok Biz News, the aaPanel security notice and the Coolify release notes (see References).

A note on versions: aaPanel lists fixes going back to PHP 7.4, while Bangkok Biz News reports that PHP 8.1 and older are past end of support. In practice, if your site still runs PHP 8.1 or older, treat it as highest risk and plan an upgrade or migration, not just a patch.

Why did some hosts patch at once and others a day later?

We saw this first-hand this week. One server management platform we use updated PHP to 8.4.27 automatically on 21 October. Another control panel only emailed its users on 22 October, asking them to click update themselves.

One day sounds short. But on a day when Cloudflare is already seeing attacks, one day is 24 hours of scanning bots knocking on every door on the internet.

If you don’t know who controls your website, who presses the update button and when, that gap is a bigger risk than the vulnerability itself.

Why this time is different: AI has become a vulnerability hunter

PHP has had serious bugs before. What sets PHP2Shell apart is that both flaws were found with the help of AI models, in code that people had reviewed for decades.

It isn’t an isolated story. The same month brought several signals pointing the same way:

• Bank of America’s CEO said on 14 October 2026 that the bank had hired around 1,000 contractors to fix vulnerabilities found by an AI model (summary on TechLawNow, Thai).
• Northwestern University research, reported by Help Net Security, found that AI-written patches passed the project’s own tests only about 61% of the time. AI is better at finding holes than fixing them (Thai summary).
• The 3BB intrusion went through a FortiGate flaw that had been patchable for almost two years, a reminder that old, unpatched holes remain the main way in (Thai summary).

What does this mean for legacy systems?

Follow the logic:

1. AI makes finding vulnerabilities cheaper and faster, for defenders and attackers alike.
2. Systems with lots of old code, many plugins and many software layers have more surface to search.
3. Fixing still takes people. Someone has to test, press update, and check the site still works.

The dangerous window is the gap between “the flaw is public” and “your site is fixed”, and that window is likely to open more often, not less.

PHP2Shell is not the last of its kind. It is an early example of what will become normal. Systems that depend on several layers of people to apply updates will find each year harder than the last.

Is your website at risk? A two-minute checklist for owners

You don’t need to be a developer to make a first assessment. If you answer “yes” or “I don’t know” to three or more of these, have your site checked soon.

• Is your site built on WordPress, WooCommerce, Joomla, Drupal, Magento or OpenCart?
• Is it on shared hosting or a VPS with a control panel such as cPanel, DirectAdmin, aaPanel, Plesk or hPanel?
• Don’t know which PHP version it uses?
• Has the agency that built it closed, stopped supporting it, or become hard to reach?
• Are there plugins or themes not updated in six months?
• Does it have member accounts, contact forms or checkout that collect names, phone numbers, emails or addresses?
• Does nobody in the company check Google Search Console regularly?
• Have you never tested restoring a backup?

The last point matters. A backup you have never restored is an umbrella you have never opened. You find out it’s broken when it’s already raining.

How to see your PHP version without logging into the server

Many sites announce their PHP version in an HTTP header called X-Powered-By, visible to anyone in the browser’s developer tools (press F12 and open the Network tab). If you see something like PHP/8.5.11, the site is not patched, because the fixed release on the 8.5 line is 8.5.12.

If you can see it, attackers can too. Scanning bots read headers like this all day to pick targets. Hiding it (turning off expose_php) doesn’t fix anything, but it keeps you off the top of the list.

What to do in the first 72 hours: a three-step plan

The guidance the Thai ministry issued, as reported by Bangkok Biz News, has three stages that work just as well for private businesses. Here they are in terms an owner can hand straight to a team.

Step 1: Inventory (within 24 hours)

List every website and system the business runs, not just the main site. Include old campaign sites, branch sites, booking systems, admin back-ends, landing pages an agency built years ago, and subdomains everyone forgot.

For each one, record:

• Whether it uses PHP, and which version
• Whose hosting or server it sits on
• Who has the access to update it
• Whether it stores customer data, and what kind

Put systems holding personal data at the top, especially health, financial and children’s data.

Step 2: Reduce the risk while you wait for the patch

If you can’t update PHP immediately, some temporary measures help:

• Turn on a WAF (Web Application Firewall), such as Cloudflare’s Managed Rules or your cloud provider’s WAF, to filter malicious requests before they reach the server.
• Apply the interim php.ini settings: session.upload_progress.enabled = 0, and on PHP 8.5 also fatal_error_backtraces = 0, then restart every PHP worker. These must be set in the main php.ini, not through ini_set() or .user.ini.
• Watch for unusual access: unknown new files in the web folder, admin accounts nobody created, and spikes in outbound traffic.

Keep in mind that the aaPanel notice is explicit: these settings only block specific attack paths for CVE-2026-109619. They don’t fix both flaws and don’t replace patching. If you can’t patch and the system holds important data, taking the site offline, as CERT-EU advised, deserves serious thought.

Step 3: Fix it properly

Update PHP to a fixed release from the table above, test that the site works, and then look back for signs of intrusion before the patch. Patching closes the door. It doesn’t remove anyone who already got in.

If you run OpenLiteSpeed, aaPanel notes that its LSPHP update script doesn’t currently upgrade existing installs, so you need to update through apt or yum. It’s a good example of why “one click and done” isn’t always real.

If you find a breach, the PDPA 72-hour countdown starts

If your review shows personal data was accessed without authorisation, the data controller must notify Thailand’s Personal Data Protection Committee office (PDPC) without delay and, where feasible, within 72 hours of becoming aware, under Section 37(4) of the Personal Data Protection Act, unless the breach is unlikely to put people’s rights at risk. Where the risk is high, the affected individuals must be told too, along with the remedies.

For an hour-by-hour plan, read A Data Leak at 2 a.m.: The First 72 Hours. If a contractor maintaining your site caused the problem, see Processor breach: who notifies whom, and how fast.

What does leaving it unpatched cost? Four layers owners rarely see

Many owners think “if the site gets hacked, we’ll restore the backup.” In reality the damage doesn’t stop at the server. It spreads in layers, and each layer costs more than the one before.

Layer 1: Google remembers longer than you think

After breaking into a PHP site, attackers rarely just steal data. They plant spam pages: fake Japanese product listings (the “Japanese keyword hack”), gambling links, counterfeit medicine or investment scams. They want to borrow your domain’s reputation to rank their own sites.

What follows:

• Google may show “This site may be hacked” under your name in search results.
• Search Console may flag a Security issue and, in worse cases, a Manual Action that demotes the whole domain.
• Spam pages already indexed don’t disappear when you delete the files. Google has to recrawl each URL, which takes weeks or months.
• Fake structured data the attacker injected, such as product listings with invalid GTINs, keeps showing up in Search Console reports long after.

Our own experience bears this out (see the case study below). Cleaning the server took days. Cleaning your name in Google’s eyes takes weeks, and the traffic that should have been sales goes elsewhere in the meantime.

Layer 2: customer trust, which you can’t buy back

Picture a customer searching for your shop and finding second-hand car keys listed in Japanese under your domain, or clicking through and landing on a gambling site.

They won’t phone to ask whether you’ve been hacked. They’ll close the tab, buy from someone else, and may never return.

For businesses that sell trust, such as clinics, accounting and law firms, schools, or any shop taking online payments, this damage never appears on the balance sheet, but it shows up in sales for months.

Layer 3: the PDPA doesn’t punish being hacked. It punishes not preparing

This is the most common misunderstanding. Thailand’s PDPA doesn’t say “never get hacked”, because no system is 100% secure. Section 37(1) requires data controllers to put appropriate security measures in place.

So when something happens, the regulator’s question isn’t “why were you hit?” but “what did you do before you were hit?”

• A critical flaw with a published patch, covered in the national news, left unpatched, is very hard to describe as an “appropriate measure”.
• Failing to comply with Section 37 carries an administrative fine of up to THB 3 million, and up to THB 5 million where sensitive data such as health information is involved.
• In civil law, affected individuals can claim damages under Section 77, and under Section 78 the court may add punitive damages of up to twice the actual damages.
• The PDPA’s criminal penalties target certain unlawful uses or disclosures of data, not being hacked as such. But if leaked data is mishandled afterwards, that exposure can open up.

PDPC statistics summarised by TechLawNow are telling: of 1,650 breaches reported, more than half did not come from cyberattacks at all but from human error (Thai summary). Cyber events like PHP2Shell are only part of the risk, and organisations with no system in place get hit from both directions.

For a single minimum-security checklist that satisfies both Thai regulators, see one security checklist for the PDPC and NCSA.

Layer 4: gambling links on your site can pull in the Computer Crime Act

This is the layer few people consider, and it can be more serious than expected.

When attackers plant online gambling pages or links on your site, that content is illegal in Thailand from the outset, and your site is the platform publishing it.

• Section 15 of the Computer Crime Act makes a service provider who cooperates with, consents to or knowingly allows an offence under Section 14 on a system under its control liable to the same penalty as the offender. An owner who genuinely didn’t know has a defence. But once you’ve been notified and leave it there, that defence weakens quickly. The law lets service providers escape liability by following the notice-and-takedown procedure in the ministerial notification, which means you have to act, not wait.
• URL blocking. Thailand’s digital ministry blocked 945,075 gambling URLs in fiscal year 2026 and cut the process to no more than four days (Thai summary). The AI used to detect them doesn’t know who the real owner is. If your domain is full of gambling pages, you may be the one proving your innocence.
• Payments. The Bank of Thailand is preparing to tighten rules on payment providers linked to online gambling. An online shop with gambling links planted on it may face questions from its payment provider or bank.

None of this is meant to cause panic. Thai law isn’t aimed at punishing victims of hackers. But the gap between “didn’t know” and “knew but didn’t act” is a line that matters, and Search Console alerts and hosting emails are evidence that you were told.

Case study: when kooru.com was hit

We didn’t write this from a textbook. Our own website was a victim.

kooru.com used to run WordPress on shared hosting. When we found malware on it, we deleted the whole WordPress site, refused to restore the infected backup, and rebuilt the site with Astro as static files on Cloudflare Pages. The move was completed on 21 October 2026.

What we found afterwards is a lesson every business should hear:

1. Search Console still showed fake Japanese product listings, such as Jeep car keys, a Suzuki key set and a Tiffany diamond necklace, attached to four of our real article URLs. Google had crawled them on 15 and 16 October, just days before we moved.
2. The reports listed problems like “Invalid GTIN”, “Missing field description” and “uploadDate has no time zone”. Our new site contains no such code. All of it was debris left by the attacker.
3. At the time of the move, the indexing report showed 475 pages not indexed against 316 indexed, mostly junk URLs from the old system such as feeds, tags and planted pages.
4. We checked every URL was genuinely clean, including the trick attackers use to hide spam (cloaking: showing normal pages to people but spam only to Google’s crawler), and only then clicked “Validate fix” on each issue. Google says validation takes days to weeks.

The good news: there are no outstanding security issues or manual actions, and since the move Google has steadily been indexing the new pages.

And when PHP2Shell broke the next day, our main site needed nothing at all, because there is no PHP left on the server to attack.

When we decided to migrate, we wondered whether it was wasted effort. Today the answer is clear. Migrating wasn’t wasted effort. It was peace of mind bought in advance.

The long-term choice: keep patching, or migrate?

Not every site needs to move. The right decision depends on what your site does and how often it changes.

Comparison table for decision-makers

To be straight about it: no technology needs zero maintenance. The same week as PHP2Shell, Node.js fixed 10 vulnerabilities, four of them high severity. The difference is the size of the door, and how many people must press update before your site is safe.

Who is Next.js for?

Next.js suits sites that are alive, where data changes constantly and each user sees something different, for example:

• Member areas where customers log in to see orders, loyalty points or service status
• Real-time dashboards
• Booking and appointment systems, or anything wired to several external APIs
• Platforms that will grow into full applications

You get high performance, modern code structure and no reliance on dozens of plugins from strangers. You still have server code running, so you still need a clear update plan.

Who is Astro on Cloudflare for?

Astro on Cloudflare Pages suits sites that have settled, where content doesn’t change every hour, for example:

• Company, services and professional-practice sites
• Article and knowledge sites that need to rank on Google and be cited by AI
• Shops with a fairly stable catalogue that use an external payment service such as Stripe
• Campaign sites and landing pages that need maximum speed

This is how kooru.com runs today. Every page is prebuilt and served from Cloudflare’s network, and the parts that genuinely need processing, such as payments, are small, easy-to-control functions.

And if you want to stay on WordPress?

You can, and for some businesses it’s the better fit, especially when many staff edit content every day. But set some minimums:

• Host somewhere that patches PHP automatically and alerts quickly.
• Name who is responsible for updates and put patch timelines for critical flaws in the contract.
• Keep plugins to the minimum and always run a WAF in front.
• Keep off-server backups that you have actually restored.

If you can’t meet those conditions, migrating usually costs less in the long run.

Migrating with Kooru: what we do

We’ve migrated our own site. We know what breaks easily, what drops Google rankings, and what typical web agencies forget. So we offer website migration for Thai businesses at affordable prices, in five steps.

1. Health check of the current site

What it runs on, which versions, any signs of intrusion, spam still sitting in Google, and what personal data it holds.

2. Pick technology that fits the business

No overselling. Settled sites go to Astro on Cloudflare, constantly changing sites go to Next.js, and if a well-maintained WordPress is still the best fit for you, we’ll tell you so.

3. Move without losing Google rankings

Keep URLs, add 301 redirects for anything that moves, submit a new sitemap, ping IndexNow, and handle Search Console, including clearing old spam and validating every fix, exactly as we did for ourselves.

4. Build in SEO, AEO and GEO from day one

A new site shouldn’t just be safe. It should be found in Google and cited in AI answers from ChatGPT, Gemini and Perplexity. We set up structured data (schema), direct answers at the top of pages, FAQs, and paired Thai and English pages (AI SEO for SMEs).

5. PDPA compliance at the same time

Privacy notice, cookie consent, forms that only collect what’s needed, and contracts with any vendor that touches customer data (PDPA for Thai SMEs).

Contact us

Send your website link to LINE: @kooru with a line about what the site does. We’ll tell you whether to keep patching, move to Next.js or move to Astro on Cloudflare, and give you a clear price before any work starts.

Talk to us on LINE @kooru

Food for thought

If it isn’t you today, it may be your turn tomorrow.

Attackers don’t pick victims by company size. Their bots scan every site online and pick the ones with unlocked doors.

Cleaning a site takes days. Cleaning your name with Google and your customers takes months.

The PDPA doesn’t ask why you were hit. It asks what you did before you were hit.

A migration is paid for once. Lost trust has no price you can pay back.

AI speeds up both sides. Defenders get faster, and so do attackers. The businesses that come through aren’t the ones that never get attacked. They’re the ones that make themselves the hardest target on the street.

Further reading

Breach response and cyber risk (AIPDPA)

• A Data Leak at 2 a.m.: The First 72 Hours
• Ransomware: what three Thai laws require
• One security checklist for the PDPC and NCSA
• Vendor checks before you sign
• A half-day company-wide breach drill

News and analysis (TechLawNow, in Thai)

• 3BB breached through an old FortiGate flaw
• ThaiCERT warns of Zimbra flaw used to plant web shells
• Gambling URL blocking cut to four days

On Kooru

• Use AI safely without leaking secrets
• PDPA for digital marketers

Frequently asked questions about PHP2Shell and migration

1. Are WordPress sites affected by PHP2Shell?

Yes, if the server still runs an unpatched PHP version, because the flaw is in PHP itself, not in WordPress. Updating WordPress or its plugins is not enough. PHP on the server must be updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later on your version line, and Wordfence has warned that WordPress auto-updates may not deliver this fix.

2. On shared hosting, do I need to do anything or wait for the host?

Shared hosts usually update PHP on the server, but you should still check which PHP version your site is set to in the control panel and ask your host whether the fix is applied. If your site is pinned to an old, unsupported PHP version, waiting won’t help.

3. Is setting session.upload_progress.enabled = 0 enough?

No. It is a temporary measure that only blocks specific attack paths for CVE-2026-109619. It does not cover CVE-2026-109618 and does not replace the patch. Update PHP as soon as possible.

4. If my site is breached through PHP2Shell, must I notify the PDPC?

Yes, if personal data was accessed, disclosed or lost in a way that risks people’s rights. Under Section 37(4) you must notify the PDPC without delay and, where feasible, within 72 hours of becoming aware, and where the risk is high you must also notify the affected individuals.

5. Is a site owner liable under the Computer Crime Act for gambling links planted by hackers?

An owner who genuinely didn’t know has a defence, because Section 15 targets providers who cooperate with, consent to or knowingly allow the offence. Once notified, for example through Search Console, customers or authorities, leaving the content up raises the risk sharply. Remove it, keep evidence and fix the vulnerability right away.

6. I removed the spam pages. Why does Search Console still show problems?

Google must recrawl each URL before the report updates. Confirm every URL is clean for both users and Google’s crawler, then click Validate fix in each report. Validation takes days to weeks.

7. Will moving from WordPress to Astro or Next.js hurt my Google rankings?

Not if it’s done properly. Keep as many URLs as possible, 301-redirect anything that moves, preserve content and structured data, and submit a new sitemap. Many sites rank better afterwards because they load faster and have cleaner HTML.

8. Should I choose Next.js or Astro?

Choose Next.js if your site has constantly changing data, such as member areas, dashboards or booking. Choose Astro on Cloudflare if the site has settled, such as a company site, article site or a shop with a stable catalogue using an external payment service.

9. Can an online shop built with Astro take payments?

Yes. The storefront is prebuilt and fast, and payments go through an external service such as Stripe Checkout via a small Cloudflare function, as kooru.com does. Customers’ card details never pass through the shop’s server.

10. How much does a migration with Kooru cost?

It depends on the number of pages, the systems involved and the target technology. We keep prices affordable for SMEs and quote clearly before starting. Send your site link to LINE @kooru for an assessment.

References

1. Post Today. (22 Oct 2026). Critical PHP vulnerability found by AI; government websites in several countries go offline (Thai). https://www.posttoday.com/smart-city/750789
2. Bangkok Biz News. (22 Oct 2026). Deputy PM orders higher security after PHP vulnerability (Thai). https://www.bangkokbiznews.com/tech/ai/1257463
3. aaPanel. (22 Oct 2026). Critical PHP security update for aaPanel users (CVE-2026-109618, CVE-2026-109619). Security notice to users.
4. Coolify. (21 Oct 2026). Release v4.4.7: Updated PHP to 8.4.27 to fix PHP2Shell. Release notes.
5. TechLawNow. (2026). News analysis on Bank of America, AI patching research, 3BB FortiGate, Zimbra, gambling URL blocking and PDPC statistics. https://techlawnow.com
6. Thailand Personal Data Protection Act B.E. 2562 (2019), Sections 37, 77, 78 and administrative penalties.
7. Thailand Computer Crime Act B.E. 2550 (2007), as amended B.E. 2560 (2017), Sections 14, 15 and 20.
8. Google Search Central. Hacked sites, spam policies and the Security Issues report. https://developers.google.com/search

This article is general information to support business decisions. It is not legal or technical advice for a specific case. Facts about the vulnerability reflect news reports and notices as of 22 October 2026 and may be updated.

By: Khun Phuwara, Senior Advisor in Business Strategy and Legal-Tech at The Kooru

About the author: Phuwara Krobtaku

Licensed lawyer no. 477/2558 · Thai Barrister-at-Law · LL.M. IP & IT Law (gold medal) · DPO

More than 20 years in IT and digital marketing before law. Founder of Kooru, a tech-law advisory handling PDPA, AI governance and intellectual property for SMEs.

Ask the author on LINEFull profile