PHP2Shell and MediaWiki

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The MediaWiki project has not posted a PHP2Shell notice on its announcement list. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: MediaWiki is one of the applications researchers used to prove the attack works. Calif confirmed unauthenticated remote code execution against MediaWiki 1.46.2, the current stable release. The flaw is in PHP, not in MediaWiki, so no MediaWiki release fixes it. Your wiki is safe from PHP2Shell only when the PHP build serving it is patched and every PHP worker has been restarted.

This guide is for anyone who runs a MediaWiki site: a company knowledge base, a documentation wiki or a community project. For the background, read what PHP2Shell is and who it affects.

Is MediaWiki Vulnerable to PHP2Shell?

MediaWiki is exposed through PHP, not through its own code. PHP describes CVE-2026-109618 as a case where "out-of-memory handling can interrupt PHP while internal request data is only partially initialized," and CVE-2026-109619 as one where "request-owned internal state can survive after its backing memory has been freed." Both happen inside PHP's request handling, which runs under every wiki page view.

On its PHP2Shell page, Calif says: "We confirmed pre-auth RCE on the following PHP apps as well as arbitrary PHP scripts in some instances." MediaWiki 1.46.2 is on that list, alongside WordPress, Drupal, Joomla, Nextcloud and others. "Pre-auth RCE" means remote code execution before any login: an attacker on the internet can make the server run commands as the web server account.

Wiz, the other main research team, demonstrated attacks only against WordPress, Drupal and Joomla. The Dutch national cyber security centre's software inventory lists MediaWiki as Vulnerable, noting that "PHP upstream confirms this runtime scope and Calif confirmed representative application-level pre-auth RCE. The remediation is the PHP runtime upgrade."

A confirmed attack on 1.46.2 doesn't mean older branches are safer. They run on the same, or older, PHP.

Has MediaWiki Published a Statement?

As of 23 October 2026, the mediawiki-announce mailing list, where the project posts security releases, has no PHP2Shell item. That is consistent with the flaw being outside MediaWiki: there is no MediaWiki patch to announce.

Don't read anything into how Wikipedia runs. MediaWiki's compatibility page says "Wikimedia production servers currently run PHP 8.3," but that describes the Wikimedia Foundation's own servers. It says nothing about your wiki's PHP. The authority on the fix is the PHP project's advisory, together with your Linux distribution or host.

MediaWiki PHP Requirements by Branch

This table combines MediaWiki's version lifecycle page with each branch's minimum PHP, as of 23 October 2026.

MediaWiki's lifecycle page is clear about older versions: "Versions in the above table marked as obsolete and versions not listed at all will not receive any security fix". A wiki on 1.44 or older carries its own unpatched MediaWiki issues on top of PHP2Shell.

The 1.43 LTS row is the one to watch. MediaWiki's 1.43 release notes say it "requires PHP 8.1.0 or later," and PHP 8.1 reached end of life on 31 December 2025. The PHP project published only a minimal source backport for 8.1, with no official release. Our guide to PHP 8.1 and PHP2Shell lists which distributions and vendors patched it.

Who Patches Your Wiki's PHP

Internal wikis are easy to forget. A documentation wiki stood up years ago on a spare server may have no owner today, and an attacker doesn't need a login to reach it if it is on the internet. Our guide to finding forgotten PHP servers covers how to inventory them.

How to Check the PHP Version on a MediaWiki Site

Open Special:Version on your wiki. The "Installed software" table lists MediaWiki, PHP and the database. On mediawiki.org itself, for example, it reads "PHP 8.3 (fpm-fcgi)". The part in brackets is the PHP server API. "fpm-fcgi" means PHP-FPM, and "apache2handler" is PHP's name for the Apache module (mod_php), which PHP's advisory calls the highest-risk setup.

Treat the version number with care. Linux distributions backport the fix without changing the upstream version, so a patched Ubuntu 24.04 server still reports PHP 8.3.6 and a patched 8.1 build still says 8.1.34. Check the package version against your distribution's advisory, or ask your host for the build date. Our guide on how to check your PHP version covers each method.

How to Patch a Self-Hosted MediaWiki Server

1. Find where PHP comes from: distribution packages, a control panel, a third-party repository or a container image. Use that source's fixed build, never an unofficial patch script.
2. Back up the database and uploaded files before changing packages. Our guide to website backup and recovery covers how.
3. Install the fixed packages. On Debian or Ubuntu with PHP-FPM, for example (replace 8.3 with your version):
   sudo apt update
   sudo apt upgrade
   sudo systemctl restart php8.3-fpm
   On RHEL-family systems, sudo dnf upgrade, then sudo systemctl restart php-fpm.
4. Restart the web server if it runs mod_php, for example sudo systemctl restart apache2 on Debian or Ubuntu. Restart any long-running PHP job runner too. Until PHP restarts, the old code keeps serving pages.
5. Reload Special:Version and compare the build with your vendor's fixed version.
6. Check for signs of compromise from at least 17 October 2026, the earliest reported exploitation attempt. Our guide on checking whether your site was hacked through PHP2Shell lists what to look for.

Interim Settings While You Wait

PHP's advisory lists settings that reduce exposure if you can't update today. It says "only an update is a complete solution" and that these measures "do not make an installation safe." The full list and its side effects are in PHP2Shell interim mitigations. For a wiki:

• session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. PHP says not to rely on ini_set() or FPM .user.ini. Keep it off after patching too, because a separate, unlikely issue (CVE-2026-115560) affects patched builds.
• A lower post_max_size: PHP suggests 8M if the site takes no uploads and 32M if it does. If your wiki accepts file uploads, test one afterward, and test saving a long page.
• On PHP 8.5 only, fatal_error_backtraces=0, then restart. The setting exists only on 8.5, which MediaWiki 1.46 supports.

A web application firewall can filter known attack requests, but rules are partial and don't replace patching.

Extensions and Upgrades

Extensions such as Semantic MediaWiki and the Parsoid parser are PHP code that runs inside the same PHP process. They can't protect against PHP2Shell, and patching PHP covers them. Keep them on the branch that matches your MediaWiki version, as the compatibility page advises. Our guide to plugin and package supply-chain security explains why every add-on still needs an owner.

If your wiki is on an end-of-life branch, plan the upgrade after PHP is patched, not during the emergency. MediaWiki "commits to supporting upgrades from up to two LTS releases ago." Its example: "to upgrade from 1.38 (or earlier) to 1.46, first upgrade your wiki to 1.39 (or 1.43), and then, you'll be able to upgrade to 1.46." 1.46 needs PHP 8.3 or newer, so a PHP upgrade usually comes first.

Conclusion

As of 23 October 2026, MediaWiki is one of the applications researchers used to prove PHP2Shell works, and the only fix is in PHP. Confirm that the build serving your wiki is patched and restarted, keep upload progress off, move 1.43 wikis off PHP 8.1, and retire anything on 1.44 or older. If you need a server patched quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions