← Signals

Signal · Regulation & Trade

Kritische Sicherheitslücken in PHP - Updates verfügbar

CERT.at security warnings RSS Authoritative source Published 21st October 2026 Austria

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&uuml;cken, deren Ausnutzung es nicht authentifizierten Angreifer:innen erm&ouml;glichen kann, aus der Ferne beliebigen Code auszuf&uuml;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&auml;nden (OOM) PHP unterbrechen, w&auml;hrend interne Anfragedaten nur teilweise initialisiert sind. Beim anschlie&szlig;enden Beenden der Anfrage werden diese ung&uuml;ltigen Daten als g&uuml;ltig verarbeitet. Bei CVE-2026-109619 kann anfragebezogener interner Zustand bestehen bleiben, nachdem der zugeh&ouml;rige Speicher bereits freigegeben wurde (Use-after-free). Eine sp&auml;tere Anfrage, die vom selben Worker-Prozess verarbeitet wird, kann diesen veralteten Zustand vor der regul&auml;ren Initialisierung verwenden.</p> <p class="block">CVE-Nummer(n):&nbsp;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&ouml;nnen Angreifer:innen ohne Authentifizierung aus der Ferne beliebigen Code mit den Rechten des Benutzerkontos ausf&uuml;hren, unter dem der Webserver- bzw. PHP-Worker-Prozess l&auml;uft. CVE-2026-109619 erm&ouml;glicht zus&auml;tzlich das Auslesen von Speicherinhalten.</p> <p class="block">Das PHP-Projekt stuft das Risiko f&uuml;r Apache mit <code>mod_php</code> am h&ouml;chsten ein: F&uuml;r diese Konfiguration wurde eine Ausnutzung demonstriert, bei der eine nicht authentifizierte Anfrage den Angriff ausl&ouml;st, bevor Anwendungscode ausgef&uuml;hrt wird. F&uuml;r CVE-2026-109619 wurde die Codeausf&uuml;hrung zus&auml;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 &auml;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&szlig;lich ein Update eine vollst&auml;ndige Abhilfe. Linux-Distributionen und LTS-Anbieter haben die Patches vorab erhalten; aktualisierte Pakete sind &uuml;ber die jeweiligen Anbieter zu beziehen. F&uuml;r das Repository <code>rpms.remirepo.net</code> sind laut PHP-Projekt am 21. Oktober 2026 keine Updates verf&uuml;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 &auml;ltere Versionen erhalten keine Updates mehr vom PHP-Projekt. Einige Distributionen und LTS-Anbieter stellen zur&uuml;ckportierte Fixes bereit. Zus&auml;tzlich hat das PHP-Projekt minimale Quellcode-Backports f&uuml;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&ouml;ffentlicht. Ein Upgrade auf eine unterst&uuml;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&ouml;glich ist, reduzieren folgende Ma&szlig;nahmen die Angriffsfl&auml;che f&uuml;r einzelne bekannte Angriffswege. Sie bieten jedoch keinen vollst&auml;ndigen Schutz:</p> <ul> <li>CVE-2026-109618: <code>memory_limit=-1</code> so setzen, dass Anwendungen den Wert nicht &uuml;berschreiben k&ouml;nnen (z.&nbsp;B. per <code>php_admin_value</code> in der FPM-Pool- oder Apache-Konfiguration). Einen niedrigen Wert f&uuml;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&auml;tzlich k&ouml;nnen Begrenzungen auf Webserver- bzw. Proxy-Ebene (u.&nbsp;a. Anfragegr&ouml;&szlig;e, Anzahl der Eingabefelder, Multipart-Teile und Header) gesetzt werden. Container- oder cgroup-Speicherlimits k&ouml;nnen als Verf&uuml;gbarkeitsgrenze dienen; <code>RLIMIT_AS</code> und <code>RLIMIT_DATA</code> sollten nicht verwendet werden, da diese die verwundbare Speicherallokation ausl&ouml;sen k&ouml;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 &uuml;ber <code>ini_set()</code> oder <code>.user.ini</code>) und alle Worker-Prozesse neu starten. Unter PHP 8.5 zus&auml;tzlich <code>fatal_error_backtraces=0</code> setzen und alle Worker-Prozesse neu starten. Ung&uuml;ltige oder veraltete INI-Einstellungen, die pro Anfrage angewendet werden und vor der Initialisierung Diagnosemeldungen erzeugen, sollten entfernt werden. Das Unterdr&uuml;cken dieser Meldungen &uuml;ber <code>error_reporting</code>, <code>display_errors</code> oder <code>@</code> ist nicht ausreichend. Weiters sollten von au&szlig;en ausl&ouml;sbare Fatal Errors und Ausf&uuml;hrungs-Timeouts behoben werden.</li> </ul> <h2 class="block">Hinweis</h2> <p class="block">Generell empfiehlt CERT.at, s&auml;mtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelm&auml;&szlig;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.

Significance 1 · Low
Confidence 2 · Low

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