PHP2Shell and Custom PHP Applications: Finding and Fixing Forgotten Servers

As of 23 October 2026, PHP has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: a custom PHP application is exposed to PHP2Shell (CVE-2026-109618 and CVE-2026-109619) exactly like WordPress or Laravel, because the flaw is in PHP itself. The difference is that no vendor will email you about it. Nobody tracks your in-house booking tool, the portal a contractor built in 2017, or the old campaign microsite still running on a forgotten server. You have to find every PHP server yourself, then patch or isolate each one.

This guide covers how to find forgotten PHP servers, triage them and confirm the fix. For background, read what PHP2Shell is.

Why Custom PHP Apps Are the Hard Part

When PHP2Shell was announced on 21 October 2026, vendors such as Laravel, TYPO3 and Matomo told their users what to do. A custom app has no such channel. The Dutch National Cyber Security Centre (NCSC-NL), which keeps the most widely cited list of affected software, says so directly: these vulnerabilities "may also occur in custom PHP applications ... Those occurrences are not registered."

Custom apps also tend to share three traits that raise the risk:

• They outlive their builders. The developer or agency moves on, and the server keeps running.
• They sit on old PHP. PHP 8.1 and older get no releases from the PHP project. PHP says "Some distributions and LTS vendors provide backported fixes," but only if someone installs them.
• Nobody owns the server. The app belongs to marketing or operations, the hosting account to finance, and IT may not know it exists.

Step 1: Decide What Counts

CISA's 21 October alert says to "Identify and inventory systems running any version of PHP across your organization. PHP is often a component of other software and prevalence may not be directly observable." Cast the net wide. Anything that runs PHP and answers web requests counts:

• Public websites and landing pages, including old campaign or event sites.
• Staging, test, demo and preview copies, which are often public and rarely patched.
• Customer and partner portals, booking systems, quote calculators and form handlers.
• Internal tools: intranets, HR or inventory systems, reporting dashboards, admin panels.
• Open-source PHP tools your team installed, such as database admin panels, webmail or wikis.
• Servers that run PHP scripts on a schedule and also have a web server installed.
• Windows servers running PHP, where it often runs as php-cgi.exe, and all-in-one installer bundles that ship their own PHP.
• Devices such as firewalls, storage boxes and VPN gateways whose management pages use PHP. NCSC-NL notes PHP is "embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly." Those need the vendor's patch. See our guide to appliances that run PHP.

Step 2: Find the Servers You Forgot

No single method finds everything. Use several and compare the results. These are general approaches. Use them only on systems your organization owns or is authorized to check.

Paper and payment trails

Go through invoices and card statements for hosting, cloud and domain charges. Every monthly hosting bill is a server someone set up. Check old contracts and handover documents from agencies and freelancers. Ask the people who would know: past web developers, marketing staff who launched campaign sites, and department heads who bought software.

Your domains and DNS records

List every domain your organization owns, from your registrar accounts. Then export the DNS zone for each one from your DNS provider. Each hostname that points to a server, such as a portal, staging or old subdomain, is a lead. Note which IP addresses they point to and who controls those servers.

Cloud consoles

Cloud accounts collect forgotten virtual machines and containers, often in regions nobody checks. Each major provider has a cross-account or cross-region inventory view:

• AWS describes Resource Explorer as "a resource search and discovery service," and says it has been "enabled by default" in AWS accounts since 6 October 2025.
• Microsoft says Azure Resource Graph can "query at scale across a given set of subscriptions."
• Google calls Cloud Asset Inventory a service to "view, search, export, monitor, and analyze your Google Cloud asset metadata."

Look for virtual machines, container services and app-hosting platforms. Don't forget accounts opened by individual teams or contractors on their own cards.

Certificate Transparency logs

Certificate authorities submit the certificates they issue to public Certificate Transparency (CT) logs, and browsers such as Chrome and Safari help enforce this. The Certificate Transparency project explains that the logs are "append-only ledgers of certificates" and that "anyone can query them to see what certificates have been included and when." Searching them for your domain shows hostnames that have had certificates issued, including ones that never made it into your records. The project keeps a list of monitors and search services. A monitor can also alert you when a new certificate appears for your domain, which helps catch new servers going forward.

Outside-in checks

Once you have a list of hostnames, check which ones respond on the web and whether they reveal PHP, for example through response headers or a login page that names a PHP app. Our free PHP2Shell exposure check can help with individual sites. US public bodies and critical infrastructure organizations can also ask CISA for its no-cost Cyber Hygiene vulnerability scanning of their internet-facing addresses.

Step 3: Identify the PHP on Each System

For each system, record which PHP version and build serves web requests, and how PHP runs (Apache mod_php, PHP-FPM, LiteSpeed, FrankenPHP, CGI on Windows, or a container). Two warnings:

• The command line can lie. The php -v in a terminal can be a different PHP from the one the web server uses.
• Backported fixes keep old version numbers. A distribution package can be fixed and still say 8.1.2 or 7.4.33. Check the package changelog or build date instead.

Our guide to checking your PHP version explains the reliable methods. If you use a temporary phpinfo() page, delete it as soon as you're done, because it exposes server details.

Step 4: Triage What You Found

CISA says to apply the patch "immediately, prioritizing internet-facing systems." Use a simple order:

Also note whether each system is still needed. An unused server is the easiest one to fix.

Step 5: Patch, Isolate or Retire

1. Patch if you can. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or your distribution's fixed package. Our fixed versions table lists every fixed release and package.
2. Restart every PHP process. An installed update does nothing until PHP restarts. That means PHP-FPM or Apache, plus any background scripts. Our restart guide covers each setup.
3. Isolate what you can't patch yet. ENISA's joint statement advises "isolating exposed applications from public networks until fixes can be applied." Beazley Security adds: use "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials."
4. Retire what nobody needs. Take a backup, shut the server down, then cancel the hosting and clean up its DNS records. Don't delete the backup until you're sure nothing depended on it.
5. Use interim settings only as a stopgap. PHP says its interim measures "reduce exposure to specific attack paths but do not make an installation safe." They are in our interim mitigations guide.

Very old apps on PHP 5.x or 7.x are a project of their own. Our PHP 7 and older guide covers the backport and upgrade options.

Step 6: Confirm, Then Check for Signs of Trouble

For each patched system, recheck the serving PHP version or build and confirm that PHP processes started after the update. Then review logs from at least 17 October 2026, the earliest date a security vendor has reported an exploitation attempt. Look for unusual multipart POST requests, memory-exhaustion errors, worker crashes and new or changed PHP files.

Wiz warns that leaked memory "may contain passwords, authentication tokens, API keys and certificates." A custom app's config files often hold database passwords and payment or email API keys. If anything looks wrong, rotate those secrets and follow your website incident response plan.

Keep the Inventory After the Emergency

The work you do this week is the start of a real asset list. Record each system's owner, purpose, PHP version, hosting account and who patches it. Review it when staff or vendors change. Our guide to headless and custom website security covers the wider supply chain risks that custom builds carry.

Conclusion

Custom PHP apps are where PHP2Shell is most likely to linger, because no vendor will remind you they exist. Start with CISA's instruction to inventory every system running PHP. Use billing records, DNS, cloud inventories and certificate logs to find the forgotten ones. Then patch, restart, isolate or retire each one, starting with anything internet-facing on old PHP. If you need help with the search or the fixes, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions