BSSA-2026-06

Date	2026-09-28
Severity	reported "critical", BlueSpice assessment: critical
Affected	bluespice/wiki Docker image (all versions)
Fixed in	Unknown
CVE	CVE-2026-100382

Problem

CVE	Component	Type of vulnerability	BlueSpice 5
CVE-2026-100382	bluespice/wiki	Remote Code Execution	affected

Impact assessment

CVE	Assessment	Mitigation without update
CVE-2026-100382	Attackers with "read" permission can execute arbitrary commands in context of the wiki-web container	Deactivate Extension:ExternalData

Solution

Timeline and exposure window

• 2026-09-25: CVE published. A fix exists upstream in ExternalData 3.7.
• From 2026-09-26: mass automated scanning and exploitation, observed by us and other MediaWiki operators.
• Assume the exposure window runs from 2026-09-25 until the moment you applied the mitigation below.

2. Secure the evidence first

Important: docker compose down removes the containers and their logs The nginx access log of wiki-web is written to stdout, so it only exists in the Docker log of the container. Save the evidence before you restart anything

3. Detect an attack in the logs

Exploitation uses the parser function #get_program_data. It appears in the query string of requests to api.php or index.php.

Limits of this check. Please read.

• Only GET requests show the payload in the access log. The same attack also works via POST, and POST bodies are not logged. Also look for:
  • requests to api.php with meta=siteinfo and siprop=extensions (probing for ExternalData), followed by
  • bursts of POST /w/api.php from the same IP within a few seconds.

• Attackers may URL-encode letters of the parser function name. If in doubt, run the decoded search on the whole log.
• A missing hit does not prove that no attack happened, for example if the logs were already rotated.

Mitigation: disable Extension:ExternalData

The extension is loaded by this line:

wfLoadExtension( 'ExternalData' );

Where it is:

• BlueSpice 4: /app/bluespice/w/settings.d/050-BlueSpiceSemanticData.php
• BlueSpice 5: /app/bluespice/w/settings.d/040-BlueSpiceProDistribution.php

The exact line number depends on the version.

Do not simply edit the file inside the running container. The change would be lost the next time the container is recreated. We recommend the following options, best first:

Mount a patched copy of the settings file

Copy the settings file out of the container, comment out the line and mount it read-only:

# BlueSpice 5 – use 050-BlueSpiceSemanticData.php for BlueSpice 4
docker cp bluespice-wiki-web:/app/bluespice/w/settings.d/040-BlueSpiceProDistribution.php ./
sed -i "s|^wfLoadExtension( 'ExternalData' );|#wfLoadExtension( 'ExternalData' ); #Disabled due to https://www.strix.ai/cve/CVE-2026-100382|" 040-BlueSpiceProDistribution.php

services:
  wiki-web:
    volumes:
      - ./040-BlueSpiceProDistribution.php:/app/bluespice/w/settings.d/040-BlueSpiceProDistribution.php:ro
  # same for wiki-task and wiki-installer

Drawback: the copied file is tied to the exact image version. After an update it would overwrite the new version's file. Remove this mount before or together with the next update. For this reason option B is preferred.

Effects of disabling

Pages that use #get_web_data, #get_db_data, #external_value or similar functions of ExternalData will show the parser function as plain text or no data until the extension is enabled again in a fixed version. No content is lost.

Recreate the container stack

A plain restart is not sufficient. It keeps the existing, possibly manipulated container file system. The containers must be removed and created again from the image:

cd /path/to/bluespice-deploy/compose
./bluespice-deploy down
./bluespice-deploy up -d

Never use down -v or down --volumes. Also do not delete ${DATADIR}. That would delete the persistent wiki data.

Recreating the containers removes everything an attacker changed inside the containers. It does not clean the persistent data in ${DATADIR} (database, uploads, configuration files on the volume). Check those as described in section 7. Verify that the extension is disabled:

docker exec bluespice-wiki-web grep -rn "ExternalData" /app/bluespice/w/settings.d/
# Must NOT list "External Data":
curl -s "https://<your-wiki>/w/api.php?action=query&meta=siteinfo&siprop=extensions&format=json" | grep -i 'external data' \
  || echo "OK: ExternalData not loaded"

If read requires a login, run the API check in a logged-in browser session.

Check for compromise in persistent data

DATADIR refers to the value in compose/.env.

Files

To check whether uploaded files were replaced, compare the file hashes with a backup from before 2026-09-25:

MediaWiki also stores a SHA-1 of every file version in the database (img_sha1, base-36). php maintenance/run.php checkImages in wiki-task reports files whose size does not match the database.

Database

Direct database changes bypass the wiki log. Changes made through the wiki (edits, uploads) show up in Special:RecentChanges and Special:Log. MySQL/MariaDB logs: the database logs are in ${DATADIR}/database/logs. Check whether binary logs (log_bin) or the general query log are enabled

If binary logs exist, save them to the evidence directory and analyse the exposure window. Binary logs only record writes. Reads (data theft) cannot be seen there.

If you found traces of compromise

1. Remove found web shells and restore manipulated files from a backup created before 2026-09-25. Put pre-/post-init-settings.php and .wikienv back to known-good content.
2. Rotate all secrets:
   • DB passwords (DB_PASS, DB_ROOT_PASS). Change them in the database and in compose/.env.
   • All files in ${DATADIR}/.secrets/, for example with openssl rand -hex 32 > … per file.
   • OAuth key pair (oauth_private.key/oauth_public.key), SAML SP certificate (simplesamlphp/certs)
   • SMTP, LDAP/AD bind account, search credentials, API keys of AI providers, Slack/Teams/Rocket.Chat tokens
   • Passwords of all administrators. Ask all users to change their passwords. Also have them re-enroll two-factor authentication, because the TOTP secrets may be exposed.
3. Invalidate all sessions: add this to post-init-settings.php:

   $GLOBALS['wgAuthenticationTokenVersion'] = "2";

   Then recreate the stack. This logs out everybody.

4. Remove any backdoor accounts, bot passwords and OAuth consumers you found. Revert manipulated interface pages.
5. Check the host and the network for unusual activity: outgoing connections of the Docker host, firewall logs and access to internal systems from the Docker network.