Latest / Modularity Podcast / PHP2Shell: What WordPress Site Owners and Hosts Need to Know

Transcript

PHP2Shell: What WordPress Site Owners and Hosts Need to Know · Modularity Podcast

• 0:00
  What if your WordPress site could be taken over by a visitor who never touches
• 0:03
  WordPress at all?
• 0:05
  No login, no vulnerable plugin, nothing.
• 0:08
  That's the situation with PHP2Shell, and Dave, I want to make sure people understand
• 0:13
  the bug lives underneath their site, not in it.
• 0:16
  Right, and that's the part that trips people up.
• 0:19
  PHP is the engine.
• 0:20
  WordPress, Drupal, Joomla, MediaWiki, they're all applications running on top of it.
• 0:27
  PHP2Shell is actually two vulnerabilities, CVE twenty twenty six,
• 0:32
  one oh nine six one eight and CVE twenty twenty six, one oh nine six one nine.
• 0:38
  Both are rated 9.2 on the CVSS version 4 scale.
• 0:43
  The researchers showed an unauthenticated attacker can run their own code on the
• 0:48
  server.
• 0:49
  The researchers at Wiz put it plainly: even a bare Hello World script on an affected
• 0:55
  PHP version can be vulnerable.
• 0:57
  And the timeline matters here.
• 0:59
  This was supposed to be a coordinated disclosure on October 22nd.
• 1:03
  Details leaked on social media on October 20th, so the PHP team moved up and
• 1:09
  announced an emergency release for Wednesday, October 21st at 14:00 UTC.
• 1:15
  Then watchTowr reported seeing exploitation in the wild through its honeypot network
• 1:20
  on that same day.
• 1:21
  And the NSA put out an advisory telling organizations to inventory their internet
• 1:26
  facing PHP and patch.
• 1:29
  Which, for the NSA to name a programming language in a press release,
• 1:34
  tells you something.
• 1:36
  So let me walk through the mechanism, because it's actually elegant in an ugly way.
• 1:40
  Picture a PHP worker, the process that handles your web requests.
• 1:45
  It handles one request, then another, and it reuses memory and internal bookkeeping
• 1:50
  between them.
• 1:51
  Now, at the very start of a request, PHP parses multipart uploads,
• 1:57
  the kind of request a file upload form sends.
• 2:00
  That happens early, before normal initialization is finished,
• 2:04
  and before any WordPress code has run.
• 2:06
  So there's a window where PHP is half set up.
• 2:09
  Exactly.
• 2:10
  If PHP runs out of memory in that window, it hits a fatal error.
• 2:15
  It destroys the memory heap for that request, but some internal pointers still point
• 2:20
  at the memory that was just thrown away.
• 2:22
  The cleanup never finished.
• 2:23
  Then the next request handled by that same worker comes in,
• 2:27
  and PHP trusts those stale pointers as if they were live data.
• 2:32
  If an attacker has arranged for that freed memory to be reclaimed with content they
• 2:36
  control, PHP is now acting on attacker data.
• 2:40
  That's the use after free idea, right?
• 2:42
  Something gets freed, but the program keeps a reference to it.
• 2:45
  Yes.
• 2:46
  And it shows up in a few ways.
• 2:47
  In one, PHP can end up reading that reclaimed memory and putting its contents into a
• 2:53
  PHPSESSID cookie in the response.
• 2:57
  That's a memory disclosure, and the researchers said the memory can contain
• 3:01
  passwords, tokens, API keys and certificates.
• 3:05
  It works even if the app never starts a session.
• 3:09
  In the others, a fatal error backtrace pointer goes stale, or the OPcache,
• 3:15
  which stores compiled PHP in shared memory, gets confused about object types between
• 3:20
  workers.
• 3:21
  Those paths lead to corrupted memory and code execution.
• 3:25
  And just to be clear for the listener, the researchers demonstrated working remote
• 3:30
  code execution against the latest container images of WordPress,
• 3:34
  Drupal and Joomla.
• 3:36
  Those were representative targets.
• 3:38
  The bug doesn't care which CMS you run.
• 3:41
  Here's what bugs me, though.
• 3:42
  These flaws were old.
• 3:44
  The Wiz write up says the vulnerable code goes back more than a decade,
• 3:48
  and they say every PHP version in the last decade is affected by at least one of
• 3:53
  them, back to 5.4.
• 3:56
  So why now?
• 3:57
  That's the AI piece, and I think it's the most important takeaway from the whole
• 4:00
  story.
• 4:01
  The researchers say the hard part was never spotting that something looked off.
• 4:05
  The hard part was turning it into a reliable exploit.
• 4:08
  You have to chain several flaws together, and memory layouts differ across PHP
• 4:13
  versions, configurations, and applications.
• 4:16
  An exploit that works on one server can fall apart on the next,
• 4:20
  and every adjustment means more debugging.
• 4:22
  Which used to be a human bottleneck.
• 4:24
  You needed rare people with lots of time.
• 4:27
  Right.
• 4:27
  Wiz says they used frontier models, Gemini 4 Argon and GPT five point six Sol,
• 4:34
  along with their own tool, Wiz Atlas, to debug failures and adapt working exploits
• 4:39
  across multiple applications in hours.
• 4:41
  Their claim is that a single researcher finished in about a week what would have
• 4:45
  taken a world class team months.
• 4:47
  That's their framing, and they're a security company with a stake in the story,
• 4:50
  so weigh it that way.
• 4:52
  But the direction is hard to argue with.
• 4:55
  Complexity used to be a kind of protection, and it's getting weaker.
• 4:58
  And it cuts both ways.
• 4:59
  The same tools help defenders find these things before attackers do.
• 5:03
  But when you're a host, the practical lesson is that the gap between a bug being
• 5:07
  disclosed and a bug being weaponized is shrinking.
• 5:11
  watchTowr saw exploitation the same day as the patch.
• 5:14
  Which is why speed on our side matters more than ever.
• 5:18
  So let's talk about what a responsible host actually does in a moment like this.
• 5:22
  First, the shared responsibility model, because it explains who owns what.
• 5:27
  As a host, we own the runtime: the PHP engine, the web server,
• 5:32
  the operating system libraries.
• 5:34
  Our customers typically own the application layer: WordPress core,
• 5:38
  plugins, themes, user accounts.
• 5:41
  PHP2Shell sits entirely in our half.
• 5:44
  So when we talk to customers, the headline is that for this specific issue,
• 5:48
  there's nothing they need to patch themselves.
• 5:50
  And what we did started before the official fix existed.
• 5:54
  We tightened firewall rules, and added extra protections where they applied.
• 5:58
  Hosts that were in the loop could look at the shape of these attacks,
• 6:02
  things like malformed multipart uploads and odd session headers,
• 6:07
  and filter at the edge.
• 6:08
  That buys time, but I want to be honest about it.
• 6:11
  It's a stopgap.
• 6:13
  PHP itself says no configuration change fully mitigates this.
• 6:18
  The real fix is the patched engine.
• 6:21
  Then the patches roll out.
• 6:22
  The fixed releases are PHP 8.5.12, 8.4.27,
• 6:30
  8.3.36 and 8.2.35.
• 6:35
  And here's a detail people miss: updating the binary isn't enough on its own.
• 6:41
  The workers hold state in memory, and that stale state is the whole problem.
• 6:45
  So you restart the PHP workers after updating so the fix takes effect.
• 6:51
  That's why some customers might see a brief service restart.
• 6:54
  We'd rather do rolling restarts and keep it short than leave a poisoned worker
• 6:59
  running.
• 7:00
  And we watch.
• 7:01
  The researchers suggest signals worth looking for: unusual multipart requests
• 7:05
  followed by memory limit errors, repeated HTTP 500 responses,
• 7:10
  strangely large or malformed PHPSESSID cookies, and unexplained worker churn.
• 7:16
  Because this happens below the application, normal app logs may show very little.
• 7:21
  So you're hunting in server level logs.
• 7:23
  Now the hard part for hosts is older PHP.
• 7:27
  PHP 8.1, 8.0 and 7.4 get no standard official release.
• 7:33
  You can use a distribution or long term support vendor package,
• 7:38
  or PHP's minimal source backports.
• 7:41
  And PHP 7.3 and older, including PHP 5, have no fix at all.
• 7:48
  watchTowr confirmed those older branches are affected too.
• 7:52
  So let's give people the dos and don'ts.
• 7:55
  Do confirm with your host that server level updates are applied.
• 7:58
  Don't just assume.
• 8:01
  Do log into your hosting panel and check what PHP version your site runs.
• 8:06
  If you're on 7.x, or 8.0 or 8.1, you're in the danger zone,
• 8:11
  and you need to schedule a move to 8.2 or newer.
• 8:14
  Do keep updating WordPress, themes and plugins.
• 8:17
  That doesn't fix PHP2Shell, but neglected plugins are their own door into your site.
• 8:23
  Now the don'ts.
• 8:25
  Don't count on a security plugin to save you.
• 8:28
  Those plugins run inside WordPress, and this bug fires in the engine during request
• 8:33
  startup.
• 8:34
  For PHP's most exposed setup, Apache mod PHP, PHP says an attack can succeed
• 8:41
  before any of the application's own code has run.
• 8:44
  Security plugins are still useful for other threats, just not this one.
• 8:48
  And don't go hunting for a snippet.
• 8:50
  There's no functions.php hook, no htaccess line, no php.ini tweak that patches a
• 8:57
  memory allocation failure inside the C engine.
• 8:59
  If someone online sells you one, be skeptical.
• 9:02
  Then there's the gray area, which is honestly the hardest.
• 9:05
  Plenty of business sites run on an abandoned plugin that breaks on PHP 8.2 or 8.3.
• 9:12
  The site owner says, don't touch it, it works.
• 9:15
  The host is then balancing two bad options: keep a backported patch in place for the
• 9:20
  old version, or push for an upgrade that might break something.
• 9:24
  My view is that's a budget conversation, not a technical one.
• 9:27
  Set aside developer time to modernize those dependencies now.
• 9:31
  Backports are a bridge, and bridges end.
• 9:34
  Once your PHP branch is past support with no patches, you're exposed the next time
• 9:38
  something like this lands.
• 9:40
  And with attackers moving faster, that next time may come sooner.
• 9:44
  So the short version: if you're with a host that's handling the server,
• 9:47
  check in, check your PHP version, and plan the upgrade you've been putting off.
• 9:52
  And if you're self managed, treat it as an emergency.
• 9:55
  Inventory every PHP install, update to the fixed release for your branch,
• 10:00
  restart the workers, and take anything you can't patch off the open internet.
• 10:04
  And if any of this feels like too much to handle alone, that's exactly what we do at
• 10:09
  Modularity Networks.
• 10:10
  Whether you need your PHP version checked, your hosting secured,
• 10:14
  or an old site modernized, you can get help with all of it at Modularity.us.