What PHP2Shell is
PHP2Shell is the name for two vulnerabilities: CVE-2026-109618 (opens in a new tab) and CVE-2026-109619 (opens in a new tab). Both are rated 9.2 out of 10 on CVSS v4. Both allow unauthenticated remote code execution. An attacker who can send an HTTP request to your server can run their own code on it. No login. No bug in your own application needed. Both bugs live in how PHP cleans up after a request fails, for example when it runs out of memory. PHP can leave internal state pointing at memory that was already freed. The next request handled by the same worker trusts that stale state. From there, an attacker can read memory from other requests or write to it. Wiz, one of the research teams, showed that reading memory alone can leak passwords, session tokens and API keys, the same way Heartbleed did in 2014. The scary part is how general it is. Wiz demonstrated remote code execution against fresh installs of WordPress, Drupal and Joomla, but wrote that even a plain "Hello World" page on a vulnerable PHP version can be attacked. Every PHP version back to 5.4 from 2012 is affected by at least one of the two bugs. PHP shipped fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end of life. The PHP team published minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions backported fixes, but anything older has no fix at all.Why it was in the news
Three things turned a security advisory into front page news. First, the bugs were found with AI. Researchers at Wiz, Calif and OpenAI used frontier models (Wiz names Gemini 4 Argon and GPT-5.6 Sol) to find the flaws and build working exploits. The code had been there for over a decade. Wiz wrote that turning it into an exploit was "at the edge of what human researchers could practically achieve", and that AI made it possible in days instead of months. The same tools help attackers too, which is why everyone moved so fast. Second, the details leaked early. CVE numbers and mitigation advice appeared online two days before the planned release, so the release was pulled forward. Amazon saw the first exploit attempt in a honeypot on October 17, four days before the patch. Cloudflare's CEO reported thousands of attempts in the ten hours before the announcement, and millions by the next day. Third, the fix is not a one click update. Hosting providers, Linux distributions, Docker images and every self managed server had to update PHP and restart every worker. Many organizations decided it was safer to go offline than to stay up while they figured out what they were running. As of this writing, the PHP Foundation says it knows of no confirmed successful remote code execution. A third, lower risk variant (CVE-2026-115560) was disclosed on October 23. It only affects an unusual session setup and shares the mitigation already recommended for CVE-2026-109619.Why game developers should care
Your game probably does not run on PHP. Your studio probably does.| What | Statistic | Source |
|---|---|---|
| Websites using PHP | 69.3% | W3Techs, October 2026 (opens in a new tab) |
| Websites running WordPress | 39.6% (all sites), 58.3% (sites with CMS) | W3Techs, October 2026 (opens in a new tab) |
| UK gaming companies with a CMS on WordPress | 60% | Firmbase, June 2026 (opens in a new tab) |
| Japanese game sites on WordPress | 36% | MUSOU LLC, 2024 (opens in a new tab) |
| Games announced around Summer Game Fest 2026 with their own site | 67% | James Binns, GamesIndustry.biz, June 2026 (opens in a new tab) |
| PC game company sites running PHP | 34% | Web Radar, PC Games (opens in a new tab) |
| Casual game company sites running PHP | 32% | Web Radar, Casual Games (opens in a new tab) |
| Video game company sites running PHP | 28% | Web Radar, Video Games (opens in a new tab) |
| Online game company sites running PHP | 25% | Web Radar, Online Games (opens in a new tab) |
- Leaderboards and login backends. Search "Unity leaderboard PHP MySQL" and you get years of tutorials, book chapters and GitHub repos. Many shipped games still run on a few PHP scripts next to a MySQL database.
- REST APIs in Laravel or Symfony for accounts, cloud saves and in-app purchases.
- Community forums. phpBB, XenForo and Invision Community are all PHP, and each published "update your PHP now" notices this week.
- Game wikis. MediaWiki, the software behind Wikipedia and most self hosted game wikis, is PHP.
- Merch stores on WooCommerce.
- Game server panels. Pterodactyl, used to manage Minecraft, Rust or FiveM servers, is a Laravel app. It shipped version 1.15.2 on October 21 just for PHP2Shell. The game servers are not PHP, but whoever controls the panel controls all of them.
What could actually happen
Your website serves malware. The classic result of a web shell is a modified download link or a fake "update your launcher" banner. Players trust your domain. If it hands them a trojan, that breach is yours even if the game was never touched. Your secrets leak. The memory disclosure works without full code execution. Anything that passed through the PHP process can be read: database passwords, Steam Web API keys, payment tokens, admin cookies. If your leaderboard API and your WordPress site share a server, one leak exposes both. Your player database is gone. A PHP login or leaderboard backend holds emails and password hashes. That is personal data, so GDPR applies, including the 72 hour deadline to report a breach. Your game servers get hijacked. A compromised Pterodactyl panel means someone can stop, wipe or replace every server it manages, and read every API key stored in it. Your old game dies. This already happened. Two Japanese mobile games, World Quest (launched 2011 on GREE) and Save My Demonic World, shut down for good this week because their old backends could not be patched or migrated. A game of yours still running on a PHP backend from a 2018 game jam is in the same spot.What to do this week
- List everything you run that uses PHP. Studio site, press kit, forum, wiki, store, leaderboard API, server panel, that staging subdomain from two years ago. Forgotten systems are the ones that get you.
- Check the PHP version the web server actually uses.
php -vin a terminal can differ from what PHP-FPM or Apache runs. Use your hosting panel or a temporaryphpinfo()page, then delete it. - On managed hosting, ask your provider to confirm both CVEs are fixed on the PHP serving your domain and that workers were restarted.
- On your own server, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP-FPM, Apache or LiteSpeed. Restarting Nginx alone does not reload PHP.
- If you are on PHP 8.1 or older, upgrade. If you cannot, take the site offline until you can. That is the official advice from CISA, the UK NCSC and the NSA.
- Set
session.upload_progress.enabled=0inphp.inior your FPM pool config. It is not a complete fix, but it closes the known path and covers the third CVE. - Rotate secrets a PHP process could have seen: database passwords, API keys, store tokens. If you cannot rule out that you were hit before patching, assume they leaked.
- Check your logs for the signals Wiz described: multipart requests followed by memory limit errors, repeated HTTP 500s, oddly large
PHPSESSIDcookies, or PHP workers restarting for no reason.
