DEV Community

jeffrey
jeffrey

Posted on

Detection engineering for CVE-2026-100382: hunting the External Data web shell

#security #vulnerability #detectionengineering #webshell

Detection engineering for CVE-2026-100382: hunting the External Data web shell

Patching CVE-2026-100382 is the easy half of the response. The hard half is answering a different question: did anything get in before the upgrade? The exploitation pattern observed after disclosure leaves enough traces for a focused hunt, and the artefacts are specific enough to search for at scale.

Vulnerability overview

The External Data extension for MediaWiki could run local programs on the server from version 3.0 onward, and the commands supplied through one of its parser functions were not filtered. CVE-2026-100382 documents the result: unauthenticated remote code execution, CVSS v4 10.0, affecting all releases before 3.7. Exploitation is confirmed in the wild, the proof of concept is public in Wikimedia Phabricator task T434961, and administrators logged automated attempts within a day of the 25 September disclosure.

Mechanism and exploitation conditions

The weakness is preserved input reaching an execution sink. Wikitext is untrusted content, the parser function forwarded it into a server-side program invocation, and the default extension setup provided the reachable path. The CVE record notes that no authentication or privilege is required, so opportunistic bots need no credentials to try it. Every request that reaches a wiki running a vulnerable version is a potential exploitation attempt, whether or not it succeeds.

What to hunt for

The reported intrusion followed a recognisable order: an API query to detect the extension, a burst of POST requests, then fetches of PHP files that the payload had just created. Turn that into four checks.

  1. File system: enumerate PHP files created since 25 September in writable, web-served directories, with priority on names matching Nx_.php or NX_.php. Lajoie found the shell in the skins directory, so skin and upload directories belong in the first pass.
  2. Web logs: look for a cluster that contains an extension-detection request, then multiple POSTs to api.php from the same source, then GET requests for newly created PHP files. The retrieval step is the most distinctive because legitimate traffic rarely fetches a file moments after it appears.
  3. Content integrity: diff the extension and skin directories against a known-good deployment. Anything added by an attacker sits outside the version control of the platform.
  4. Execution configuration: confirm that PHP execution is disabled in upload directories at the web server level. A .htaccess rule is not sufficient evidence, because it can be bypassed or ignored depending on configuration.

A simple log filter using the standard library is often enough to surface candidates:

import re

pattern = re.compile(r'api\.php')
with open('access.log', encoding='utf-8', errors='replace') as handle:
    for line in handle:
        if pattern.search(line) and ('POST' in line or '.php' in line):
            print(line.rstrip())
Enter fullscreen mode Exit fullscreen mode

Treat the output as leads, not verdicts. Correlate source addresses and time clusters before drawing conclusions.

Impact

A web shell in a web-served directory gives an attacker a durable foothold that patching alone does not remove. From there, LocalSettings.php supplies database credentials, secret keys and API keys, and the wiki's reachability makes it a convenient host for further activity. Detection that stops at version confirmation leaves that foothold in place.

Affected products and scope

Every External Data release before 3.7 is affected. The extension is optional, so scope is determined by what is installed, not by the MediaWiki version alone. Inventory via Special:Version and the filesystem is faster and more reliable than assuming a platform build implies a specific extension set.

Exposure context

Sanity-check the size of the population before starting. A ZoomEye search for http.body="ExternalData" returned 1128 assets at the time of writing. That number describes assets whose responses mention the extension string; it is a scoping hint, not a vulnerability confirmation.

Remediation and mitigations

Upgrade to 3.7 or disable the extension, then complete the hunt described above. Rotate the database password, secret keys and administrator passwords on any host that ran an older version, and replace stored API keys. Remove confirmed shells and re-scan afterwards, because a partial cleanup leaves the same access path open. Verify the deployed version on Special:Version as the final check.

References

Top comments (0)