PHP SOAP: CVE-2026-6722 — unauthentifizierter Use-after-Free-RCE im ext-soap (plus vier weitere PHP-Funde im selben Release)

TL;DR — 90 Sekunden

Betroffen?

PHP-Anwendungen, die einen SoapServer betreiben und untrusted SOAP-Requests parsen (RCE-Pfad, CVE-2026-6722); zusätzlich jeder PHP-Stack über den urldecode()-OOB-Read (CVE-2026-7258) — unabhängig von SOAP. Betroffene Branches: PHP vor 8.2.31, 8.3.31, 8.4.21, 8.5.6 (mbstring-Fund nur vor 8.4.21 / 8.5.6).

Risiko?

CVE-2026-6722: Use-after-Free → unauthentifizierte RCE (CVSS 4.0 Base 9.5 laut DB/Berichten). Weitere: CVE-2026-7261 UAF (SoapServer/Session), CVE-2026-7262 NULL-Deref → DoS, CVE-2026-7258 OOB-Read in urldecode(), CVE-2026-6104 mbstring-Overrun (Info-Disclosure).

Sofortmassnahme?

Auf das jeweilige Patch-Release ziehen (8.2.31 / 8.3.31 / 8.4.21 / 8.5.6). Wo kein SOAP nötig ist: ext-soap gar nicht erst laden. SoapServer auf untrusted Input nicht ohne Patch betreiben.

Empfehlung?

Mid-Market und Enterprise: PHP-Point-Release als regulären, aber priorisierten Bump behandeln; ext-soap-Präsenz im Stack inventarisieren (auch transitiv über Alt-Integrationen/Libs); SoapServer-Endpunkte hinter Auth/Allowlist.

Kritikalität?

high (referenziert das Hero-Badge — unauth RCE-Pfad bei SoapServer-Exposure; der urldecode()-Teil betrifft alle PHP-Stacks).

Was ist das Problem?

Die PHP-SOAP-Extension hat eine lange Historie von Memory-Corruption-Fehlern — diese Runde überschreitet aber die Linie zur unauthentifizierten RCE. Der zentrale Fund, CVE-2026-6722, sitzt in der Art, wie ext-soap beim Parsen eines XML-Dokuments Objekte im XML-Graphen über die Attribute id und href dedupliziert: Die Extension legt einfache PHP-Objekte in eine globale Hash-Map ab, versäumt aber, den Reference-Count zu erhöhen. Über den „Apache map“-Mechanismus kann ein Angreifer diese Objekte gezielt freigeben, indem er bestehende Map-Einträge überschreibt — das freigegebene Speichersegment wird danach wiederverwendbar. Laut dem Forscher Brett Gervasoni lässt sich dieser Speicher anschliessend durch das Allozieren einfacher Strings hochgradig kontrollieren und der Fehler bis zur vollständigen Remote Code Execution eskalieren.

Entscheidend für die Schwere: Die Ausnutzung erfordert lediglich, einen präparierten SOAP-Request-Body an einen PHP-Endpunkt zu senden, der die SOAP-Extension zum Parsen von Client-Input aufruft — ohne Authentifizierung, wenn der Endpunkt unauthentifizierten SOAP-Verkehr annimmt. Genau das ist die klassische SOAP-Server-Konstellation. Die Berichterstattung/DB führt CVE-2026-6722 mit CVSS 4.0 Base 9.5 als kritisch (die Erst-Aufnahme spricht zugleich von „high-severity“ — wir geben beides ehrlich wieder und leiten die Schwere primär aus „remote + unauth + RCE“ ab, nicht aus einer einzelnen Zahl).

Neben dem RCE-Fund hat das PHP-Team im selben Schwung vier weitere, moderate Schwachstellen über GitHub adressiert. CVE-2026-7261 ist ein weiterer Use-after-Free im SoapServer beim Umgang mit session-persistierten Objekten: Schlägt die Handler-Funktion eines Header-Knotens fehl oder wirft eine Exception, wird das Objekt fälschlich freigegeben, aber dennoch in den Session-Storage geschrieben. CVE-2026-7262 ist ein NULL-Pointer-Dereference beim Dekodieren von „Apache: Map“-Knoten — ein XML-Request ohne Value-Knoten lässt den PHP-Prozess zuverlässig abstürzen (DoS). CVE-2026-7258 ist ein Out-of-bounds-Read in der nativen urldecode()-Funktion (fehlender Type-Cast bei der Auswertung von Hex-Zeichen, negative Byte-Werte → Segfault auf manchen Plattformen, z. B. NetBSD) — dieser Fund betrifft PHP unabhängig von SOAP. Und CVE-2026-6104 betrifft die mbstring-Extension: Encoding-Namen mit eingebetteten NUL-Bytes lösen einen globalen Buffer-Overrun aus (Information Disclosure, nicht direkt RCE-fähig).

Wer ist betroffen?

Für unseren Kontext wichtig und ehrlich: Der spektakuläre Teil — die unauth RCE — greift nur, wenn tatsächlich ein SoapServer untrusted Input verarbeitet. Wer SOAP nicht (mehr) betreibt, ist hier nicht exponiert. Der unscheinbare Teil — urldecode() — ist die eigentliche Breitenwirkung, weil urldecode() in unzähligen Stacks vorkommt und der Fund SOAP-unabhängig ist. Die Patch-Liste (8.2.31 / 8.3.31 / 8.4.21 / 8.5.6) ist die massgebliche Referenz; konkrete Versionsstände immer gegen das PHP-Advisory bzw. die eigene Distribution abgleichen.

Auswirkungen

Die operative Schwere zerfällt in zwei sehr unterschiedliche Profile. CVE-2026-6722 ist das Worst-Case-Profil: Ein einzelner präparierter SOAP-Body gegen einen unauthentifizierten SoapServer kann — über die kontrollierte Wiederbelegung des freigegebenen Speichers mit Strings — zu Remote Code Execution führen. Das ist Total-Übernahme des Workers, ohne Vorbedingung ausser „der Endpunkt parst meinen SOAP-Input“. Genau diese Konstellation (öffentlich erreichbarer SOAP-Endpunkt ohne Auth) ist in Alt-Integrationen, B2B-Schnittstellen und Legacy-Webservices verbreitet — und oft vergessen.

Die übrigen vier Funde sind weniger dramatisch, aber nicht irrelevant. CVE-2026-7261 (UAF im SoapServer/Session) und CVE-2026-7262 (NULL-Deref → DoS) verbreitern die SOAP-Angriffsfläche um Absturz- und potenzielle Folgekorruption. CVE-2026-7258 ist der eine, der jeden betrifft: urldecode() wird in Routing, Query-Parsing, Form-Handling und Dritt-Bibliotheken massenhaft aufgerufen; ein OOB-Read mit plattformabhängigem Segfault ist zwar primär ein Stabilitäts-/DoS-Problem, gehört aber genau deshalb in jeden Patch-Plan. CVE-2026-6104 (mbstring) ist eine Info-Disclosure über einen globalen Buffer-Overrun beim Parsen von Encoding-Namen mit NUL-Bytes — nicht direkt für Code-Execution nutzbar, aber ein Leck.

Eine einzelne, einheitliche CVSS-Zahl für das ganze Bündel gibt es nicht; die Quelle nennt für 6722 CVSS 4.0 Base 9.5 (kritisch) und stuft die übrigen als moderat ein. Wir behandeln das Bündel operativ als „ein PHP-Point-Release, das ohnehin eingespielt gehört — mit einem RCE-Fund obendrauf, falls SOAP exponiert ist“.

Mitigation / Sofortmassnahmen

Hinweis: Die folgenden Schritte sind unsere operative Empfehlung auf Basis der dokumentierten Funde und Fix-Versionen — keine herstellerzertifizierte Anleitung. Konkrete Versionsstände gegen das PHP-Advisory GHSA-85c2-q967-79q5 bzw. Ihre Distribution abgleichen.

Operational Decision Block

• Sofort handeln, wenn … ein SoapServer untrusted/unauthentifizierten SOAP-Input parst (RCE-Pfad CVE-2026-6722).
• Priorisiert prüfen, wenn … Ihr PHP-Stack auf einem Branch vor 8.2.31/8.3.31/8.4.21/8.5.6 läuft — wegen des SOAP-unabhängigen urldecode()-Funds betrifft das praktisch alle.
• Reine Awareness, wenn … Sie bereits auf dem Patch-Release sind und ext-soap nicht laden.

Schritt 1 — PHP auf das Patch-Release ziehen

# aktuelle Version pruefen
php -v
# Ziel-Releases: 8.2.31 / 8.3.31 / 8.4.21 / 8.5.6 (Branch-passend)
# Debian/Ubuntu (Distribution liefert i. d. R. backportierte Fixes):
apt-get update && apt-get install --only-upgrade php php-cli php-fpm php-soap php-mbstring
# Container: Basis-Image auf gepatchtes PHP heben und neu bauen

Schritt 2 — SOAP-Angriffsfläche eliminieren, wo nicht gebraucht

# Laeuft ext-soap ueberhaupt? (oft unbemerkt geladen)
php -m | grep -i soap
# Wenn SOAP nicht gebraucht wird: Extension nicht laden
#  - php.ini / conf.d: die soap-Extension auskommentieren/entfernen
#  - im Container: das Modul gar nicht erst hineinbauen (docker-php-ext-install soap weglassen)

Schritt 3 — Exponierte SoapServer absichern (bis gepatcht)

- SoapServer-Endpunkte hinter Authentifizierung/Allowlist stellen
  (CVE-2026-6722 ist unauth NUR, wenn der Endpunkt unauth SOAP annimmt)
- oeffentlich erreichbare SOAP-Endpunkte am Reverse-Proxy beschraenken
- WSDL/Endpunkt-Inventar: welche Services parsen Client-SOAP? (oft Legacy/B2B)

Schritt 4 — Composer-/Stack-Inventar gegen ext-soap

# Pakete/Integrationen, die ext-soap voraussetzen (auch transitiv)
composer why-not ext-soap 2>/dev/null
grep -RIn "new SoapServer\|new SoapClient\|SoapServer(" --include=*.php .

Detection / Prüfung

Prüfpunkte aus den dokumentierten Funden und gängiger PHP-Inventarisierung abgeleitet.

Version & Modul-Inventar

# PHP-Version pro Host/Container/FPM-Pool
php -v; php-fpm -v 2>/dev/null
# ist soap/mbstring geladen?
php -m | grep -iE "soap|mbstring"
# Container-Images scannen statt nur Hosts
grype <image-ref> 2>/dev/null | grep -iE "php|ext-soap"

SOAP-Nutzung im Code finden

# SoapServer-Instanzen (untrusted-Input-Parser) und SOAP-Endpunkte
grep -RInE "new\s+SoapServer|SoapServer\(|->handle\(" --include=*.php .
# Routen/Controller, die SOAP-Bodies annehmen
grep -RInE "Content-Type:.*xml|text/xml|application/soap\+xml" --include=*.{php,conf,yaml} .

Laufzeit-Indikatoren

- PHP-FPM-Worker-Crashes/Segfaults bei SOAP-Requests (UAF/NULL-Deref-Trigger)
- Segfaults rund um urldecode() in Logs (CVE-2026-7258), plattformabhaengig
- ungewoehnliche Kindprozesse eines PHP-FPM-Workers (moegliche RCE-Folge bei 6722)
- gehaeufte 500er/Worker-Restarts auf SOAP-Endpunkten (moeglicher DoS, 7262)

Betreiberempfehlung

Mittelstand

Den PHP-Point-Release einspielen — nicht wegen SOAP, sondern wegen urldecode(): Dieser Fund betrifft Ihren Stack auch dann, wenn Sie nie eine Zeile SOAP geschrieben haben. Prüfen Sie nebenbei mit php -m | grep -i soap, ob ext-soap überhaupt geladen ist (oft ist es das aus historischen Image-Defaults, ohne dass es jemand nutzt) — wenn nein, gehört es raus, das verkleinert die Angriffsfläche dauerhaft. Falls doch irgendwo ein SoapServer öffentlich Client-Input annimmt, ist das Ihr dringender Fall: patchen oder bis dahin hinter Auth/Allowlist.

Enterprise

Zusätzlich: SBOM-/Inventar-getriebene Suche nach ext-soap über alle Images, FPM-Pools und Alt-Integrationen — gerade B2B-/Legacy-Webservices halten SOAP oft länger am Leben als das Projektgedächtnis. Behandeln Sie das PHP-Release als priorisierten Security-Bump mit eigenem SLA, nicht als Routine. Für die urldecode()-Breite lohnt ein kurzer Blick auf plattformspezifische Segfault-Telemetrie. Wo SoapServer produktiv bleiben muss: Auth erzwingen, Input-Grössen begrenzen, Worker isolieren, damit ein erfolgreicher UAF nicht zu lateraler Bewegung wird.

Kubernetes / Container

Basis-Images auf das gepatchte PHP heben und neu bauen; prüfen, ob soap/mbstring über docker-php-ext-install überhaupt hineingebaut werden — wenn nicht gebraucht, weglassen. PHP-FPM-Pods, die SOAP parsen, gehören in einen minimal privilegierten Namespace mit harten Ressourcen-Limits (gegen die DoS-Funde) und ohne breiten ausgehenden Netzzugang (begrenzt den RCE-Blast-Radius). Endpunkt-Exposure über NetworkPolicy/Ingress einschränken.

Deklarative Stacks (NixOS / Talos / Flatcar)

Der Hebel ist die explizite Feature-Matrix: Wer PHP deklarativ mit genau den benötigten Extensions baut, hat ext-soap entweder bewusst drin oder sauber draussen — kein „ist halt aus dem Base-Image mitgekommen“. Der Rebuild auf die gepatchte Version ist reproduzierbar und nachweisbar, und ein Build ganz ohne SOAP-Extension ist gegen CVE-2026-6722/-7261/-7262 strukturell nicht erreichbar. Genau das ist hier der saubere Default für alle, die SOAP — wie wir — praktisch nicht mehr einsetzen.

Was wir konkret getan haben

Volle Offenheit: Wir setzen SOAP in unseren betreuten Stacks praktisch nicht mehr ein — der RCE-Fund (CVE-2026-6722) ist für uns also primär ein Inventar- und Hygiene-Anlass, kein Brandherd. Anlassbezogen heisst das: über die betreuten Stacks php -m | grep -i soap gefahren, um geladene-aber-ungenutzte ext-soap-Instanzen aus alten Image-Defaults zu finden und zu entfernen; Composer-/Code-Sweep auf SoapServer/SoapClient; und — der eigentlich breite Teil — die PHP-Point-Releases (8.2.31 / 8.3.31 / 8.4.21 / 8.5.6) als priorisierten Bump eingeplant, weil der urldecode()-Fund (CVE-2026-7258) SOAP-unabhängig jeden Stack betrifft.

Die Lehre ist unspektakulär, aber genau deshalb wertvoll: Eine „abgeschaltete“ Technologie ist nicht dasselbe wie eine „nicht geladene“ Technologie. ext-soap reist in vielen PHP-Images als Default mit, auch wenn die Anwendung längst auf REST/JSON umgestellt hat — und eine geladene Extension ist Angriffsfläche, ob genutzt oder nicht. Deshalb ist unsere stehende Empfehlung hier nicht „SOAP patchen“, sondern „SOAP, das niemand mehr braucht, gar nicht erst laden“ — und den ohnehin fälligen PHP-Release wegen der nicht-SOAP-Funde zeitnah ziehen.

Tiefer Blick: warum die Deduplizierung zur RCE wird

Der Kern von CVE-2026-6722 ist ein klassisches Refcount-Versäumnis in einer Optimierung. SOAP-XML kann Objekte über id/href referenzieren, statt sie zu duplizieren — die Extension merkt sich dafür Objekt-Zeiger in einer globalen Map. Korrekt wäre, beim Ablegen den Reference-Count zu erhöhen, damit das Objekt nicht freigegeben wird, solange die Map es referenziert. Genau das passiert nicht: Der Zeiger liegt in der Map, der Refcount bleibt unverändert. Über den „Apache map“-Mechanismus kann ein Angreifer denselben Map-Eintrag überschreiben und so das ursprüngliche Objekt freigeben, während die (jetzt verwaiste) Referenz weiterlebt — ein lehrbuchhafter Use-after-Free. Der Schritt zur RCE ist dann Heap-Grooming: Das freigegebene Segment lässt sich mit einfachen PHP-Strings neu belegen, deren Inhalt der Angreifer kontrolliert; damit wird aus „freigegebener, aber referenzierter Speicher“ ein kontrollierter Speicherbereich. Lehre für eigenen Code und Extensions: Jede Caching-/Dedup-Schicht, die rohe Zeiger ohne Ownership-Buchführung hält, ist ein UAF-Kandidat — die Optimierung muss den Lebenszyklus mitverwalten, nicht nur die Identität.

Fazit

Für Stacks, die SOAP noch produktiv betreiben, ist CVE-2026-6722 ein ernster Fall: unauthentifizierte RCE über einen einzelnen präparierten Request, ohne Vorbedingung ausser einem parsenden Endpunkt. Für alle anderen — uns eingeschlossen — ist die Lage zweigeteilt und unspektakulär: Der RCE-Pfad greift nicht ohne SoapServer, aber der mitausgelieferte urldecode()-Fund betrifft jeden PHP-Stack, also gehört der Point-Release ohnehin eingespielt. Die stehende Lehre ist die wertvollste: „Abgeschaltet“ heisst nicht „nicht geladen“ — eine ext-soap, die als Image-Default mitreist, ist Angriffsfläche, auch wenn die App längst auf REST umgestellt hat. Ungenutztes SOAP entladen, den fälligen PHP-Release wegen der nicht-SOAP-Funde ziehen, und exponierte SoapServer hinter Auth. Konkrete Versionsstände gehören zum PHP-Advisory, nicht zu einer Momentaufnahme. Kein 48h-Tagesfall — aber ein sauberer PHP-Hygiene-Anlass, der zu lange liegen bleibt, wenn ihn niemand explizit aufgreift.

Quellen

• Cyber Security News — Critical PHP SOAP Extension Vulnerabilities Enables Remote Code Execution Attacks (12.05.2026; Cluster-Übersicht, Verweis auf das PHP-Advisory)
• PHP-Security-Advisory GHSA-85c2-q967-79q5 (php/php-src; massgebliche Fix-Versionen)
• SentinelOne CVE-DB — CVE-2026-6722 (PHP SOAP Extension RCE)
• SentinelOne CVE-DB — CVE-2026-7261 (PHP SoapServer Use-After-Free)