PHP2Shell: Protect Self-Hosted Apps from CVE-2026-109618 and CVE-2026-109619

Two critical PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and known as PHP2Shell, are being exploited in the wild. They sit in the PHP runtime itself, not in a plugin or theme, so any web-facing PHP install is in scope: WordPress, Magento, custom apps, admin panels, and other self-hosted stacks.

AWS reported exploit attempts as early as October 17, days before public disclosure. Cloudflare saw the volume climb from thousands of attempts before disclosure into millions afterward, with attackers mutating payloads to get around WAF rules.

What PHP2Shell does

Both bugs involve unsafe memory handling when PHP fails mid-request. An unauthenticated attacker can send crafted HTTP traffic and, in the worst case, crash the process, leak data, or run code on the server.

Because this is a runtime flaw, updating WordPress or a plugin is not enough. You need a patched PHP binary.

Patch first

Update to a fixed release as soon as you can:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

If your host manages PHP, ask them to apply the security update. Keep any WAF rules enabled while you patch; they are helpful defense-in-depth, not a replacement for the fix. Temporary mitigations exist in the PHP advisory, but the advisory is clear: only updating is a complete solution.

Keep private apps off the open internet

Patching closes this hole. Access architecture reduces the next one.

A lot of self-hosted PHP is not meant for anonymous public traffic: admin UIs, internal tools, staging sites, billing panels, and ops dashboards. If those apps accept HTTP from the open internet, every new unauthenticated PHP bug is a direct hit on the runtime.

There are two strong patterns here. Pangolin supports both.

Authenticated reverse proxy

An identity-aware reverse proxy sits in front of the app and requires login before traffic is forwarded. Unauthenticated scanners and exploit traffic stop at the proxy. Even if the underlying PHP app is later compromised, you still have a separate access layer controlling who can reach it.

This fits when users need browser access without installing a client, and you are willing to publish a hostname that still requires identity before the origin sees the request.

Identity-based VPN and private reverse proxy

A step further is to take the app entirely off the public internet.

Users connect with an identity-based VPN client over a secure tunnel. Once connected, a reverse proxy serves the app on that private path with a valid certificate, so the browser experience stays as normal HTTPS, but the hostname is only reachable inside the tunnel. From the internet’s point of view, there is nothing to probe. No public listener means no unauthenticated PHP2Shell traffic against that app.

This is useful when:

• the app should only be used by your team or approved machines
• you want zero public exposure, not just an auth gate on a public URL
• you still want clean hostnames and TLS for private web apps after the client is connected

Public sites that must stay anonymous still need the PHP patch immediately. For everything that does not need to be public, stop letting the internet talk to PHP directly, either with auth at the edge or by keeping the whole path private.

Conclusion

PHP2Shell is a reminder that self-hosted security is layered. First, you should patch the runtime. Then, you can decide which apps truly need a public front door and which should stay private.