Leuffen.deBlog

Security · PHP BCMath-Erweiterung – bccomp()

PHP: Präparierte externe Werte können bccomp()-Speicher beschädigen

kritisch

Betroffen sind PHP 8.4 vor 8.4.24 und PHP 8.5 vor 8.5.9 – aber nur Anwendungen, die von außen beeinflussbare Werte an bccomp() übergeben. Dann kann eine gewöhnlich wirkende Anfrage den Speicher des PHP-Prozesses beschädigen.

CVE
CVE-2026-17544
Betroffen
PHP 8.4 vor 8.4.24 und PHP 8.5 vor 8.5.9; betroffen ist die BCMath-Funktion bccomp(), wenn ein Angreifer Operanden oder die Zahl der zu vergleichenden Nachkommastellen beeinflussen kann. Bei Ubuntu betrifft die konkrete Schwachstelle laut Canonical PHP 8.5 in Ubuntu 26.04 LTS.
Behoben
Upstream: PHP 8.4.24 beziehungsweise 8.5.9 oder neuer; Ubuntu 26.04 LTS: php8.5-Pakete ab 8.5.4-0ubuntu1.3

BCMath ist eine PHP-Erweiterung für Dezimalrechnungen, bei denen gewöhnliche Gleitkommazahlen zu ungenau wären. Ihre Funktion bccomp() vergleicht zwei als Zeichenketten übergebene Dezimalzahlen. CVE-2026-17544 betrifft diesen Vergleich: Präparierte Operanden und eine passende Angabe der zu vergleichenden Nachkommastellen können PHP dazu bringen, außerhalb des vorgesehenen Speicherbereichs zu schreiben.

Ein solcher „Out-of-bounds write“ ist ein Programmfehler, bei dem Daten außerhalb des reservierten Speichers landen. Das kann den PHP-Prozess zum Absturz bringen oder seinen Ablauf verändern. Canonical nennt neben einem Ausfall des Dienstes auch die mögliche Ausführung fremden Codes.

Was die Bewertungen tatsächlich sagen

CVSS ist ein standardisiertes Schema zur Beschreibung der technischen Schwere einer Schwachstelle. Verschiedene CVSS-Versionen verwenden unterschiedliche Kennzahlen und sind deshalb nicht direkt wie zwei Messungen derselben Skala zu vergleichen.

Der von PHP veröffentlichte CVE-Datensatz bewertet die Lücke mit CVSS 4.0: 8,1 – High. Das PHP-Upstream-Advisory führt sie ebenfalls als High. Canonicals Ubuntu-Seite zeigt zusätzlich CVSS 3.1: 9,8 – Critical, setzt die eigene Ubuntu-Priorität aber auf Medium. Die technische Wirkung kann also sehr schwer sein, während das praktische Risiko einer konkreten Installation von Version, Anwendungscode und erreichbarem Datenpfad abhängt.

Im Radar bleibt die Stufe kritisch, jedoch ausdrücklich bedingt: Erst eine Anwendung, die fremde Eingaben an die verwundbare Funktion weiterreicht, öffnet den Weg zum Fehler.

Das Szenario – drei getrennte Rollen

Ein gewöhnlicher Nutzer trägt beispielsweise in einem Preisformular einen Betrag ein. Die Anwendung verarbeitet diesen Wert und vergleicht ihn im Hintergrund mit einer Grenze. Für diesen normalen Nutzer ist weder eine Warnung noch eine besondere technische Handlung sichtbar.

Ein Angreifer sendet stattdessen einen präparierten Dezimalwert über dasselbe Formular, eine API oder einen Import. Die Anfrage kann äußerlich gewöhnlich wirken. Sie ist nur dann wirksam, wenn der kontrollierte Wert als Operand oder Nachkommastellenangabe tatsächlich bei bccomp() ankommt.

Auf dem Server verarbeitet ein PHP-Prozess diesen Funktionsaufruf. Trifft die passende Eingabe auf eine verwundbare PHP-Version, kann der Speicher beschädigt werden. Wiederholte PHP-FPM-Neustarts, Segmentierungsfehler, Core-Dumps oder kurzzeitige HTTP-502-Antworten wären mögliche Betriebsanzeichen. Sie sind unspezifisch, können viele andere Ursachen haben und eignen sich weder als Beweis für einen Angriff noch als Entwarnung, wenn sie fehlen.

Wann ein Angriff aus der Ferne möglich ist

Die Kennzeichnung remote_exploitable: true gilt nur, wenn alle folgenden Bedingungen zusammentreffen:

  1. Die Anwendung läuft mit einer betroffenen PHP-Version.
  2. Ein Angreifer kann mindestens einen an bccomp() übergebenen Wert beeinflussen.
  3. Der entsprechende Formular-, API- oder Importweg ist für ihn erreichbar – offen oder nach einer Anmeldung.

Wer bccomp() ausschließlich mit intern erzeugten, zuverlässig begrenzten Werten aufruft, hat diesen konkreten Fernzugriffspfad nicht. Ob das wirklich so ist, sollte anhand des Codes und des Datenflusses geprüft werden. Die Annahme, ein Eingabefeld enthalte „nur Zahlen“, ist noch keine technische Grenze.

Betroffene und korrigierte Versionen

Der PHP-CVE-Datensatz nennt folgende betroffene Bereiche:

  • PHP 8.4 vor 8.4.24
  • PHP 8.5 vor 8.5.9

Das PHP-Changelog dokumentiert die Korrektur für 8.5.9 ausdrücklich. Canonical veröffentlichte am 10. September 2026 korrigierte Pakete für Ubuntu 26.04 LTS ab 8.5.4-0ubuntu1.3. Ubuntu 24.04 mit PHP 8.3 und Ubuntu 22.04 mit PHP 8.1 führt Canonical für diese konkrete Schwachstelle als nicht betroffen.

Bei Distributionspaketen ist die Paketversion maßgeblich. Distributionen können eine Sicherheitskorrektur zurückportieren, ohne die sichtbare PHP-Basisversion auf die Upstream-Version des Fixes anzuheben.

Was jetzt sinnvoll ist

Betreiber sollten zuerst die tatsächlich installierte PHP- beziehungsweise Distributionsversion feststellen und eine korrigierte Ausgabe einspielen. Danach lohnt sich eine gezielte Suche nach bccomp( im eigenen Code und in unmittelbar kontrollierten Abhängigkeiten.

Für jeden Treffer ist zu klären, ob Werte aus HTTP-Anfragen, Nachrichtenwarteschlangen, Importdateien oder anderen fremden Quellen bis zu diesem Aufruf gelangen. Längen- und Formatgrenzen können die Angriffsfläche verkleinern, ersetzen das Update aber nicht.

In den geprüften Primärquellen wird keine aktive Ausnutzung bestätigt. Das ist die Grenze des belegbaren Stands vom 12. September 2026 und kein Beweis dafür, dass es keine unbemerkten Angriffe gibt.

Quellen

Quellenstand: 12. September 2026.

Originalmeldung öffnen →