Security:Security Advisories/BSSA-2026-08

Date	2026-10-23
Severity	reported "critical" (CVSS 4.0: 9.2), BlueSpice assessment: critical (container bluespice/wiki), low (container bluespice/collabpads)
Affected	Container bluespice/wiki in BlueSpice 5.1 up to 5.1.11 and BlueSpice 5.2 up to 5.2.7 (all editions) Container bluespice/collabpads in BlueSpice 5.1 up to 5.1.11 and BlueSpice 5.2 up to 5.2.7 (not exploitable in default configuration) BlueSpice installations without containers that use an unpatched PHP version
Fixed in	BlueSpice 5.1.11.1 and BlueSpice 5.2.7.1 (containers bluespice/wiki and bluespice/collabpads, published on 2026-10-22)
CVE	CVE-2026-109618 CVE-2026-109619

Problem

Two vulnerabilities in the PHP interpreter (publicly known as "PHP2Shell") allow unauthenticated remote code execution on web servers that run PHP. They were disclosed by the PHP project on 2026-10-21. Exploitation in the wild has been reported. BlueSpice is affected because it runs on PHP.

CVE	Component	Type of vulnerability	BlueSpice 5
CVE-2026-109618	PHP (containers bluespice/wiki and bluespice/collabpads)	Remote code execution through memory corruption when PHP runs out of memory while processing a request	affected
CVE-2026-109619	PHP (containers bluespice/wiki and bluespice/collabpads)	Remote code execution through use of freed memory in a later request (use after free)	affected

Impact assessment

Component	Assessment	Mitigation without update
Container bluespice/wiki	Critical. The wiki container processes all user requests with PHP-FPM. The vulnerabilities can be exploited before any BlueSpice code runs, so no login is needed, and private wikis are affected as well. A successful attacker can run commands inside the wiki container. This gives access to all wiki content and uploaded files, to the secrets of the container (e.g. database credentials) and to the internal services (database, search, cache).	No configuration change fully mitigates the vulnerabilities. Take the wiki offline or restrict access to trusted networks (e.g. VPN only) until the update is installed.
Container bluespice/collabpads	Low. The collabpads service is a WebSocket server that runs as a single PHP command line process. It does not use the PHP request processing that the vulnerabilities affect. Not exploitable through the known attack paths. The container was updated as a precaution.	None required. Update with the next maintenance.

Solution

Update to BlueSpice 5.1.11.1 or BlueSpice 5.2.7.1. These releases contain only updated containers bluespice/wiki (PHP 8.4.27) and bluespice/collabpads (PHP 8.3.36). The wiki container also disables the PHP setting session.upload_progress.enabled, which BlueSpice does not use.

The other services (e.g. search, pdf, formula) were not re-released and keep their version numbers. The image tags 5, 5.2 and 5.1 of bluespice/wiki and bluespice/collabpads point to the fixed images. Therefore, in the .env file of bluespice-deploy, set VERSION to 5.2 or 5.1. Do not set it to 5.2.7.1 or 5.1.11.1, as the other services are not available with these tags. Then pull the images and re-create the containers. Run these commands in the compose directory of bluespice-deploy: ./bluespice-deploy pull && ./bluespice-deploy up -d. Use the bluespice-deploy script instead of plain docker compose, because only the script loads all required docker-compose.*.yml files.

To check whether your installation is fixed, run:

• ./bluespice-deploy exec wiki-web php -v: must show PHP 8.4.27 or higher
• ./bluespice-deploy exec collabpads php -v (BlueSpice pro and farm only): must show PHP 8.3.36 or higher

Tarballs of BlueSpice 5.1.11.1 and 5.2.7.1 are available on bluespice.com.

BlueSpice cloud was taken offline as a precaution before the vulnerabilities were announced. We found no evidence of attacks. The cloud instances are already back online with a patched PHP version. No action is required from cloud customers.

BlueSpice 4 is no longer supported. As some people still use it, we published updated images bluespice/wiki:4.5.8.1 and bluespice/collabpads:4.5.8.1 with a patched PHP version. We strongly recommend updating to BlueSpice 5 though.

Was my installation compromised?

As far as we know, there were no successful attacks before 2026-10-21.

Installing the update stops further exploitation. It does not remove anything an attacker may have left behind. The risk depends on what you did before the update:

• You took the wiki offline (or restricted access to trusted networks) when the early warning was published on 2026-10-21 and kept it offline until the update was installed: your installation should be safe. We still recommend the basic checks below.
• Your wiki stayed reachable from untrusted networks (especially from the internet) with an unpatched PHP version: the chances of a successful attack are high. Treat the installation as compromised and follow the procedure below.

Basic checks

1. PHP error log: check the log of the wiki-web container (./bluespice-deploy logs wiki-web) for messages like Allowed memory size of … bytes exhausted … in Unknown on line 0 and for PHP-FPM workers that ended with a segmentation fault (exited on signal 11). Such messages alone do not prove an attack, but they are a reason for a closer look.
2. Settings files in the data volume: check the files pre-init-settings.php and post-init-settings.php in the data volume of the wiki (/data/bluespice in the container) for content that you did not add. Also look for other unexpected .php files in the data volume. These files may be loaded by the wiki and are not replaced by the update.
3. Users and groups: check the members of the groups sysop and bureaucrat (Special:ListUsers) and recently created accounts (Special:Log/newusers).

Procedure for installations that stayed reachable

An attacker could run any command in the wiki container. This includes reading all secrets of the container, and reading and changing the database, the search index and all files in the data volume. Changes made directly in the database do not show up in the page history.

1. Preserve the evidence first. Before you reset anything, save all log files: the access logs of the reverse proxy, the logs of all containers (./bluespice-deploy logs > logs.txt; container logs are lost when the containers are removed), and the system logs of the server. Also keep a copy of the data volumes and a database dump of the current state for the analysis.
2. Renew the infrastructure. Set up a new server (or virtual machine) with a fresh operating system and install BlueSpice 5.1.11.1 or 5.2.7.1. Do not reuse the old server.
3. Use new credentials. Generate new passwords and secrets for the new installation (database passwords, the secrets in the .env file and the secret files of bluespice-deploy). Also change all credentials that were configured in the old installation, e.g. for LDAP, SAML, mail servers or other connected systems. Ask administrators and users to change their passwords.
4. Analyze the content before you move it to the new server:
   • Log files: look for unusually large POST requests, requests from unknown addresses and the PHP errors listed in the basic checks, starting from 2026-10-21. If your logs go back further, also check the days before.
   • Files: scan the data volume (uploaded files, settings files) with an up-to-date virus scanner. Look for .php files and other files that you do not know, and for files that were changed recently.
   • Pages: check Special:RecentChanges and Special:Log for unexpected changes. Pay special attention to pages in the MediaWiki namespace (e.g. MediaWiki:Common.js, MediaWiki:Common.css), user scripts, templates and pages with many readers. Look for injected scripts, links or forms. As changes made directly in the database leave no trace in the page history, compare important pages with a backup.
   • Users and permissions: check administrator accounts, new accounts, changes of user groups and, in BlueSpice pro and farm, OAuth applications (Special:OAuthListConsumers).
5. Restore. If possible, restore the data from a backup created before 2026-10-21. Otherwise, only move data that you have checked to the new server.
6. Check connected systems. The server could also be used to attack other systems in your network (lateral movement). Check systems that the wiki server can reach (e.g. directory services, file servers) as well.

If you find signs of an attack, please contact the Hallo Welt! GmbH support.