Hunting web shells after CVE-2026-100382: detection guidance for MediaWiki's External Data RCE

A patch is only half the response

Security teams running MediaWiki have a straightforward fix for CVE-2026-100382: upgrade the External Data extension to version 3.7. The harder question, as a detection engineering write-up on dev.to frames it, is whether an attacker already used the flaw to plant a web shell before the upgrade landed. The post argues that the exploitation pattern seen after disclosure leaves traces specific enough to search for at scale.

The vulnerability in brief

According to the dev.to write-up, the External Data extension has been able to invoke local programs on the server since version 3.0, and input supplied through one of its parser functions reached that execution sink without filtering. The resulting CVE describes unauthenticated remote code execution, scored 10.0 under CVSS v4, affecting every release before 3.7. Exploitation is confirmed in the wild, a proof of concept is public in Wikimedia Phabricator task T434961, and administrators recorded automated attempts within a day of the 25 September disclosure. Because wikitext is untrusted content and the default extension configuration exposed the path, no authentication or privilege is needed to try the flaw — every request reaching a vulnerable wiki is a potential exploitation attempt, successful or not.

What the intrusion looked like

The write-up describes a recognisable sequence: an API query to check whether the extension is present, a burst of POST requests, and then fetches of PHP files the payload had just written. One observed shell was located in the skins directory of a compromised host — a finding credited in the post to Lajoie — which puts skin and upload directories in the first pass of any sweep.

Four checks to run

The post turns that sequence into four checks.

File system: enumerate PHP files created on or after 25 September in writable directories the web server serves, prioritising names matching Nx_.php or NX_.php, with skin and upload directories first.

Web logs: look for clusters that combine an extension-probing request, repeated POSTs to api.php from a single source address, and GET requests for files that only just appeared. Retrieving a freshly created file is the strongest signal, since ordinary traffic almost never requests a file moments after it comes into existence.

Content integrity: diff the extension and skin directories against a known-good deployment. Anything an attacker added sits outside what the platform's version control accounts for.

Execution configuration: confirm that PHP execution is switched off in upload directories at the web server level. A .htaccess rule on its own proves little, the post cautions, because it can be bypassed or ignored depending on how the server is configured.

The author notes that a small regular-expression filter over access logs is often enough to surface candidate lines, but recommends treating matches as leads — correlated by source address and time cluster — rather than confirmed intrusions.

Scoping the exposure

External Data is an optional extension, so exposure depends on what is installed, not on the MediaWiki core version. The write-up recommends building an inventory through Special:Version and the filesystem instead of assuming a particular platform build implies a specific extension set. As a rough size estimate, a ZoomEye query for http.body="ExternalData" returned 1128 assets at the time of writing — an indication of how many responses mention the string, not a list of vulnerable hosts.

Remediation goes past the upgrade

The remediation sequence laid out in the post runs: upgrade to 3.7 or disable the extension, then complete the hunt; rotate the database password, secret keys and administrator passwords on any host that ran an older release, and replace stored API keys; delete confirmed shells and rescan afterwards, since a partial cleanup reopens the same access path; and verify the deployed version on Special:Version as the final check.

Why it matters

A web shell sitting in a web-served directory survives the patch that closed the way in. From that position, LocalSettings.php exposes database credentials, secret keys and API keys, and the wiki's reachability makes it a convenient host for further activity. Detection that stops at confirming the patched version leaves that access in place, which is why the write-up treats hunting as the required second half of the response rather than an optional follow-up.