CVE-2026-100382 · Improper Neutralization of Special Elements used in an OS Command (…

01 · The Real Story

A loaded trap door hidden inside a luxury add-on that most homeowners never ordered

CVE-2026-100382 is an OS command injection (CWE-78) in the MediaWiki ExternalData extension, specifically in its *local program execution* feature (#get_program_data and equivalent parser functions). The extension allows wiki pages to pull structured data from external URLs, databases, LDAP directories, and — crucially — local server-side executables. Parameters passed to configured commands are sanitized via regex-based param filters, but these filters are bypassable, letting an attacker inject shell metacharacters (;, |, ` `, $()) into the command string. All ExternalData versions prior to 3.7 (released 2026-09-23) are affected. The fix landed in Gerrit change 1326012, tracked as Phabricator T434961. Version 3.7 also introduced $wgExternalDataDisabledClasses`, strongly suggesting the fix involves the ability to disable the program-execution code path entirely.

The CNA-assigned CVSS 4.0 vector is a perfect 10.0 (AV:N/AC:L/AT:N/PR:N/UI:N), modeling the worst case: unauthenticated, no-complexity, full-impact RCE. That score is *technically accurate for wikis that allow anonymous editing and have program execution configured*, but it dramatically overstates the risk for the typical enterprise deployment. ExternalData is an optional extension — not part of core MediaWiki. Of those who install it, the vast majority use it for URL/CSV/database data retrieval, not local program execution, which requires explicit admin configuration in LocalSettings.php. The effective attack surface is the intersection of three conditions: extension installed, program execution configured, and attacker-reachable editing or parameter injection surface. That intersection is narrow. A CVSS 10.0 label will cause alert fatigue and mis-prioritization against truly fleet-wide risks.

"Unauthenticated RCE in a niche MediaWiki extension. Devastating if you have it; most orgs don't."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Fingerprint the target wiki

The attacker identifies a MediaWiki instance (via generator meta tag or /api.php?action=siteinfo) and enumerates installed extensions by requesting Special:Version or parsing api.php?action=query&meta=siteinfo&siprop=extensions. If ExternalData appears in the response, the target is potentially in scope. Many wikis expose Special:Version to anonymous users by default.

Conditions required:

Target runs MediaWiki with a network-reachable HTTP endpoint

Where this breaks in practice:

Enterprise wikis are often behind VPN or SSO — not internet-facing
Special:Version can be restricted via $wgGroupPermissions; some hardened installs block it

Detection/coverage: Web application scanners (Nuclei, Nikto) can fingerprint MediaWiki version and extension list via Special:Version or API responses.

STEP 02

Confirm local program execution is configured

The attacker probes for pages that call #get_program_data or the newer #get_external_data with a program:// source type. They may search the wiki's content (if search is enabled for anons) for these parser function invocations, or attempt to create a test page using a known program-execution call. A 'class disabled' or 'no such source' error confirms the feature is absent; a parameter validation error confirms it is present.

Conditions required:

ExternalData extension is installed
Local program execution is configured in $wgExternalDataSources with a command key

Where this breaks in practice:

Most ExternalData deployments use URL/DB/file sources, not program execution — this is an explicit opt-in by the admin
If $wgExternalDataDisabledClasses (new in 3.7) is backported or the program class is never configured, this step fails entirely

STEP 03

Craft a filter-bypass injection payload

The regex-based param filters in ExternalData are the primary input sanitization layer. The attacker crafts a payload that passes the configured regex but still contains shell metacharacters. For example, if the filter is /^[\w-]+$/, the attacker looks for Unicode normalization tricks, newline injection, or mismatched encoding that lets a semicolon or backtick slip through the PHP preg_match boundary. The specific bypass depends on the filter regex configured by the admin — weaker regexes (e.g., /^.+$/) are trivially bypassable.

Conditions required:

Parameter filter regex is bypassable or not configured for all parameters
Attacker understands the configured command template and parameter names

Where this breaks in practice:

Strict, well-written regexes (e.g., /^[a-z0-9-]+$/) significantly raise the bar
The attacker cannot see the regex or command template directly — they must infer it from error messages or wiki page source

Detection/coverage: WAF rules detecting shell metacharacters in wiki edit payloads can catch basic injection attempts.

STEP 04

Trigger command execution via page edit or transclusion

The attacker submits a wiki page edit (or, on wikis with anonymous editing, creates a new page) containing the malicious ExternalData parser function call with the crafted parameter. When MediaWiki renders the page, the ExternalData extension passes the parameter to the configured command via PHP's exec(), shell_exec(), or proc_open(). The injected payload executes as the web server user (typically www-data or apache). On wikis without anonymous editing, the attacker needs a valid account — even a low-privilege registered user suffices.

Conditions required:

Attacker can edit or create a wiki page (anonymous editing OR a low-privilege account)
The wiki renders the page (not deferred/queued)

Where this breaks in practice:

Enterprise wikis almost universally require authentication to edit; many use SSO/LDAP integration
Edit rate-limiting, CAPTCHA, and abuse filters may slow or block automated exploitation
ContentStabilization / FlaggedRevs extensions can require editorial approval before rendering new edits

Detection/coverage: MediaWiki RecentChanges feed, edit logs, and abuse filters can flag pages containing ExternalData parser functions with suspicious parameters. PHP proc_open/exec calls from the web server process are detectable by EDR and auditd.

STEP 05

Achieve RCE as web server user

The injected command runs with the privileges of the PHP/web server process. The attacker establishes a reverse shell or drops a webshell. From this foothold, they can read LocalSettings.php (containing database credentials, secret keys, LDAP bind passwords), access the wiki database, pivot to adjacent systems on the same network segment, or escalate privileges if the host is misconfigured. The blast radius is typically host-level unless the wiki server has stored credentials for higher-value systems.

Conditions required:

Steps 1–4 succeeded
Outbound network connectivity for reverse shell, or writable web directory for webshell

Where this breaks in practice:

Containers, SELinux, AppArmor, and read-only filesystems limit post-exploitation options
Network segmentation prevents lateral movement from DMZ wiki servers
Outbound firewall rules may block reverse shell callbacks

Detection/coverage: EDR detects shell spawned by PHP process. Network monitoring flags unexpected outbound connections from the web server. File integrity monitoring catches webshell drops.

03 · Compensating Control

HIGH 8.1→IGNORE 0.0

SEVERITY REDUCED

Disable program execution in ExternalData immediately — Add $wgExternalDataDisabledClasses = ['EDConnectorExe']; to LocalSettings.php (available in 3.7, or manually remove any 'command' entries from $wgExternalDataSources on older versions). This eliminates the vulnerable code path entirely without removing the extension's other data-retrieval features. Deploy within the noisgate mitigation SLA of 30 days for HIGH-severity findings — but given the trivial effort, same-day is realistic.

HIGH 8.1→MEDIUM 6.5

SEVERITY REDUCED

Restrict wiki editing to authenticated users — Ensure $wgGroupPermissions['*']['edit'] = false; in LocalSettings.php so anonymous users cannot create or edit pages. This eliminates the unauthenticated attack vector (PR:N → PR:L). Combine with strong authentication (SSO/MFA). Does NOT fully mitigate — any authenticated wiki user can still exploit. Deploy within 30 days per noisgate mitigation SLA.

HIGH 8.1→IGNORE 0.0

SEVERITY REDUCED

Upgrade ExternalData to version 3.7 — The definitive fix. Version 3.7 patches the parameter filter bypass and introduces $wgExternalDataDisabledClasses for defense-in-depth. This is the noisgate remediation SLA action — deploy within 180 days for HIGH-severity. Given the low complexity of the upgrade (single extension update via Composer or Git), prioritize within the first patch cycle.

HIGH 8.1→HIGH 7.2

Deploy WAF rules blocking shell metacharacters in wiki edit payloads — Configure your WAF (ModSecurity, Cloudflare, AWS WAF) to inspect POST bodies to api.php and index.php?action=edit for shell metacharacters (;, |, ` `, $(, &&`) in parameters matching ExternalData parser function patterns. This is a detection/partial-block layer — sophisticated encoding bypasses are possible. Deploy within 30 days.

HIGH 8.1→MEDIUM 5.5

SEVERITY REDUCED

Run MediaWiki in a restricted container with no outbound network and read-only filesystem — Use a hardened container image with AppArmor/SELinux profiles, drop all Linux capabilities except those required for PHP-FPM, mount the webroot read-only, and block outbound connections via network policy. This does not prevent command execution but severely limits post-exploitation (no reverse shell, no webshell persistence, no lateral movement). Deploy within 30 days.

What doesn't work

Updating core MediaWiki alone does not help. The vulnerability is in the ExternalData extension, not MediaWiki core. Upgrading MediaWiki to the latest version without updating ExternalData leaves you vulnerable.
IP-based rate limiting on edits. The attack requires a single page edit — rate limiting will not prevent a one-shot exploit.
Content Security Policy (CSP) headers. CSP governs browser-side script execution. OS command injection runs server-side in PHP — CSP is irrelevant to this attack path.
PHP disable_functions for exec/shell_exec. While this would block the vulnerable code path, it would also break ExternalData's program execution feature entirely AND may break other MediaWiki functionality (image thumbnailing via ImageMagick, etc.). This is equivalent to disabling the feature, not a surgical mitigation.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No known exploitation. Not listed on CISA KEV. No campaigns, ransomware affiliates, or APT groups have been observed targeting this CVE as of 2026-09-26. The CVE was disclosed only 1 day ago.
Proof-of-Concept	No public PoC as of 2026-09-26. No exploit code on GitHub, Exploit-DB, or PacketStorm. The bypass technique for `param filters` regex sanitization has not been publicly documented. Weaponization difficulty is moderate — requires knowledge of the target's configured command template and parameter filter regexes.
EPSS Score	Not yet scored. The CVE was published 2026-09-25; FIRST typically requires 30+ days of signal before producing a reliable EPSS estimate. Given the niche attack surface (optional extension, opt-in feature), expect a low-to-moderate EPSS once scored.
KEV Status	Not listed. No CISA KEV entry as of 2026-09-26. No BOD 22-01 remediation deadline applies.
CVSS Vector	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H = 10.0 (CNA-assigned). Network-accessible, no authentication, no complexity, full CIA impact on vulnerable and subsequent systems. This models the worst-case scenario of an anonymous-edit-enabled wiki with program execution configured.
Affected Versions	MediaWiki ExternalData extension < 3.7 — all prior versions including 3.6.1, 3.6, 3.5.x, and earlier back to 3.0 (when `#get_program_data` was introduced in December 2021). Core MediaWiki is NOT affected — only installations with this optional extension.
Fixed Versions	ExternalData 3.7 (released 2026-09-23). Patch: Gerrit 1326012. New `$wgExternalDataDisabledClasses` config variable allows disabling the program execution class entirely. No distro backports identified — Debian/Ubuntu do not package this extension.
Scanning / Exposure	MediaWiki powers ~40,000+ public-facing sites (per Wappalyzer/BuiltWith estimates). ExternalData is bundled in BlueSpice, Canasta, MyWikis, ProWiki, and semantic::core distributions but is still a minority of total MediaWiki installs. Shodan/Censys queries for `X-Powered-By: MediaWiki` or `generator: MediaWiki` return broad results, but there is no way to remotely fingerprint whether ExternalData's program execution feature is configured.
Disclosure Date	2026-09-25 (NVD publication). Patch released 2026-09-23 (2 days prior). Tracked as Phabricator T434961.
Credited Researcher	SomeRandomDeveloper (credited as finder in the CVE record).

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (8.1/10)

Why this verdict

Extension is optional, not core MediaWiki. ExternalData is a third-party extension that must be explicitly installed. The majority of MediaWiki deployments — including most enterprise wikis — do not use it. This immediately narrows the reachable population to a subset of MediaWiki installs, perhaps 10–20%.
Program execution is an opt-in admin configuration. Even among ExternalData users, the command key in $wgExternalDataSources (local program execution) is a power-user feature explicitly configured in LocalSettings.php. Most deployments use the extension for URL, CSV, or database data retrieval. Conservatively, fewer than 10% of ExternalData installs have program execution enabled. The compounding effect: ~1–2% of all MediaWiki instances are plausibly vulnerable.
Enterprise wikis require authentication to edit. The CVSS PR:N rating assumes anonymous editing, which is common on public community wikis but rare in enterprise environments. Corporate MediaWiki instances almost universally require SSO/LDAP authentication to edit, effectively raising the prerequisite to PR:L (low-privilege authenticated user). This reduces the unauthenticated attack surface to public-facing community wikis.
No PoC, no exploitation, day-one disclosure. As of 2026-09-26, there is no public exploit code, no documented bypass technique for the param filter regex, and no observed in-the-wild exploitation. The attacker must reverse-engineer the specific filter bypass, which varies per deployment. Time-to-weaponization is non-trivial.
Role multiplier: MediaWiki is NOT a high-value infrastructure component. MediaWiki is a web application / knowledge base. It does not occupy any role in the high-value catalog (not an IdP, domain controller, hypervisor, CI/CD system, backup platform, database engine, network edge appliance, EDR agent, or SIEM). Compromise yields host-level access as www-data/apache — the blast radius is the wiki server itself plus any credentials stored in LocalSettings.php (database password, LDAP bind credentials). In a well-segmented enterprise, lateral movement from a wiki server is limited. The blast radius is host-level, not domain/fleet/supply-chain. No floor elevation applies.
Where the chain DOES land, impact is severe. For the ~1–2% of MediaWiki instances where all prerequisites align (extension installed, program execution configured, attacker can edit), this is a genuine unauthenticated/low-auth RCE with full host compromise. The vulnerability class (OS command injection) is inherently high-severity. This prevents further downgrade below HIGH.

Why not higher?

A CRITICAL rating would require either (a) the affected component to canonically occupy a high-value infrastructure role (≥10% of installs are domain controllers, hypervisors, etc.) or (b) the vulnerability to be trivially exploitable across a broad installed base with fleet-scale blast radius. MediaWiki is a web application, not infrastructure. The ExternalData extension with program execution is a niche feature within a niche extension. The compounding prerequisites (extension installed + program execution configured + attacker editing access) reduce the reachable population to ~1–2% of MediaWiki installs. No active exploitation or public PoC exists. These factors collectively prevent a CRITICAL assessment.

Why not lower?

Despite the narrow attack surface, this is a textbook unauthenticated RCE (CWE-78) with no complexity barriers once the prerequisites are met. The vulnerability class — unsanitized input flowing to exec()/shell_exec() — is among the most dangerous in web applications. Any organization that *does* run ExternalData with program execution faces full server compromise. Additionally, the extension is bundled in several popular MediaWiki distributions (BlueSpice, Canasta), so the installed base is not negligible. A MEDIUM rating would understate the impact for affected deployments.

06 · Verification

Crowdsourced verification payload.

Run this script on the MediaWiki host as any user with read access to the MediaWiki installation directory (no root required). Invoke with: bash check_cve_2026_100382.sh /var/www/mediawiki (adjust the path to your MediaWiki root). The script checks whether the ExternalData extension is installed, its version, and whether local program execution is configured.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-100382 — MediaWiki ExternalData Extension OS Command Injection
# Outputs: VULNERABLE / PATCHED / UNKNOWN
set -uo pipefail

MW_DIR="${1:-/var/www/mediawiki}"
EXT_DIR="$MW_DIR/extensions/ExternalData"

if [ ! -d "$MW_DIR" ]; then
    echo "UNKNOWN — MediaWiki directory not found at $MW_DIR. Provide the correct path as argument."
    exit 2
fi

# 1. Check if ExternalData extension is installed
if [ ! -d "$EXT_DIR" ]; then
    echo "PATCHED — ExternalData extension is NOT installed. This instance is not affected by CVE-2026-100382."
    exit 0
fi

# 2. Read version from extension.json
EXT_JSON="$EXT_DIR/extension.json"
if [ ! -f "$EXT_JSON" ]; then
    echo "UNKNOWN — extension.json not found in $EXT_DIR. Cannot determine version."
    exit 2
fi

# Parse version (prefer python3, fall back to grep)
if command -v python3 &>/dev/null; then
    VERSION=$(python3 -c "import json,sys; print(json.load(open(sys.argv[1])).get('version',''))" "$EXT_JSON" 2>/dev/null)
else
    VERSION=$(grep -oP '"version"\s*:\s*"\K[^"]+' "$EXT_JSON" 2>/dev/null || true)
fi

if [ -z "$VERSION" ]; then
    echo "UNKNOWN — Could not parse version from $EXT_JSON."
    exit 2
fi

# 3. Compare version — need >= 3.7
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
MAJOR=${MAJOR:-0}; MINOR=${MINOR:-0}

if [ "$MAJOR" -gt 3 ] 2>/dev/null || { [ "$MAJOR" -eq 3 ] 2>/dev/null && [ "$MINOR" -ge 7 ] 2>/dev/null; }; then
    echo "PATCHED — ExternalData v$VERSION (>= 3.7). CVE-2026-100382 is fixed."
    exit 0
fi

# 4. Vulnerable version — check if program execution is configured
PROG_RISK=""
LOCAL_SETTINGS="$MW_DIR/LocalSettings.php"
if [ -f "$LOCAL_SETTINGS" ]; then
    if grep -qE "('command'|\"command\"|get_program_data|EDConnectorExe)" "$LOCAL_SETTINGS" 2>/dev/null; then
        PROG_RISK=" [!!] Program execution appears CONFIGURED — exploitation is directly possible."
    else
        PROG_RISK=" Program execution not detected in LocalSettings.php — risk is reduced but update is still required."
    fi
fi

echo "VULNERABLE — ExternalData v$VERSION (< 3.7). CVE-2026-100382 applies.$PROG_RISK"
exit 1

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously