PHP2Shell: the first 24 hours of a critical RCE

On Tuesday, October 20, 2026, details leaked of two flaws in PHP, the language behind most of the websites in the world. Researchers called the pair PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both rated critical at 9.2 out of 10). Each one is a remote code execution flaw, or RCE: a stranger on the internet can send a request and run their own commands on your server, with no password. The PHP project said fixed versions would ship the next day at 14:00 UTC. Security vendors were already reporting attack attempts.

I run a small set of servers for . On one of them, two services run PHP, and that morning anyone on the internet could reach both. This is the first day of the response, in the order I did things. The order mattered more than the speed.

What was exposed

Two services on the same host ran PHP:

• , the self-hosted platform that deploys every other app on the host. Its sign-in page answered anyone on the internet.
• A project-management app. Every page sat behind my single sign-on (SSO) gate, except one API route that skipped it.

The two were not equal risks. holds the Docker socket, the host’s SSH keys and the secrets of every app it deploys. The Docker socket is the control channel for all the containers on the host. So whoever runs code inside controls the whole host. Code execution in the project app would give an attacker that app, its database and a foothold on the internal network. Bad, but smaller.

Nothing else on the host ran PHP, and the host itself had none.

There was also no complete workaround. The interim advice was to turn off one PHP feature, session upload progress, and to limit file uploads. Both lowered the risk. Neither removed it.

The day, hour by hour

Times are UTC, from my notes. A tilde (~) marks a time I logged as approximate. In the diagram, red dots run the flawed PHP, hollow dots run no PHP, and solid dark dots are patched. The dashed circle is the allow-list at the reverse proxy, the server that receives every request before the apps do.

Closing it at the edge

The allow-list did the most work for the least effort. It took about ten minutes, needed no patch and no restart, and stopped every request from an unknown address before PHP saw it.

I use Traefik as my reverse proxy. Traefik reads extra rules from files and picks them up without a restart, which is what made this a ten-minute fix. I left the existing routes alone and added one new file. It matches the same hostname at a higher priority, so its rules are checked first, and it puts an allow-list in front of the dashboard. Here is the pattern, with documentation addresses and an example domain:

# Matches the dashboard's hostname at a higher priority than the existing
# routes, so these rules win. Unknown sources get 403 before PHP runs.
http:
  middlewares:
    admin-only:
      ipAllowList:
        sourceRange:
          - 198.51.100.7/32   # my workstation
    github-hooks:
      ipAllowList:
        sourceRange:
          # Stand-ins: copy the real "hooks" ranges from api.github.com/meta.
          - 192.0.2.0/26
          - 203.0.113.64/27

  routers:
    dashboard-guard:
      rule: Host(`deploy.example.com`)
      priority: 2000
      entryPoints: [https]
      middlewares: [admin-only]
      service: dashboard@docker
      tls: {}
    github-webhooks:
      rule: Host(`deploy.example.com`) && PathPrefix(`/webhooks/github/`)
      priority: 2100
      entryPoints: [https]
      middlewares: [github-hooks]
      service: dashboard@docker
      tls: {}

Four things to check before you trust a rule like this:

1. The proxy must see the real client address. If it only sees an internal address, an allow-list lets in everyone or no one. My workstation’s single address matched, which proved the real addresses arrived.
2. Keep the paths that must stay open. Webhooks from your Git server and from GitHub need their own routes. GitHub publishes its webhook source ranges at api.github.com/meta. Copy them when you write the rule, and refresh them later.
3. Plan for lockout. If your own address changes, the dashboard answers 403 to you too. Know how to reach the server another way, and which line to edit.
4. Test from every side. From the allowed address, from a refused one, and from each webhook source. Then test again after every upgrade.

The notice

The same day I also sent a short notice to the people who use these services. It said three things: you are safe, you need to do nothing, and expect scam emails. Here it is, lightly edited for this page.

The notice, October 21, 2026

On October 20, details leaked about a serious flaw in PHP. PHP is software that runs most of the websites in the world. The flaw lets attackers take control of a website without a password, and attacks already started.

The services you use are safe. Your portal, chat and sign-in do not use PHP. I closed my two internal PHP tools to the internet within hours, and I found no sign of misuse. You do not have to do anything.

The rest of the internet is at risk. Many stores, blogs and other sites that you use will be slow to install the fix. Attackers will steal data from them and use it in fake emails for weeks or months.

To stay safe:

1. Do not click links in unexpected “security update” or “reset your password” emails.
2. Use a different password for each account, and turn on two-step sign-in.
3. If you own a website, ask your web host if it uses PHP and has the October 21 fix.

I will never ask for your password or send you a link to fix this. If a message from me looks wrong, call the number that you already have for me.

What I left out matters as much as what I put in. There are no version numbers, no list of systems and no promise that nothing can ever go wrong. Most readers need to know one thing: do I have to act? The second paragraph answers that. The rest prepares them for what comes next, because the scam emails that follow a flaw like this reach far more people than the flaw itself.

What I would do again

1. Look before you touch. Ten minutes of read-only inspection told me what ran PHP, what was reachable and what was not. Every later step depended on it.
2. Rank by blast radius, not by count. Two exposed services is not two equal problems. Close the one that controls everything else first.
3. Take away reach before you can remove the flaw. An allow-list at the proxy needs no patch. It also stays useful after the patch: a deployment dashboard has no reason to be public.
4. Keep a person in the loop for changes to the control plane. The agent was fast, and its proposed rollback was reasonable. Its permission check still stopped it and waited for me. That pause cost nothing.
5. Test the mitigation again after every change. My own rule broke during the upgrade. A second test found it within half an hour.
6. Tell people early, in plain words. Say whether they must act, and warn them about what follows.

Sources

• PHP project, “Upcoming Critical PHP Security Release”, October 20, 2026, as quoted on the oss-security mailing list.
• Help Net Security, PHP2Shell vulnerabilities patched (CVE-2026-109618, CVE-2026-109619), October 21, 2026.
• Qualys, PHP announces critical security release for two vulnerabilities, October 20, 2026.
• GitHub, meta API, for webhook source ranges.
• W3Techs, usage statistics of PHP.