PHP2Shell and the hosts nobody owns

The first step in CISA's PHP2Shell alert is an inventory: "Identify and inventory systems running any version of PHP across your organization." The patch is easy once you know where PHP lives. Knowing where it lives is the hard part.

On Oct. 21, CISA strongly urged organizations to immediately patch CVE-2026-109618 and CVE-2026-109619, which it says allow unauthenticated remote code execution and affect all PHP installations serving web requests. The alert lists fixed releases (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35) and says organizations that cannot update, or that still run PHP 8.1 or earlier, should take those systems offline until they can be patched. It also warns that PHP "is often a component of other software and prevalence may not be directly observable."

Two details from the first week matter for planning. CISA said that as of publication it had not observed successful exploitation in the wild. Amazon's threat intelligence team then reported a PHP2Shell exploitation attempt against its MadPot honeypots dating to Oct. 17, four days before public disclosure, said it was unclear whether those early attempts would have succeeded against real systems, and later described broad exploitation attempts in the wild. Amazon's lesson for defenders was direct: "defenders should not assume the public disclosure date is the earliest date of exploitation."

Why the forgotten hosts are the real exposure

The PHP servers your engineering team runs on purpose will get patched this week. They are in the deployment pipeline, someone gets paged for them, and the change is routine.

The ones that worry me are the others. The marketing microsite from a launch three years ago. The WordPress blog a previous agency set up. The support portal that came with an acquisition. The domain someone registered for a conference and never took down. The vendor appliance with a PHP admin panel nobody thinks of as PHP. These sit on the internet, they still answer requests, and nobody has their name next to them.

That is a governance gap. A host with no owner has no one to receive the alert, no one to approve downtime, and no one who can say whether it is safe to turn off. Amazon's advice to measure patch and mitigation timelines in hours for critical internet-facing systems is impossible to meet for a server you cannot find.

A checklist for finding what you forgot you own

This is defensive inventory work. None of it touches anyone else's systems.

1. Start from domains, not servers. Pull every domain the company has registered, from every registrar account you can find, including ones on personal or departmental cards. Then list every DNS record under each. Forgotten hosts usually still have a DNS name pointing at them.
2. Check certificate transparency logs for your domains. Every public TLS certificate issued for a name you own is logged, which often surfaces subdomains no one remembers creating.
3. List every cloud account and hosting provider. Ask finance for every recurring charge from a hosting, cloud, or website company. Small, steady charges are often the forgotten sites.
4. Ask the departments. Marketing, events, HR, and sales are the usual owners of sites engineering never built. Ask each one what websites, landing pages, or portals they have paid for or had built.
5. Include acquisitions and agencies. Anything inherited in a deal or built by an outside agency belongs on the list, along with who still holds the credentials.
6. Look inside products you bought. CISA's point about PHP being a component of other software applies to appliances, CMS platforms, and admin panels. Ask vendors directly whether their product includes PHP and which version.
7. Write down an owner for every host. A named person. A team alias does not count. If no one will take it, that is your answer about whether it should still be online.

Decide, then patch

Every host on that list gets one of three decisions: patch it now, take it offline until it can be patched, or retire it. CISA's own guidance already covers the second option for systems that cannot be updated. For a forgotten campaign site, retirement is often the right call, and it is cheaper than maintaining something nobody uses.

Patch internet-facing systems first, as CISA advises. Then, because exploitation attempts may predate the advisory, ask whoever owns each host to check for the signs CISA lists, such as PHP worker processes launching shells or downloading tools. For an orphaned host, there may be no logs worth reviewing, and that by itself is a reason to rebuild or retire it rather than patch in place.

What this has to do with AI readiness

The same inventory question is coming for AI. Teams are standing up internal tools, agent backends, and demo apps quickly, often on whatever stack is fastest, and often outside the main deployment pipeline. In two years those will be the forgotten hosts. A company that can answer "what do we run, and who owns it" for its websites today will be able to answer it for its AI systems tomorrow. One that cannot will be doing this same scramble with higher stakes.

For leadership, the useful question this week is simple: how many internet-facing hosts do we have, and how many of them have a named owner? If nobody can answer the first number, the second does not matter yet.

Start with the domain list

Pull every domain the company owns and every DNS record under it, and put an owner's name next to each host. Anything left without a name by the end of the week should be taken offline until someone claims it.