Signal · Regulation & Trade
Kritische Sicherheitslücken in PHP - Updates verfügbar
What the source reported
Source-reported<p class="block">21. Oktober 2026</p> <h2 class="block">Beschreibung</h2> <p class="block">In PHP existieren zwei kritische Sicherheitslücken, deren Ausnutzung es nicht authentifizierten Angreifer:innen ermöglichen kann, aus der Ferne beliebigen Code auszuführen. Betroffen sind laut PHP-Projekt alle PHP-Installationen, die Web-Anfragen verarbeiten, darunter PHP-FPM, Apache mit <code>mod_php</code>, <code>php-cgi</code>, FrankenPHP und LiteSpeed.</p> <p class="block">Bei CVE-2026-109618 kann die Behandlung von Out-of-Memory-Zuständen (OOM) PHP unterbrechen, während interne Anfragedaten nur teilweise initialisiert sind. Beim anschließenden Beenden der Anfrage werden diese ungültigen Daten als gültig verarbeitet. Bei CVE-2026-109619 kann anfragebezogener interner Zustand bestehen bleiben, nachdem der zugehörige Speicher bereits freigegeben wurde (Use-after-free). Eine spätere Anfrage, die vom selben Worker-Prozess verarbeitet wird, kann diesen veralteten Zustand vor der regulären Initialisierung verwenden.</p> <p class="block">CVE-Nummer(n): CVE-2026-109618, CVE-2026-109619</p> <p class="block">CVSS v4.0 Base Score: 9.2</p> <h2 class="block">Auswirkungen</h2> <p class="block">Durch Ausnutzen der Schwachstellen können Angreifer:innen ohne Authentifizierung aus der Ferne beliebigen Code mit den Rechten des Benutzerkontos ausführen, unter dem der Webserver- bzw. PHP-Worker-Prozess läuft. CVE-2026-109619 ermöglicht zusätzlich das Auslesen von Speicherinhalten.</p> <p class="block">Das PHP-Projekt stuft das Risiko für Apache mit <code>mod_php</code> am höchsten ein: Für diese Konfiguration wurde eine Ausnutzung demonstriert, bei der eine nicht authentifizierte Anfrage den Angriff auslöst, bevor Anwendungscode ausgeführt wird. Für CVE-2026-109619 wurde die Codeausführung zusätzlich gegen PHP-FPM validiert. Angaben zu einer aktiven Ausnutzung macht das PHP-Projekt nicht.</p> <h2 class="block">Betroffene Systeme</h2> <ul> <li>PHP 8.5 vor Version 8.5.12</li> <li>PHP 8.4 vor Version 8.4.27</li> <li>PHP 8.3 vor Version 8.3.36</li> <li>PHP 8.2 vor Version 8.2.35</li> <li>PHP 8.1 und ältere Versionen (End of Life)</li> </ul> <h2 class="block">Abhilfe</h2> <p class="block">Das PHP-Projekt stellt mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 Updates bereit, welche die Schwachstellen beheben. Laut Hersteller ist ausschließlich ein Update eine vollständige Abhilfe. Linux-Distributionen und LTS-Anbieter haben die Patches vorab erhalten; aktualisierte Pakete sind über die jeweiligen Anbieter zu beziehen. Für das Repository <code>rpms.remirepo.net</code> sind laut PHP-Projekt am 21. Oktober 2026 keine Updates verfügbar. Betreiber:innen, die dieses Repository nutzen, wird empfohlen, auf Distributionspakete umzusteigen oder PHP aus dem Quellcode zu bauen.</p> <p class="block">PHP 8.1 und ältere Versionen erhalten keine Updates mehr vom PHP-Projekt. Einige Distributionen und LTS-Anbieter stellen zurückportierte Fixes bereit. Zusätzlich hat das PHP-Projekt minimale Quellcode-Backports für <a href="https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619">PHP 7.4</a>, <a href="https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619">PHP 8.0</a> und <a href="https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619">PHP 8.1</a> veröffentlicht. Ein Upgrade auf eine unterstützte Version wird empfohlen. PHP 8.2 erreicht am 31. Dezember 2026 das End of Life.</p> <p class="block">Falls ein sofortiges Update nicht möglich ist, reduzieren folgende Maßnahmen die Angriffsfläche für einzelne bekannte Angriffswege. Sie bieten jedoch keinen vollständigen Schutz:</p> <ul> <li>CVE-2026-109618: <code>memory_limit=-1</code> so setzen, dass Anwendungen den Wert nicht überschreiben können (z. B. per <code>php_admin_value</code> in der FPM-Pool- oder Apache-Konfiguration). Einen niedrigen Wert für <code>post_max_size</code> setzen (<code>8M</code> ohne Datei-Uploads, <code>32M</code> mit Datei-Uploads) und <code>upload_max_filesize</code> darunter halten. Zusätzlich können Begrenzungen auf Webserver- bzw. Proxy-Ebene (u. a. Anfragegröße, Anzahl der Eingabefelder, Multipart-Teile und Header) gesetzt werden. Container- oder cgroup-Speicherlimits können als Verfügbarkeitsgrenze dienen; <code>RLIMIT_AS</code> und <code>RLIMIT_DATA</code> sollten nicht verwendet werden, da diese die verwundbare Speicherallokation auslösen können.</li> <li>CVE-2026-109619: <code>session.upload_progress.enabled=0</code> in <code>php.ini</code>, in der FPM-Pool- oder Serverkonfiguration setzen (nicht über <code>ini_set()</code> oder <code>.user.ini</code>) und alle Worker-Prozesse neu starten. Unter PHP 8.5 zusätzlich <code>fatal_error_backtraces=0</code> setzen und alle Worker-Prozesse neu starten. Ungültige oder veraltete INI-Einstellungen, die pro Anfrage angewendet werden und vor der Initialisierung Diagnosemeldungen erzeugen, sollten entfernt werden. Das Unterdrücken dieser Meldungen über <code>error_reporting</code>, <code>display_errors</code> oder <code>@</code> ist nicht ausreichend. Weiters sollten von außen auslösbare Fatal Errors und Ausführungs-Timeouts behoben werden.</li> </ul> <h2 class="block">Hinweis</h2> <p class="block">Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelmäßige Neustarts stellen sicher, dass diese auch zeitnah aktiviert werden.</p> <hr /> <h2 class="block">Informationsquelle(n):</h2> <p class="block"><em>Security advisory: Critical remote code execution vulnerabilities, update now (Englisch)<br /><a href="https://www.php.net/index.php#2026-10-21-5">https://www.php.net/index.php#2026-10-21-5</a></em></p> <p class="block"><em>GitHub Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (Englisch)<br /><a href="https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w">https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w</a></em></p> <p class="block"><em>GitHub Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (Englisch)<br /><a href="https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp">https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp</a></em></p>
- Publication
- CERT.at security warnings RSS · Government/Regulator
- Published
- 21st October 2026
- Original report
- cert.at
ProcIntel stores what the source published in its feed — a headline, a summary and a link. It does not store or reproduce the full article.
What ProcIntel recorded
ProcIntel-derived- Category
- Regulation & Trade
- Geography
- Austria
- Organisations
- None identified
- Collected
- 21st October 2026 · 17:48
Initial assessment ProcIntel's automatic, provisional read of this individual Signal -- Initial Significance and Initial Confidence, computed deterministically before any Event extraction or human review.
A provisional, automatically computed reading of this individual Signal, before Event extraction or human review. Not a final rating.
Initial Significance Low (15.0/100). Strongest contributor: Procurement Impact (6.0/30 points). Limiting factor: Impact-Scale Specificity (0.0/10 points). Initial Confidence Low (39/100, data sufficiency: Insufficient). Strongest contributor: Source Authority (40.0/40 points). Limiting factor: Specificity (0.0/20 points). Capped at 39 (Low) -- insufficient structured evidence to support a higher Confidence reading, regardless of source authority.
- Strongest contributor
- Procurement Impact
- Limiting factor
- Impact-Scale Specificity