In short: MediaWiki security after PHP2Shell begins with the server's PHP, because the flaw sits there and not in the wiki. Internal wikis are often left untouched for years and run on old PHP versions. Check the status on Special:Version, patch and restart, and then check LocalSettings.php, images and the interface administrators.
Why internal wikis are a worthwhile target
In many companies, authorities and research institutions, MediaWiki serves as an internal handbook. It holds procedures, contact persons, network diagrams, server instructions and sometimes even credentials that do not belong there. For an attacker, such a wiki is a map of the company.
According to the PHP team, the PHP flaws CVE-2026-109618 and CVE-2026-109619 allow remote code execution without authentication. A wiki that was meant to be "internal only" but is reachable via the internet is thus directly vulnerable. And because wikis are rarely the focus of IT, they often run on old servers, frequently still with PHP as an Apache module, the operating mode with the highest risk according to the PHP team.
MediaWiki security: checking the PHP version and patch level
The page Special:Version shows the version of MediaWiki, PHP and the database as well as all installed extensions and skins. Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Many wiki servers run on Linux distributions with backports; the displayed number then stays the same although the system is patched.
If the wiki runs on PHP 8.1 or older, the PHP project no longer provides official updates, only minimal source backports for 7.4, 8.0 and 8.1. What applies then is summarised in PHP 8.1 and older. Which PHP versions your MediaWiki version supports can be found in the system requirements on mediawiki.org. A PHP switch may require a MediaWiki upgrade.
Maintenance scripts and job runners run via the command-line PHP. This version must be patched as well. If the job queue runs as a permanent service, it must restart after the update just like the web server or PHP-FPM. With mod_php this means a restart of Apache itself, because PHP sits inside the web server process there.
Also clarify who owns the wiki. Internal wikis were often set up by a specialist department and run outside normal server maintenance. Without clear responsibility, the PHP update stays pending there the longest.
Directories and files in MediaWiki
| Location | Content | What to check |
|---|---|---|
LocalSettings.php |
Database credentials, $wgSecretKey, $wgUpgradeKey, permissions, upload settings |
Inserted code, renew keys if you suspect an incident |
images/ |
Uploaded files and thumbnails | No PHP files, no PHP execution |
extensions/, skins/ |
Extensions and designs | Unknown or modified files |
cache/ |
Cache | Empty after a cleanup |
maintenance/ |
Maintenance scripts for the command line | Do not use via the web |
The upload directory should not execute scripts at web server level. Under Apache, this works independently of the PHP operating mode as follows:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
A harmless first check:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Check the pages MediaWiki:Common.js and MediaWiki:Common.css in the revision history. Changes there take effect for every visitor of the wiki and are a typical place for injected code.
Permissions, groups and extensions
In MediaWiki, user groups decide on security. Under Special:ListUsers and Special:UserRights, check who belongs to the groups administrators, bureaucrats and interface administrators. Interface administrators can change the JavaScript of the entire wiki; this group should be very small.
For an internal wiki, reading without logging in should be switched off and the registration of new accounts blocked. Allow uploads only for the file types that are really needed. Extensions bring their own PHP code; unmaintained extensions also hold up every upgrade. For file permissions on the server, the guide File permissions on the web server provides orientation.
What a MediaWiki update can and cannot do
A MediaWiki update replaces the core and closes known flaws in it. It does not patch PHP, does not restart PHP processes, changes nothing in LocalSettings.php and removes neither files in images/ nor changes to MediaWiki:Common.js or additional group members. Nor does it prove that nobody was reading along before the patch.
The logs under Special:Log also give a quick overview. New user accounts, changes to group rights and edits to interface pages since 17 October 2026 are recorded there with the time.
How does PHP SOS help?
- We check the PHP version, operating mode and backport status of your wiki server and have the restart confirmed.
- We secure logs from 20 October 2026 onward, the database and the files.
- We check
LocalSettings.php, uploads, extensions, group rights and the revision history of the interface pages. - As part of the PHP2Shell emergency help, we assess with you whether the wiki has to remain publicly reachable.
Frequently asked questions
Is MediaWiki affected by PHP2Shell?
MediaWiki itself has no new flaw but runs on PHP. If the server's PHP is not patched, an attacker can, according to the PHP team, execute code without authentication. A MediaWiki update does not close the flaw.
Where do I see my wiki's PHP version?
On the page Special:Version, MediaWiki lists the installed software, including the PHP version. The number does not tell you whether a backport has been applied; the server operator confirms that.
Why is MediaWiki:Common.js a risk?
The content of this page is delivered as JavaScript to all visitors of the wiki. Anyone who can change it can execute code in every user's browser. The group of interface administrators should therefore be very small.
Is it enough to make the wiki reachable only internally?
A wiki reachable only in the company network or via VPN reduces the risk considerably, because attackers from the internet cannot reach it directly. You still have to patch, since an attack can also come from the internal network.