PHP CVE-2025-14177: getimagesize() blutet Heap-Speicher, iptcembed() bleibt offen

TL;DR — 90 Sekunden

Was ist das Problem?

JPEG-Dateien transportieren ihre Metadaten in „Application Segments“ — kleinen, hintereinander geketteten Blöcken im Dateikopf, in denen Kameras, Bildbearbeitungsprogramme und Content-Management-Systeme Informationen wie Aufnahmedatum, GPS-Koordinaten, IPTC-Stichwörter oder ICC-Farbprofile ablegen. PHPs ext/standard-Extension hat zwei Funktionen, die diese Segmente lesen und schreiben: getimagesize() zieht Dimensionen, MIME-Type und IPTC-Daten heraus, iptcembed() schreibt IPTC-Daten in eine vorhandene JPEG-Datei zurück. Beide Funktionen sind seit über zwei Dekaden im Sprachkern, beide werden in CMS-Upload-Workflows, in E-Commerce-Produktpflege und in Asset-Pipelines aufgerufen, oft ohne dass es im Anwendungs-Code sichtbar ist.

Nikita Sveshnikov von Positive Technologies (PT SWARM) hat am 17. Mai zwei voneinander unabhängige Memory-Safety-Bugs in dieser Schicht offengelegt. Der erste Bug, CVE-2025-14177, sitzt in der internen Hilfsfunktion php_read_stream_all_chunks, die JPEG-APP-Segmente blockweise in einen Heap-Puffer liest. Die Funktion alloziert den Zielpuffer einmal initial, schreibt aber bei jedem read-Aufruf an den Anfang des Puffers, anstatt den Schreibzeiger fortzuschalten. In der Folge überschreiben spätere Chunks die Daten der vorherigen, und der Schwanz des Puffers bleibt mit unzufälligem Heap-Inhalt aus früherer Allokation gefüllt. Eine speziell präparierte JPEG-Datei, die den Parser in den „read everything until EOF“-Modus zwingt, kann diese unzufälligen Bytes als Teil der Funktionsrückgabe zurück an den Aufrufer geben — und damit Fragmente fremder Prozess-Heap-Inhalte exfiltrieren.

Der zweite Bug ist eine Variante der gleichen Bug-Klasse („measure once, read forever“) in iptcembed(). Diese Funktion fragt einmal per fstat die Größe der Eingabedatei ab und alloziert auf dieser Basis den Output-Puffer — dann liest sie aber in einer Schleife weiter, ohne die Schreibgrenze pro Iteration neu zu prüfen. Eine JPEG-Datei, deren Inhalt im Lese-Verlauf wächst (klassisch: Race auf dem Filesystem, oder ein speziell gebauter Pipe-Stream), führt zu Out-of-Bounds-Schreiben auf den Heap. Der Patch für CVE-2025-14177 ist in den oben genannten Maintenance-Versionen enthalten; für iptcembed() lag zu Redaktionsschluss noch kein offizieller Fix vor.

Bug-Klasse im Klartext

Beide Bugs sind keine Logikfehler, sondern Pflege-Schulden aus der Frühzeit der C-Implementierung. Die Funktionen wurden gebaut, als JPEG-APP-Segmente klein waren und Pufferarithmetik in jedem zweiten C-Programm so geschrieben wurde. Was sie heute angreifbar macht, ist nicht die Bösartigkeit eines Angreifers, sondern die Tatsache, dass CMS- und E-Commerce-Plattformen Dateien aus dem Internet annehmen und durch genau diese Funktionen schleusen. Das ist der eigentliche Kontext: Es geht nicht um einen exotischen Edge-Case, sondern um die Standard-Pipeline für Produktbilder, Pressefotos und Avatar-Uploads.

Wer ist betroffen?

Betroffen ist jeder PHP-Prozess der oben genannten Versionsspanne, der getimagesize() oder iptcembed() auf nicht vertrauenswürdige Eingabedateien aufruft. Das schliesst die meisten CMS-Upload-Pfade, fast alle Sylius-Produktpflege-Pipelines und einen großen Teil der Composer-getriebenen B2B-Plattformen mit ein. Plattformen, die JPEGs ausschließlich aus einem geprüften CDN oder einem internen DAM ziehen, sind nicht betroffen.

Auswirkungen

CVE-2025-14177 ist eine Information-Disclosure mit CVSS 6.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) — netzwerkbasierte Auslösung, ohne Privilegien, mit Nutzerinteraktion (Upload-Klick), Auswirkung ausschließlich auf Vertraulichkeit. Was in der Score-Tabelle harmlos aussieht, ist im operativen Befund unangenehmer: Geleakter Heap-Inhalt kann Session-Tokens, OPCache-Inhalte, Datenbank-Verbindungs-Strings oder andere zuvor in dieser PHP-Prozess-Inkarnation verarbeitete Daten enthalten. In Long-Running-FPM-Pools (z. B. statt PHP-FPM-pm=ondemand auf pm=static) sammelt sich über Stunden eine Heap-Geschichte an, die der nächste Upload abgreifen kann. Wer Bilder im Response zurückgibt (Bildvorschau, Thumbnail-Generierung mit Re-Embed der Original-Metadaten), gibt Heap-Inhalt in den Browser-Cache des Anfragers.

Der iptcembed()-Bug ist die ernstere Lage. Ein Heap-Buffer-Overflow in einer C-Funktion, die ohne Hardening (kein PIE, keine FORTIFY_SOURCE im Build) ausgeliefert wird, ist im Worst-Case ein RCE-Pfad. Im realistischen Mittelstands-Kontext heißt das: Wer auf einem produktiven PHP-FPM-Pool eine Race-Condition oder einen Pipe-Stream auf eine iptcembed-Routine fahren kann, kann den Prozess crashen (DoS auf dem Worker) oder, je nach Hardening, eigene Anweisungen auf dem Heap unterbringen. Der Angriffsweg setzt voraus, dass der Angreifer den Schreib-Pfad in iptcembed() reproduzierbar triggert — das ist in CMS-Upload-Workflows nicht der Standardfall, in Asset-Pipelines mit nachgelagerter IPTC-Anreicherung aber durchaus. Solange kein PHP-Patch da ist, ist die operative Mitigation wichtiger als das Score-Niveau.

Business-Auswirkung im Mittelstands-Sinn: Ein Information-Disclosure aus dem PHP-Heap kann personenbezogene Daten freilegen (DSGVO Art. 32 — Sicherheit der Verarbeitung). Ein DoS auf produktive PHP-FPM-Worker trifft Umsatz-tragende Endpunkte (Sylius-Checkout, TYPO3-Login-Seite) direkt. Im NIS-2-Kontext zählt ein bewusst ausgenutzter Information-Disclosure oder DoS als „signifikanter Sicherheitsvorfall“ und muss innerhalb der 24/72-Stunden-Fristen an das BSI gemeldet werden.

Mitigation / Sofortmaßnahmen

Die Reihenfolge ist nicht beliebig. Erst patchen, dann Workarounds, dann strukturell härten.

Pfad 1 — PHP-Patch einspielen (CVE-2025-14177)

Für Debian-/Ubuntu-Repositorien (Sury) und für Wolfi-/Chainguard-Bilder sind die Patches da. Beispielhaft für die meistgenutzten Stränge:

# Debian/Ubuntu mit Sury-Repo
apt update
apt install --only-upgrade php8.3 php8.3-cli php8.3-fpm php8.3-common
# Ziel: 8.3.29 oder höher
php -v

# Wolfi-Container (manueller Build)
docker pull chainguard/php:8.3
docker run --rm chainguard/php:8.3 php -r "echo PHP_VERSION, PHP_EOL;"

# Composer-Projekt mit PHP-Anforderung im composer.json prüfen
composer why-not php 8.3.29

Für Container-Images: Nicht den Tag-Alias updaten, sondern den vollen SHA-Digest pinnen, sobald der nightly Build durch ist. Sonst wandert ein nicht reproduzierbarer Stand in Produktion.

Pfad 2 — Workaround für iptcembed() (kein Patch verfügbar)

Bis der iptcembed()-Fix in PHP-Upstream ist, drei aufeinander aufbauende Schritte:

// 1. iptcembed im Anwendungs-Code auskommentieren oder durch eine geprüfte
//    Alternative ersetzen (Imagick::setImageProperty + writeImage), wenn
//    die Bibliothek das hergibt.
$im = new Imagick($jpegPath);
$im->setImageProperty('IPTC:2:120', $caption);
$im->setImageProperty('IPTC:2:25', $keywords);
$im->writeImage($jpegPath);
$im->clear();

// 2. Wenn iptcembed() nicht ersetzbar ist: per disable_functions in der
//    php.ini sperren und im Anwendungs-Code defensive Fallback-Logik
//    einbauen, die ohne IPTC-Re-Embed lebt.
// php.ini:
//   disable_functions = iptcembed

// 3. Für nachgelagerte Asset-Pipelines (Cron, Queue-Worker): JPEG-
//    Metadaten ausschliesslich über externe Tools (exiftool im sandboxed
//    Container) schreiben, nicht über den PHP-Prozess.

Pfad 3 — Strukturell: Upload-Härtung

Wer Upload-JPEGs annimmt, sollte die Datei vor dem PHP-Parser durch ein normalisierendes Tool schicken — ImageMagick im rootless Container, oder jpegtran mit --copy=none. Damit verlässt das JPEG den Eingangs-Pfad ohne fremde APP-Segmente, und getimagesize() oder iptcembed() sieht nur sauberes Material.

# Beispiel: ImageMagick im rootless Container für JPEG-Normalisierung
docker run --rm -v "$(pwd)/uploads:/in:ro" -v "$(pwd)/clean:/out" \
    --read-only --cap-drop=ALL --user=1000:1000 \
    chainguard/imagemagick:latest \
    convert /in/upload.jpg -strip /out/normalized.jpg

# Anschliessend in PHP nur das normalisierte Bild parsen
$info = getimagesize('/path/to/clean/normalized.jpg');

Diese Pipeline ist nicht nur eine Mitigation für CVE-2025-14177, sondern eine generelle Härtungsempfehlung — sie reduziert die Angriffsfläche für die nächste JPEG-Memory-Bug-Variante, die in zwölf Monaten kommen wird.

Detection / Prüfung

Eine direkte Detection für gestohlene Heap-Bytes ist nicht trivial, weil der Exfil-Pfad über reguläre HTTP-Responses läuft. Die operativen Hebel liegen einen Schritt vor und einen Schritt nach dem PHP-Prozess.

Vor dem PHP-Prozess — Upload-Anomalie-Erkennung

# JPEGs mit auffällig grossen APP-Segmenten markieren
# (Schwellwert empirisch: gesunde Editorial-JPEGs liegen meist <128 KB
# APP1+APP13; Trigger bei >1 MB lohnen Aufmerksamkeit)
exiftool -j -G uploaded.jpg | jq '.[] | {APP1Length:.["APP1:DirectoryItemLength"], APP13Length:.["APP13:DirectoryItemLength"]}'

# Alternativ: jpeginfo / jpegtran als Sanity-Check
jpeginfo -c uploaded.jpg
jpegtran -copy none -optimize uploaded.jpg > /dev/null && echo "ok" || echo "anomalous"

Im PHP-Prozess — OPCache- und FPM-Memory-Inspektion

Wenn der Verdacht besteht, dass eine Disclosure stattgefunden hat, ist die richtige Frage nicht „was wurde geleakt“, sondern „welche Geheimnisse waren im FPM-Pool zum Zeitpunkt der Anfrage präsent“. Das beantwortet kein Memory-Dump, sondern eine Inventur:

# Welche Geheimnisse landen prinzipiell im FPM-Heap?
# In php.ini suchen nach:
grep -E "^(session\.save_path|opcache\.|auto_prepend_file)" /etc/php/8.3/fpm/php.ini

# Welche Composer-Pakete machen Heap-Allokationen für sensible Daten?
composer show --installed | grep -iE "(jwt|oauth|encryption|sodium|paseto)"

Nach dem PHP-Prozess — Falco-Rule und eBPF-Trace

Wer eine Container-Sicherheits-Schicht hat (Falco, Tetragon), kann den Aufruf-Pfad getimagesize/iptcembed mit auffälligen Argument-Mustern markieren. Beispiel für Falco:

- rule: php_jpeg_upload_with_large_app_segment
  desc: PHP process reads a JPEG file with unusually large APP segment (heuristic for CVE-2025-14177 exploit attempt)
  condition: >
    spawned_process and
    proc.name in (php, php-fpm, php-fpm8.3) and
    fd.name endswith ".jpg" and
    fd.size > 10485760
  output: >
    Large JPEG read by PHP process (proc=%proc.name file=%fd.name size=%fd.size pid=%proc.pid)
  priority: WARNING
  tags: [cve-2025-14177, php, jpeg]

Eine analoge Tetragon-TracingPolicy auf den read-Syscall mit Dateinamen-Pattern *.jpg und Lese-Größe oberhalb eines Schwellwerts ist äquivalent und sitzt auf Kernel-Ebene.

Betreiberempfehlung

Operational Decision Block

• Sofort mitigieren, wenn … Sie produktive PHP-Plattformen mit öffentlichem Upload-Endpoint betreiben (TYPO3-Frontend-Formulare, Sylius-B2C-Avatare, Shop-Produkt-Editor mit nicht-administrativen Redakteuren). Patch heute, Pipe-Härtung diese Woche.
• Wartungsfenster möglich, wenn … Ihre PHP-Plattform JPEG-Uploads ausschließlich von authentifizierten Redakteur:innen aus einem geschlossenen Backend annimmt und keine Heap-sensiblen Geheimnisse im FPM-Pool liegen. Patch innerhalb der nächsten zwei Wochen, im normalen Maintenance-Slot.
• Reine Workstation- / lokale Entwicklung, wenn … Sie PHP lokal für Composer-Tooling nutzen und keine Webserver-Pfade exponieren. Patch beim nächsten Update der Distribution, kein eigener Slot nötig.

Mittelstand

Für den DACH-Mittelstand sitzen drei Hebel auf einer Linie: erstens das Gespräch mit dem Hosting-Anbieter (Mittwald, Hetzner-Managed, Plesk-Hoster, hostNET, alle haben unterschiedliche Patch-Linien), zweitens das eigene Composer-Projekt (composer why-not php 8.3.29 ist der schnellste Sanity-Check, ob die Anforderung im Lockfile passt), drittens die Frage, ob in den letzten 30 Tagen verdächtig große JPEG-Uploads angenommen wurden. Die Frage „haben wir reingeguckt?“ ist wichtiger als die Frage „haben wir gepatcht?“, weil ein Information-Disclosure-Score von 6.3 in der NIS-2-Welt schnell zu einer Meldepflicht wird, sobald ein Hinweis auf Ausnutzung vorliegt.

Enterprise / Container-Plattformen

Auf Container-Plattformen ist der Patch-Hebel die Build-Pipeline, nicht der Pod. Wer das Base-Image nachts neu zieht, hat den Patch am 18. Mai bereits im Roll-out. Wer das Base-Image quartalsweise pinnt, hat das Problem bis August. Dazwischen liegt die Mehrzahl der mittelständischen Container-Stacks. Die Entscheidungsfrage lautet hier nicht „patchen oder nicht“, sondern „Build-Pipeline auf Daily-Rolling umstellen oder weiter Quartal-Pins fahren“. Wir empfehlen Daily-Rolling für alle Container, die einen öffentlichen Eingangs-Endpoint anfassen, und Quartal-Pins nur für rein interne Worker.

Kubernetes / OpenShift

In Kubernetes sind die operativen Schritte: imagePullPolicy: Always setzen, das Deployment mit einem Annotation-Trigger versehen, der nachts ein Rolling-Update ausführt, und im PodSecurityContextreadOnlyRootFilesystem: true plus allowPrivilegeEscalation: false setzen, damit ein Heap-Overflow nicht in einen Container-Escape übergeht. Wer Karpenter oder Cluster-Autoscaler nutzt, sollte die Container-Image-Caches der Worker-Nodes auf TTL=24h setzen, sonst zieht der Scheduler veraltete Images.

Deklarative Stacks (NixOS / Talos / Flatcar)

In deklarativen Stacks ist der Patch eine Pin-Erhöhung im Nix-Flake oder im Talos-Patch-File und ein vollständiger Rebuild. Der Vorteil: der Stand ist reproduzierbar und auditfähig. Der Nachteil: Wer das Pin nicht erhöht, fährt ohne Patch weiter, ohne dass eine apt-update-Routine die Korrektur einspielt. Beim nächsten Flake-Update den php-Pin auf 8.3.29 / 8.4.16 / 8.5.1 setzen und den Build verifizieren.

Was wir konkret getan haben

Wir haben am 17. Mai gegen 22:00 Uhr die Disclosure des PT-SWARM-Teams gelesen und am 18. Mai morgens die gepatchte PHP-Version automatisiert über unsere Build-Pipeline ausgerollt — sowohl auf der Moselwal-Hauptseite (TYPO3-getrieben, JPEG-Uploads aus dem Editor-Backend) als auch auf den drei Kunden-Plattformen, die wir aktiv betreiben.

Der Rollout lief über die normale Update-Kette unserer Base-Images: Sobald die gepatchten PHP-Maintenance-Versionen in Wolfi verfügbar waren, hat die CI-Pipeline die Base-Images neu gebaut und in derselben Sequenz alle abhängigen Application-Images automatisch nachgezogen. Die aktualisierten SHA-Digests landeten in den Kubernetes-Deployments, ein Rolling-Update auf den Worker-Pools setzte den Patch produktiv. Manuelles Eingreifen pro Projekt war nicht nötig; die Pipeline ist genau für diesen Fall gebaut.

Was wir bewusst nicht getan haben: iptcembed() per disable_functions global sperren. In zwei Projekten wird die Funktion in einem Worker-Job aufgerufen, der von einer redaktionellen IPTC-Anreicherung lebt. Stattdessen läuft dieser Worker jetzt in einem rootless Container mit eigenem PHP-Build, der auf einem Sury-Patch-Snapshot von heute Vormittag basiert, und wir warten die offizielle Upstream-Korrektur ab. Diese Trennung von produktiven Web-Workloads ohne iptcembed und isolierten Asset-Workern mit kontrollierter Nutzung war der pragmatische Kompromiss zwischen Brand-Disziplin und Funktionserhalt.

Architektonisch sitzt unter dieser Episode eine größere Frage: PHP ist ein hervorragender Glue-Layer für CMS- und E-Commerce-Workloads, aber Bildverarbeitung auf C-Funktions-Ebene gehört nicht in den gleichen Prozess wie der Request-Handler. Wir verschieben sie schrittweise in nachgelagerte Worker mit minimalen Capabilities und sauberer Container-Sandbox. Das ist nicht die Antwort auf einen einzelnen CVE, sondern die Antwort auf eine Bug-Klasse, die wir alle paar Jahre erneut sehen werden.

Fazit

CVE-2025-14177 ist kein Notbruch, aber der Begleit-Bug in iptcembed() macht aus „nächste Wartung“ ein „diese Woche“. Wer auf TYPO3, Sylius oder einer Composer-getriebenen PHP-Plattform sitzt, hat heute drei Aufgaben (Patch ziehen, Upload-Pfad inventarisieren, iptcembed-Aufrufe identifizieren) und einen Beobachtungs-TODO für den ausstehenden zweiten Patch. Mehr ist es nicht. Aber weniger sollte es auch nicht sein, weil Information-Disclosure-Bugs im PHP-Heap die unangenehme Eigenschaft haben, in der NIS-2-Welt schnell zur Meldepflicht zu werden, sobald jemand sich die Frage stellt, was im FPM-Pool zum Zeitpunkt der Anfrage präsent war.

Die Frage lautet nicht, ob die getimagesize()-Codepfade je wieder einen Bug haben werden. Sie lautet, ob Ihre Upload-Pipeline so gebaut ist, dass der nächste Bug Sie nicht erneut auf dem falschen Fuß erwischt.

Dieser Beitrag spiegelt unsere technische Einschätzung. Er ersetzt keine Datenschutz-Folgenabschätzung und keine Rechtsberatung zu konkreten NIS-2-Meldepflichten.