Zwei schwer­wie­gen­de Sicher­heits­lü­cken in der Pro­gram­mier­spra­che PHP set­zen der­zeit Web­sei­ten unter Druck. Unter dem Namen „PHP2Shell“ wer­den Schwach­stel­len zusam­men­ge­fasst, über die Angrei­fer unter bestimm­ten Vor­aus­set­zun­gen ohne Anmel­dung Schad­code auf einem Web­ser­ver aus­füh­ren oder ver­trau­li­che Daten aus­le­sen kön­nen. Sicher­heits­up­dates sind seit dem 21. Okto­ber 2026 ver­füg­bar. Fach­leu­te raten, die­se unver­züg­lich ein­zu­spie­len. Stand der Recher­che: 22. Okto­ber 2026.

Was hin­ter PHP2Shell steckt

PHP arbei­tet im Hin­ter­grund vie­ler Inter­net­an­ge­bo­te. Ver­brei­te­te Sys­te­me wie Word­Press, Joom­la und Drup­al nut­zen die­se Tech­nik. Die jetzt bekannt gewor­de­nen Schwach­stel­len betref­fen jedoch nicht ein ein­zel­nes Plug­in oder ein bestimm­tes Redak­ti­ons­sys­tem, son­dern die PHP-Lauf­zeit­um­ge­bung selbst.

Die bei­den Lücken tra­gen die Ken­nun­gen CVE-2026–109618 und CVE-2026–109619. Das PHP-Pro­jekt bewer­tet sie mit jeweils 9,2 von zehn Punk­ten auf der Schwe­re­grad­ska­la CVSS 4.0 als kritisch.

Ver­ein­facht gesagt ent­ste­hen die Pro­ble­me beim Umgang mit Spei­cher und bei schwer­wie­gen­den Feh­lern wäh­rend der Ver­ar­bei­tung von Web­an­fra­gen. Inter­ne Daten kön­nen dabei unvoll­stän­dig initia­li­siert blei­ben, oder es blei­ben Ver­wei­se auf bereits frei­ge­ge­be­nen Spei­cher erhal­ten. Angrei­fer kön­nen sol­che Zustän­de mit prä­pa­rier­ten Anfra­gen aus­nut­zen. Mög­li­che Fol­gen sind die Aus­füh­rung frem­den Pro­gramm­codes, der Zugriff auf sen­si­ble Infor­ma­tio­nen oder der Aus­fall von Diens­ten. Wel­che Angriffs­mög­lich­kei­ten tat­säch­lich bestehen, hängt unter ande­rem von der ein­ge­setz­ten PHP-Ver­si­on und der Ser­ver­um­ge­bung ab.

Wel­che Web­sei­ten betrof­fen sein können

Nach Anga­ben des PHP-Sicher­heits­teams müs­sen grund­sätz­lich alle PHP-Instal­la­tio­nen geprüft wer­den, die Web­an­fra­gen bedie­nen. Dazu gehö­ren unter ande­rem PHP-FPM, Apa­che mit mod_php, php-cgi, Fran­ken­PHP und LiteSpeed.

Das höchs­te Risi­ko sieht das PHP-Team bei Apa­che mit mod_php. Hier wur­de ein Angriff nach­ge­wie­sen, der bereits vor der Aus­füh­rung des eigent­li­chen Anwen­dungs­codes anset­zen kann. Auch sorg­fäl­tig pro­gram­mier­te Web­sei­ten sind damit nicht auto­ma­tisch geschützt.

Sicher­heits­for­scher von Wiz haben Angrif­fe auf Test­in­stal­la­tio­nen von Word­Press, Drup­al und Joom­la gezeigt. Die­se Bei­spie­le bele­gen mög­li­che Aus­wir­kun­gen. Sie bedeu­ten nicht, dass jede Instal­la­ti­on die­ser Sys­te­me bereits erfolg­reich ange­grif­fen wurde.

Berei­nig­te Ver­sio­nen und der Stand bei älte­ren Systemen

Am 21. Okto­ber 2026 hat das PHP-Pro­jekt berei­nig­te Ver­sio­nen ver­öf­fent­licht: PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 und PHP 8.5.12.

Für älte­re Instal­la­tio­nen ist beson­de­re Auf­merk­sam­keit nötig. PHP 8.1 und älte­re Ver­si­ons­rei­hen erhal­ten vom PHP-Pro­jekt kei­ne regu­lä­ren Updates mehr. Ein­zel­ne Dis­tri­bu­to­ren oder Anbie­ter mit Lang­zeit­un­ter­stüt­zung kön­nen eige­ne Sicher­heits­kor­rek­tu­ren bereit­stel­len. Das PHP-Sicher­heits­team hat außer­dem Quell­code­kor­rek­tu­ren für die älte­ren Rei­hen 7.4, 8.0 und 8.1 veröffentlicht.

Ent­schei­dend ist des­halb nicht allein die ange­zeig­te Ver­si­ons­num­mer, son­dern ob der zustän­di­ge Anbie­ter die Feh­ler in sei­nem Paket bereits beho­ben hat.

Dass die Gefahr nicht nur theo­re­tisch besteht, zeigt ein Bericht von Cloud­fla­re. Das Unter­neh­men hat nach eige­nen Anga­ben Angriffs­ver­kehr gegen sei­ne Kun­den beob­ach­tet. Dabei hät­ten Angrei­fer ihre Anfra­gen ver­än­dert, um Schutz­re­geln zu umge­hen. Sol­che Beob­ach­tun­gen sind von einem bestä­tig­ten erfolg­rei­chen Ein­bruch in einen kon­kre­ten Ser­ver zu unterscheiden.

Was Betrei­ber jetzt tun sollten

Die wich­tigs­te Emp­feh­lung des PHP-Sicher­heits­teams ist ein­deu­tig: Nur ein Update behebt die Schwach­stel­len voll­stän­dig. Ein Update des Redak­ti­ons­sys­tems oder sei­ner Erwei­te­run­gen allein reicht nicht. Aktua­li­siert wer­den muss die dar­un­ter­lie­gen­de PHP-Umge­bung. Bei betreu­ten Hos­ting­pa­ke­ten ist dafür übli­cher­wei­se der Hos­tin­g­an­bie­ter zuständig.

Mal­ware­bytes emp­fiehlt Web­sei­ten­be­trei­bern aus­drück­lich, beim Hos­ting- oder IT-Dienst­leis­ter nach­zu­fra­gen, ob die Sicher­heits­kor­rek­tu­ren bereits instal­liert und nicht ledig­lich ein­ge­plant sind. Auch älte­re Web­sei­ten und wei­te­re Anwen­dun­gen soll­ten dabei berück­sich­tigt werden.

Für Ver­ei­ne, Unter­neh­men und ande­re Sei­ten­be­trei­ber in Emden und der Regi­on erge­ben sich dar­aus fünf kon­kre­te Schrit­te. Zuerst soll­te geprüft wer­den, wel­che Web­sei­ten, Anwen­dun­gen und Gerä­te mit Web­ober­flä­che PHP ver­wen­den. Danach müs­sen die pas­sen­den Sicher­heits­kor­rek­tu­ren des PHP-Pro­jekts oder des jewei­li­gen Anbie­ters unver­züg­lich ein­ge­spielt wer­den. Nach dem Update sind die betrof­fe­nen Web­ser­ver- und PHP-Pro­zes­se neu zu star­ten, damit die kor­ri­gier­te Soft­ware tat­säch­lich arbei­tet. Bei nicht mehr unter­stütz­ten Sys­te­men ist zu klä­ren, ob ein Anbie­ter noch ver­läss­li­che Sicher­heits­up­dates lie­fert, oder ob eine Umstel­lung ansteht. Zusätz­lich lohnt ein Blick in die Pro­to­kol­le: unge­wöhn­li­che Anfra­gen, gehäuf­te Spei­cher­feh­ler, wie­der­hol­te Ser­ver­feh­ler oder uner­klär­li­che Neu­starts von PHP-Pro­zes­sen sind mög­li­che Warn­si­gna­le, für sich genom­men aber kein Beweis für einen Angriff.

Fire­wall-Regeln erset­zen das Update nicht

Cloud­fla­re hat Schutz­re­geln für sei­ne Web Appli­ca­ti­on Fire­wall bereit­ge­stellt. Das Unter­neh­men betont selbst, dass die­se nur eine zusätz­li­che Schutz­schicht sind und das PHP-Update nicht erset­zen. Auch die vom PHP-Pro­jekt beschrie­be­nen vor­über­ge­hen­den Kon­fi­gu­ra­ti­ons­maß­nah­men ver­rin­gern ledig­lich ein­zel­ne Angriffs­mög­lich­kei­ten. Sie machen eine ver­wund­ba­re Instal­la­ti­on nicht voll­stän­dig sicher. Sol­che Ein­grif­fe soll­ten Admi­nis­tra­to­ren anhand der offi­zi­el­len Hin­wei­se vornehmen.

Die US-Sicher­heits­be­hör­de NSA emp­fiehlt, betrof­fe­ne Sys­te­me vor­über­ge­hend off­line zu neh­men, wenn eine sofor­ti­ge Aktua­li­sie­rung nicht mög­lich ist, bis ein aus­rei­chen­der Schutz her­ge­stellt wer­den kann. Außer­dem rät sie zu einer Bestands­auf­nah­me und ver­stärk­ter Protokollierung.

Was das für Besu­cher von Web­sei­ten bedeutet

Für gewöhn­li­che Inter­net­nut­zer sind die nöti­gen PHP-Updates auf den betrof­fe­nen Ser­vern vor­zu­neh­men, nicht auf dem eige­nen Smart­phone oder Com­pu­ter. Eine vor­über­ge­hen­de War­tungs­sei­te ist außer­dem kein auto­ma­ti­scher Hin­weis auf einen erfolg­rei­chen Angriff. Sie kann eine Vor­sichts­maß­nah­me sein, wäh­rend Betrei­ber ihre Sys­te­me aktualisieren.

Mal­ware­bytes rät den­noch zur Auf­merk­sam­keit. Uner­war­te­te Wei­ter­lei­tun­gen, unge­wöhn­li­che Down­loads oder wie­der­hol­te Anmel­de­auf­for­de­run­gen soll­ten auch auf bekann­ten Web­sei­ten kri­tisch geprüft werden.

Für Web­sei­ten­be­trei­ber besteht unmit­tel­ba­rer Hand­lungs­be­darf. Wer die eige­ne Inter­net­sei­te nicht selbst tech­nisch betreut, soll­te jetzt beim zustän­di­gen Dienst­leis­ter nach­fra­gen und sich die erfolg­te Absi­che­rung der PHP-Umge­bung bestä­ti­gen lassen.

Das Wich­tigs­te auf einen Blick

• Schwach­stel­len: CVE-2026–109618 und CVE-2026–109619, jeweils mit 9,2 von 10 Punk­ten (CVSS 4.0) als kri­tisch bewertet
• Berei­nig­te Ver­sio­nen seit 21. Okto­ber 2026: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12
• Beson­ders betrof­fen: Web­ser­ver-Betriebs­ar­ten wie PHP-FPM, Apa­che mit mod_php, php-cgi, Fran­ken­PHP und Lite­Speed; höchs­tes Risi­ko bei Apa­che mit mod_php
• Wich­tigs­ter Schritt: PHP-Umge­bung aktua­li­sie­ren und die Pro­zes­se neu star­ten, nicht nur Word­Press oder Plugins
• Älte­re Sys­te­me: PHP 8.1 und älter ohne regu­lä­re Updates des PHP-Pro­jekts; Quell­code­kor­rek­tu­ren lie­gen für 7.4, 8.0 und 8.1 vor

Ver­wen­de­te Quellen

1. PHP-Pro­jekt: Offi­zi­el­le Sicher­heits­war­nung und Upda­te­hin­wei­se vom 21. Okto­ber 2026 – Schwach­stel­len, betrof­fe­ne Betriebs­ar­ten, berei­nig­te Ver­sio­nen und Gren­zen vor­über­ge­hen­der Schutzmaßnahmen.
2. Wiz Rese­arch: PHP2Shell: AI unco­vers cri­ti­cal RCE vul­nerabi­li­ties – tech­ni­sche Hin­ter­grün­de, Angriffs­nach­wei­se in Test­um­ge­bun­gen und Hin­wei­se zur Unter­su­chung auf­fäl­li­ger Aktivitäten.
3. Cloud­fla­re: Cloud­fla­re deploys pro­tec­tions against php2shell vul­nerabi­li­ty – beob­ach­te­ter Angriffs­ver­kehr und ergän­zen­de Firewall-Schutzmaßnahmen.
4. Natio­nal Secu­ri­ty Agen­cy: Cri­ti­cal Patches Recom­men­ded for PHP Vul­nerabi­li­ties – Emp­feh­lun­gen zu Bestands­auf­nah­me, Updates, Pro­to­kol­lie­rung und vor­über­ge­hen­der Abschaltung.
5. Mal­ware­bytes Labs: PHP2Shell: Why web­sites are going off­line for emer­gen­cy secu­ri­ty updates – Hand­lungs­emp­feh­lun­gen für Web­sei­ten­be­trei­ber und Besucher.

— Redak­ti­on: Lese­r­ECHO Emden