DEV Community

StarkMan
StarkMan

Posted on

Closing the execution sink: defensive patterns after CVE-2026-100382

#security #defensivedesign #mediawiki #vulnerability

Closing the execution sink: defensive patterns after CVE-2026-100382

Every remote code execution vulnerability is a failure of one specific boundary, and CVE-2026-100382 makes that boundary unusually easy to describe. Untrusted page content reached a server-side program invocation. The fix removes the specific route, but the pattern recurs often enough that the defensive lessons deserve to outlive this advisory.

Vulnerability overview

The External Data extension for MediaWiki allowed unauthenticated remote code execution in all releases before 3.7. Tracked as CVE-2026-100382 with a CVSS v4 score of 10.0, it is confirmed as exploited, has public exploitation details in Wikimedia Phabricator task T434961, and drew automated attacks within a day of the 25 September disclosure. One administrator documented 13 attack rounds on a production wiki.

Mechanism and exploitation conditions

The extension acquired the ability to run local programs on the server in version 3.0. The parser function that accepted the command passed it along without filtering. The CVE record notes that the flaw works without requiring authentication or any privileges. The attack surface therefore includes any visitor who can reach the wiki, and the observed intrusion ended with a web shell in the skins directory after API probing and POST delivery.

The boundary that failed

Three properties made the flaw severe: the input is attacker-controlled, the sink is a privileged process, and the gate in front of the sink was absent. Removing any one of those properties would have reduced the impact substantially. That framing produces reusable controls.

  • Treat any execution capability exposed to content as requiring an explicit allowlist, not a denylist of known-bad strings.
  • Require a privilege boundary in front of execution features, even when the feature is meant for trusted editors, because page content is not a trusted channel.
  • Disable execution in directories that accept uploads or user-influenced writes, at the web server layer.
  • Monitor for the retrieval step. A file being fetched moments after it appears is a strong signal regardless of which vulnerability created it.

Impact

Command execution as the web server user exposes LocalSettings.php with its database password, secret keys and API keys, and permits writing into web-served directories. The result is a persistent foothold that survives a content review, which is why cleanup matters as much as patching.

Affected products and scope

All External Data releases before 3.7, on any MediaWiki version that supports it. The incident environment used Canasta 3.5.7 with MediaWiki 1.43.8. Wikis without the extension are not affected by this vulnerability.

Exposure context

ZoomEye matched 1128 assets for http.body="ExternalData". The figure counts assets that mention the extension in a response and is useful for estimating the population to verify, not for confirming a vulnerable version on a specific host.

Remediation and mitigations

Upgrade to 3.7 or disable the extension, then apply the broader controls above. Hunt for newly created PHP files in writable directories, focusing on Nx_.php and NX_.php names, and review access logs from 25 September onward for extension probes followed by POST bursts to api.php. Block PHP execution in upload directories at the web server level. Rotate the database password, secret keys and administrator passwords, and replace stored API keys. Verify the deployed version on Special:Version.

References

Top comments (0)