Was my WordPress site hacked by PHP2Shell?

A patch doesn’t undo a break-in

If you’ve just updated PHP for PHP2Shell (the pair of PHP-runtime bugs CVE-2026-109618 and CVE-2026-109619), well done — but notice what the update does and doesn’t do. Patching PHP stops new exploitation. It does nothing to anything an attacker already planted while your site was exposed: a rogue administrator account, a backdoor file in your uploads folder, a scheduled task that re-infects you after every clean-up.

That’s the uncomfortable part of any serious vulnerability. The fix and the clean-up are two different jobs. This guide is only the first one: working out whether anyone got in. It’s deliberately calm and entirely defensive — a list of things to look for, not a way to attack anything. If you turn up a warning sign, the recovery checklist is where you go next.

Were you even exposed?

Before you comb through logs, establish two things: were you running a vulnerable PHP build, and for how long. If the answer to the first is “no” — your host patched or mitigated before you were ever reachable on an unpatched runtime — the rest of this becomes a quick sanity check rather than an investigation.

The dates that frame the window:

1. 1 Aug 2026

   Bugs first reported

   Roughly when researchers reported the issues to PHP. Security vendors suggest reviewing admin logins back to here as a precaution — not because exploitation started then, but because it’s a safe outer edge.

2. 17 Oct 2026

   First attempt on record

   Amazon’s threat-intelligence team logged an exploitation attempt against its sensors, four days before patches — while the bugs were still under embargo.

3. 20–21 Oct 2026

   Details leak, then fixes ship

   Information spread publicly on 20 October; PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. Mass scanning climbed from thousands of attempts to millions after the announcement.

4. The moment you patched

   Your window closes

   Your exposure window runs from whenever your server became reachable on an unpatched build until the moment patched PHP workers restarted. If that overlaps 17 October onward, check carefully.

Not sure whether the version you were on was vulnerable? This three-question checker runs entirely in your browser and tells you where a given PHP version stands. It won’t tell you whether you were hacked — nothing automatic can — but it settles the “was I even vulnerable?” question first.

Still unsure what your host actually did, or when? That’s a fair question to put to them directly — our guide on how to ask your host whether they’re patched has a copy-and-paste email, including the key question of when PHP was restarted.

The compromise checklist

Here’s the whole thing as an interactive list. Tick items as you check them; press Found this on anything that looks wrong. Your ticks are saved in this browser, so you can stop and come back. The sections after it explain each group in more detail, including the commands to run.

What the logs reveal

Logs are your best witness, because PHP2Shell’s most reliable triggers leave a shape in them. The attack paths that worry researchers most go through PHP’s multipart parsing and session upload-progress handling, which run before WordPress loads a single line. So the tell-tale requests often land on URLs that have no business receiving an upload at all.

In your web server access log (and your WAF log, if you have one), you’re looking for:

• Multipart POSTs to the wrong places — upload-style requests aimed at your homepage, a feed, or paths that never accept files.
• The PHP_SESSION_UPLOAD_PROGRESS field — if your WAF records request bodies or field names, this one is a strong signal because it was a demonstrated remote trigger.
• Oversized requests — abnormally large multipart bodies or thousands of form fields.
• Oversized PHPSESSID values — a memory-disclosure technique leaked around 67 KB of server memory per attack through an inflated session cookie.

In the PHP error log, the signature of the out-of-memory technique is a spike of Allowed memory size … exhausted messages, sometimes alongside worker segfaults. On their own these have ordinary causes, so don’t panic at one. What matters is a sudden cluster around your exposure window — then line those timestamps up against the access log and see what was being requested at the same moment.

# Upload-progress trigger and multipart posts in the access log$ grep -i 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/nginx/access.log*$ grep -iE 'multipart/form-data' /var/log/nginx/access.log* | grep ' POST '# Memory-exhaustion spikes and worker crashes in the PHP error log$ grep -iE 'Allowed memory size|exhausted' /var/log/php*-fpm.log*$ grep -iE 'signal 11|segfault|child .* exited' /var/log/php*-fpm.log*# POSTs to the homepage around the exposure window (adjust the date)$ grep ' POST / ' /var/log/nginx/access.log | grep '17/Oct/2026'

Signs on the server

If an attempt turned into code execution, the next traces are on the filesystem and in the process list. Successful code execution with the web server’s privileges typically shows up as one or more of the following.

Out-of-place code

.php files in wp-content/uploads, or unfamiliar files in the web root and mu-plugins

Spawned processes

sh, bash, curl, wget, python or perl with php-fpm or Apache as the parent

Outbound traffic

Connections from PHP processes to unfamiliar hosts or IPs

New persistence

Cron jobs, systemd timers or SSH keys you didn’t add

The media library is the clearest tell: it should contain images, video and documents, never executable PHP. A single .php file in wp-content/uploads is reason enough to treat the site as compromised. The same goes for anything in mu-plugins you can’t explain, since must-use plugins load automatically and can’t be switched off from the admin.

# PHP files where only media should live$ find wp-content/uploads -type f -name '*.php'# PHP files changed since the first recorded attempt$ find . -type f -name '*.php' -newermt '2026-10-17' -not -path './wp-content/cache/*'# Must-use plugins (there may legitimately be none)$ ls -la wp-content/mu-plugins 2>/dev/null# Administrators and when they were created (WP-CLI)$ wp user list --role=administrator --fields=ID,user_login,user_email,user_registered# Core files that differ from the official release$ wp core verify-checksums

None of this modifies anything — it only lists and compares. If a command above surfaces something you can’t account for, don’t start deleting. Preserving the evidence is what lets you (or a professional) work out how far the intrusion went, and the recovery checklist explains the order to clean up in.

Signs inside WordPress

Some evidence never touches a log you can read — but it surfaces inside WordPress and in Google. These are the signs a non-technical site owner is most likely to notice first, and they’re worth checking even if you have no server access.

1. 1

   Step 1: Unknown administrators

   Open Users › All Users and filter by Administrator. An account you didn’t create — especially one registered during your exposure window — is a serious red flag. Note it; don’t delete it yet.
2. 2

   Step 2: Plugins you didn’t install

   Check Plugins › Installed Plugins and the Must-Use tab. Attackers add plugins to keep a foothold, and must-use plugins are a favourite hiding place because they can’t be deactivated from the dashboard.
3. 3

   Step 3: Spam pages and redirects

   Search site:yourdomain.com for pages you never wrote — pharma, casino, counterfeit goods or foreign-language spam. Redirects often fire only for visitors arriving from Google, or only on mobile, so you may not see them while logged in.
4. 4

   Step 4: Search Console security issues

   Open Search Console › Security & Manual Actions › Security issues. A “Hacked: content injection” or similar flag is Google telling you it found something you haven’t.
5. 5

   Step 5: Host and antivirus warnings

   A malware, spam or resource-abuse notice from your host, or readers reporting that their antivirus blocks your site, is external confirmation worth taking seriously.
6. 6

   Step 6: Unexplained admin logins

   If you log logins, review successful administrator sign-ins back to 1 August 2026 for odd times, locations or IPs. No login log? Your host’s access logs are the fallback.

You found something — now what

If you flagged anything above, treat the site as compromised until you’ve proven otherwise. The instinct is to start deleting the scary files immediately; resist it for ten minutes, because deleting evidence makes it far harder to tell how far the attacker got and whether they left a way back in.

1. 1

   Step 1: Contain, don’t delete

   Put the site behind maintenance at the server or CDN level, or take it offline. A maintenance-mode plugin isn’t enough — it runs inside the compromised software.
2. 2

   Step 2: Preserve the evidence

   Snapshot files, a database export and your logs before changing anything. Even an infected copy is useful, and it’s a fallback if the clean-up goes wrong.
3. 3

   Step 3: Confirm PHP is patched

   There’s no point cleaning while the door is still open. Make sure PHP is on a fixed build (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport) and that workers were restarted.
4. 4

   Step 4: Rotate every secret

   Because PHP2Shell can leak worker memory, assume passwords, tokens and API keys were exposed. Our guide on rotating WordPress security keys and secrets walks through the full list.
5. 5

   Step 5: Clean up in order

   Follow the WordPress hacked recovery checklist: restore a clean backup from before your exposure window, or rebuild from official sources, then request a Google review.

For a site that handles payments, member accounts or personal data, bring in professional help early — you may have legal duties to work out what was accessed, not just to make the symptoms disappear.

Why PHP2Shell can’t touch Presscomet

PHP2Shell is a bug in the PHP runtime. Presscomet has no PHP runtime — it runs the same wp-admin, block editor, URLs and REST API on Node.js with a single SQLite file — so PHP2Shell and the whole class of PHP-runtime vulnerabilities simply don’t apply to it. There’s no PHP worker memory to leak and no multipart parser to abuse.

That’s a genuine reduction in attack surface, not a magic shield, and it’s worth being honest about the edges. Presscomet still has its own software to keep updated — Node.js, its libraries and the server it runs on — and its own login to protect, so nobody should call it unhackable. It also doesn’t run PHP plugins: the common jobs (SEO, forms, SMTP, redirects, security, custom fields) are built in, but WooCommerce stores aren’t supported. The trade-offs are laid out on our WordPress security page.

And if you came through this clean: keep your logs for a few weeks, re-check your administrator list and a site: search next week, and — if you were exposed at all — rotate your secrets as a precaution. Then run the broader WordPress security checklist so the next runtime bug is someone else’s emergency, not yours.