Hacked After PHP2Shell or Node2Shell?

Patching closes the hole. It removes nothing an attacker left behind. If your PHP or Node.js server was reachable from the internet and unpatched while exposed, and you see no sign of compromise, restart it on a fixed build, keep your pre-17 October backups before anything overwrites them, then check what changed and prioritize the secrets the web process could read.⁠⁴ If you do see signs, or can't rule them out, the FBI advises isolating the affected system and preserving web server and PHP logs before you clean anything.⁠²

The complete PHP2Shell guide covers the flaws themselves. This article covers the step after the patch.

What is confirmed, and what isn't

The evidence is uneven, so the dates matter.

• 17 October. Amazon recorded the earliest known exploit attempt on its honeypots, four days before the fixes. That is an attempt, not a confirmed intrusion.⁠³
• 21 October. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35.⁠¹ Node.js shipped its fix the same day.⁠⁹
• 24 October. Researcher Adel Karimi logged 35 shells on three honeypots running PHP 8.4.26 under Apache mod_php. His findings fit exploitation of CVE-2026-109618, and he found no evidence the second PHP flaw was involved. His single-worker setup favors the attacker, so it says little about how reliably the attack works on production servers.⁠³ These are honeypot results, not compromises of real organizations.
• 26 October. CISA added both PHP CVEs to its Known Exploited Vulnerabilities (KEV) catalog. The Register reports a 29 October deadline for US federal civilian agencies, a date CISA's bulletin itself does not state. CISA named no victims.⁠³⁠²⁰ Earlier success claims from Sophos and Palo Alto Networks were walked back or withdrawn.⁠³
• 27 October. CISA added the Node.js flaw to KEV, with a reported 10 November federal deadline. It published no attack details.⁠¹⁸ Previdian logged one attempt on 27 October. ELLIO caught a malicious request on 26 October, but says the attacker's own final stage produced no shell in any of its 50 tests.⁠¹⁸
• 26 October onward. Reported Dream Research described a campaign that chained the PHP flaws with the Linux kernel flaw Fragnesia (CVE-2026-46300) to root 25 firewall and management servers in the US, Japan, Taiwan and South Korea, one of them tied to a US government-affiliated network.⁠¹⁷⁠¹⁹ Palo Alto Networks says its Unit 42 independently verified the attacker's tooling and confirmed the reported results.⁠⁸ Verified tooling shows the exploit chain works. The victim count is Dream's, and no victim is named publicly. CISA added Fragnesia to KEV on 28 October and said it can be chained with the PHP flaws to run commands as root.⁠⁶ The reported Dream campaign targeted appliance management interfaces. I found no ordinary website or company named as breached.

How you'd notice

Treat everything below as leads, not proof. Most of it comes from honeypot captures and vendor write-ups. I found no published web-shell names or file hashes from a real victim to match against.⁠¹⁶

In logs

Log patterns and what they mean goes deeper. The short list:

• PHP errors reading "Allowed memory size … exhausted … in Unknown on line 0", which means memory ran out before any script started. Also Apache workers exiting with a segmentation fault (signal 11), sometimes in runs.⁠¹¹
• Large multipart POSTs to / or any .php path with no User-Agent, or with the User-Agent php2shell-109618, which Fastly saw from the most widespread exploit kit.⁠⁵ Fastly says User-Agent signatures go stale within a day. It found the multipart boundary string more reliable, and it says to rule out look-alike wp2shell and React2Shell traffic first.⁠⁵
• The final step can leave no normal log line, because the worker dies right after launching the shell. Hunting only for HTTP 500s misses it.⁠¹¹

On the host

• PHP workers (php-fpm, php-cgi, httpd, apache2) starting shells, or downloading files with curl, wget or nc.⁠² Karimi's honeypots also ran id, hostname and uname -m, and tried to write proof files to temp and web-root paths.⁠¹²
• Reported Eon's guide lists new PHP files in web roots, executables in /tmp, /var/tmp or /dev/shm, auto_prepend_file entries in .user.ini or .htaccess, and new cron jobs, systemd units, SSH keys or accounts.⁠⁴ These are common persistence spots, not traces tied to a published PHP2Shell case.
• The web user reading ~/.aws/credentials, .env files or the cloud metadata address.⁠⁴
• If Fragnesia was in play, the attacker had root, so the whole host is suspect, not just the web user. Whether a given kernel is affected depends on your distribution's advisory and backports, so check those instead of the kernel's release date.⁠⁶

In cloud accounts, from 17 October

Reported Eon, a backup vendor, suggests checking audit logs for snapshots or images shared with outside accounts, snapshot copies, deleted backups, changed backup-vault policies, and a caller-identity check, which often comes first when stolen keys are tested.⁠⁴ These are generic stolen-key signs, not PHP2Shell-specific ones.

On Node.js hosts

Measured In Tanium's lab, the exploit replaced the Node.js process instead of launching a shell, so "Node started a shell" detection sees nothing. Each failed guess crashed the service, and restarts repeated within minutes. The same Node.js version installed directly on the host only crashed.⁠⁹ Look for restart loops, and check containers and unpackaged copies under /opt. A patched Node.js keeps reporting its old Brotli version, so the version string misleads.⁠⁹

Source IPs

Amazon, Karimi and CYFIRMA published address lists. Many are shared or anonymization infrastructure. Investigate a match instead of blocking on it.⁠¹²

Why a clean result isn't proof, and why a bad one isn't a given

• Fastly says success is not visible from the edge, because a successful attempt and a failed one can look the same.⁠⁵
• Your logs may not record request size, which hides the large bodies.⁠⁴
• Modification times are easy to fake. Check change time too.
• Reported Wiz reports one path can leak process memory, including passwords, tokens, API keys and certificates.⁠¹³ Opinion If a server was exploited that way, there may be no file on disk to find.
• A scanner reports whether a server is vulnerable today. What scanners can't tell you is whether someone got in earlier.

None of this means your server was breached or that credentials were stolen. SecurityWeek writes that, despite broad exploitation attempts, success has been attributed to very few threat actors.⁠⁸ The point is narrower: a clean log is weaker evidence than it looks.

Do this

Do today

1. Triage first. If you see signs of compromise above, or can't rule it out on a server that holds sensitive data, isolate it from the network before you restart anything, and preserve web server and PHP logs, as the FBI advises.⁠² Opinion Capture volatile evidence you can grab quickly, such as running processes and network connections, but don't delay containment to collect it. Then rebuild or restore through a controlled process instead of simply restarting. If you see no signs, go to step 2.
2. Patch and restart every PHP worker and every Node.js process, then confirm the running version. Ubuntu says applications using the interpreter would likely need a restart after the update.⁠¹⁴ Patch and restart first has the steps. Restoring a backup does not fix the flaw.⁠⁴ For the Linux kernel, check your distribution's security advisory for CVE-2026-46300, your installed kernel package and whether the fix is backported, then install the fixed package if your kernel is affected.⁠⁶
3. Preserve evidence before cleaning. Keep the newest backup from before 17 October and every backup between 17 October and your patch date. A 7-day retention policy may already have deleted the baseline.⁠⁴ Store copies where the web server's cloud credentials can't reach them. If you find signs of compromise, the FBI advises reporting to your local FBI field office or ic3.gov.⁠²
4. Rotate secrets in priority order. Eon recommends rotating every secret the web user could read on any internet-facing server that ran a vulnerable version, even without evidence of compromise.⁠⁴ Rotation has operational cost, so start with the highest-risk credentials: cloud keys and tokens with write or admin rights, database and payment credentials, and signing keys. Revoke active sessions and tokens where appropriate, coordinate with the services that depend on each secret, and check cloud audit logs before and after. If compromise is confirmed or likely, rotate from a trusted machine, not the suspect host, and only after that host is isolated or rebuilt. Opinion A memory leak leaves no trace, which is a reason to rotate. It is not evidence that yours leaked.
5. Take the system offline if you can't patch or investigate quickly. The FBI advises this until it can be fully mitigated.⁠²

Do this week

6. Compare a pre-17 October snapshot with the current one in an isolated account, mounted read-only. Check web roots and persistence locations by checksum, scan the copies for web shells, and check databases for new admin users, altered settings and changed payment or contact details.⁠⁴

7. Review cloud audit logs back to 17 October.
8. Restore selectively. Patch first, then restore only what changed, from the last clean restore point.⁠⁴
9. Consider an incident responder if you hold customer data. Opinion That is a judgment call, not a rule. If customer or personal data may have been exposed, check your legal and contractual notification duties with a qualified adviser.
10. Set session.upload_progress.enabled=0 for the separate flaw CVE-2026-115560, which has no fix yet. PHP says applications that never switch the serialize handler at runtime can leave it on.⁠¹ The interim setting has the per-server syntax.

Can wait

11. Attribution, meaning who did this.
12. Blocking by IP address alone.
13. Rewriting your whole stack.