When AI Finds the Flaw, Trust Is What Still Needs Defending

Every visit to a business’s website is a small decision about trust. The customer recognizes the name, types the address they know, and expects to be dealing with that business. When a threat actor takes control of that website, every one of those signals still points to the business.

That is the question underneath this week’s PHP disclosure. On October 21, the PHP project released fixes for two critical flaws, collectively called php2shell, that could let an unauthenticated attacker run code on servers running PHP, the language behind a large share of the web (WSJ (opens in new tab)). Researchers found them with the help of AI models and worked with maintainers and security providers to prepare protections before disclosure (OpenAI (opens in new tab)). That is a meaningful defensive success. The immediate priority is to find exposed systems and patch them, and early exploitation attempts have already been reported (Fortune (opens in new tab)).

For business leaders, the implications extend past the patch.

Threat actors already borrow the trust of legitimate websites. Since mid-2025, Doppel analysts have confirmed scam content hosted on hundreds of legitimate organizations’ websites, including universities, government agencies, and nonprofits. Most of it did not require a breach: documents impersonating customer support for well-known brands, uploaded through the sites’ own web forms. The domain did the persuading. A flaw that hands over control of the server makes that easier and quieter.

The headline itself becomes material as well. Threat actors have impersonated the WordPress security team before, emailing site owners about a fake vulnerability and a “patch” plugin that installed a backdoor (BleepingComputer (opens in new tab)). A named, critical PHP flaw is the kind of news those lures are built on, and I would expect php2shell-themed “patch” emails to follow.

Consider a plausible hypothetical scenario. A threat actor compromises a supplier’s website and changes the payment instructions posted there. An email directs a customer to that page, and a follow-up call reinforces the request. The address is correct, the company is familiar, and the website belongs to the supplier. Several of the signals we have taught people to rely on are present, yet the transaction is fraudulent.

To be clear, that scenario is illustrative; it is not a claim about what has happened with these PHP flaws. It deserves attention because it exposes a weakness in how we often organize security. The application team investigates the website, the email team examines the message, and the fraud team handles the payment. The adversary benefits from the gaps between them. From the customer’s perspective, it is one experience.

Three changes help close those gaps:

• Bring trust into incident response. When a public-facing system is compromised, find out whether customers were redirected, payment details were altered, credentials were collected, or fraudulent communications went out. Check what your own site is serving, including payment instructions, contact numbers, and the folders where web forms store uploaded files. Give support teams a clear way to help people verify what is legitimate.
• Connect intelligence across channels. A reported email, a suspicious text, and a fraudulent domain are often pieces of the same attack chain. Take down infrastructure the threat actor controls, and work with owners and hosting providers to secure legitimate sites that were compromised. Each action should reduce the adversary’s ability to reach the next person.
• Make verification easier than compliance. Employees and customers need a known process for confirming payment changes and urgent requests, along with explicit permission to pause. That process has to work even when the message looks professional, the caller sounds convincing, and the website appears familiar.

Leaders share the responsibility here. If we demand speed, reward unquestioning responsiveness, and make verification cumbersome, we create exactly the conditions a social engineer looks for.

AI helped defenders find these flaws first. That capability deserves investment, and so do the people who turn findings into fixes. We should also prepare for what happens when a flaw becomes a compromised website, and that website becomes the reason someone trusts a fraudulent request.

A patch closes the vulnerability. Protecting the people who trust the business means following the attack chain all the way to the person it was built to deceive.