Zwei kri­ti­sche Sicher­heits­lü­cken in PHP gefähr­den auch Word­Press-Web­sites: CVE-2026–109618 und CVE-2026–109619 kön­nen unter bestimm­ten Vor­aus­set­zun­gen die Aus­füh­rung von Schad­code ohne Anmel­dung ermög­li­chen.
Am 21. Okto­ber 2026 ver­öf­fent­lich­te das PHP-Pro­jekt außer­plan­mä­ßi­ge Sicher­heits­up­dates. Bei­de Schwach­stel­len wer­den nach CVSS v4.0 mit 9,2 von 10 bewer­tet.

Das Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (BSI) stuft die Bedro­hung mit Kri­ti­k­ali­tät 3 / Oran­ge ein und for­dert unver­züg­li­che Maß­nah­men. Die euro­päi­sche Sicher­heits­stel­le CERT-EU warnt eben­falls vor den Schwach­stel­len, die in der Sicher­heits­be­richt­erstat­tung unter dem Namen PHP2Shell bekannt gewor­den sind.

Beson­ders wich­tig: Die Schwach­stel­len lie­gen nicht im Word­Press Core, son­dern in der zugrun­de lie­gen­den PHP-Lauf­zeit­um­ge­bung. Selbst eine voll­stän­dig aktua­li­sier­te Word­Press-Web­site kann des­halb ver­wund­bar blei­ben.

Wel­che PHP-Ver­sio­nen sind betrof­fen, wie bewer­ten BSI und CERT-EU die Gefähr­dung, was haben die Word­fence-Tests erge­ben und wel­che Maß­nah­men soll­ten Unter­neh­men und Web­site-Betrei­ber jetzt ergrei­fen?

Was ist pas­siert? Zwei kri­ti­sche PHP-Sicher­heits­lü­cken im Okto­ber 2026

Am 20. Okto­ber 2026 kün­dig­te das PHP-Pro­jekt außer­plan­mä­ßi­ge Sicher­heits­up­dates an. Die Ver­öf­fent­li­chung erfolg­te am 21. Okto­ber 2026. Hin­ter­grund waren zwei kri­ti­sche Schwach­stel­len, die unter bestimm­ten Bedin­gun­gen eine Aus­füh­rung von Pro­gramm­code auf betrof­fe­nen Ser­vern ermög­li­chen kön­nen.

Die Schwach­stel­len betref­fen grund­le­gen­de Funk­tio­nen der PHP-Lauf­zeit­um­ge­bung. Dadurch ist die mög­li­che Angriffs­flä­che erheb­lich grö­ßer als bei einer Sicher­heits­lü­cke in einem ein­zel­nen Word­Press-Plug­in.

Das BSI weist aus­drück­lich dar­auf hin, dass PHP nicht nur in klas­si­schen Web­sites ein­ge­setzt wird. Auch Con­tent-Manage­ment-Sys­te­me, Online­shops, Kol­la­bo­ra­ti­ons­lö­sun­gen und ein­zel­ne Kom­po­nen­ten ande­rer IT-Pro­duk­te kön­nen PHP ver­wen­den.

Wel­che PHP-Ver­sio­nen schlie­ßen die Sicher­heits­lü­cken?

Wich­tig: Die Ver­si­ons­num­mer allein reicht nicht immer aus, um den Sicher­heits­sta­tus zu bestim­men. Linux-Dis­tri­bu­tio­nen, LTS-Anbie­ter und Her­stel­ler kön­nen Sicher­heits­kor­rek­tu­ren in älte­re Paket­ver­sio­nen zurück­por­tie­ren. Maß­geb­lich ist des­halb auch die kon­kre­te Paket­re­vi­si­on und das zuge­hö­ri­ge Secu­ri­ty Advi­so­ry.

Was bedeu­ten CVE-2026–109618 und CVE-2026–109619?

CVE-2026–109618: Spei­cher­feh­ler bei Out-of-Memo­ry-Situa­tio­nen

Die­se Schwach­stel­le betrifft die inter­ne Spei­cher­ver­wal­tung von PHP. Unter bestimm­ten Bedin­gun­gen kann eine fehl­ge­schla­ge­ne Spei­cher­zu­wei­sung dazu füh­ren, dass inter­ne Daten­struk­tu­ren nicht voll­stän­dig initia­li­siert wer­den.

Bei der anschlie­ßen­den Berei­ni­gung kön­nen dadurch ungül­ti­ge Spei­cher­zu­stän­de ver­ar­bei­tet wer­den. Eine sol­che Spei­cher­kor­rup­ti­on kann unter geeig­ne­ten Vor­aus­set­zun­gen für die Aus­füh­rung von Schad­code aus­ge­nutzt wer­den.

CVE-2026–109619: Ver­al­te­ter glo­ba­ler Zustand zwi­schen Anfra­gen

Die zwei­te Schwach­stel­le betrifft inter­nen Zustand, der nach der Ver­ar­bei­tung einer Anfra­ge unter bestimm­ten Bedin­gun­gen bestehen blei­ben kann, obwohl zuge­hö­ri­ger Spei­cher bereits frei­ge­ge­ben wur­de.

Spä­te­re Anfra­gen kön­nen dadurch auf ungül­ti­ge Spei­cher­be­rei­che zugrei­fen. Auch hier besteht unter ent­spre­chen­den Vor­aus­set­zun­gen das Risi­ko einer Remo­te Code Exe­cu­ti­on.

Bei­de Sicher­heits­pro­ble­me lie­gen in PHP selbst. Ihre kon­kre­te Aus­nutz­bar­keit hängt unter ande­rem von der Ser­ver­kon­fi­gu­ra­ti­on, dem PHP-Build und der jewei­li­gen Betriebs­art ab.

BSI warnt vor PHP2Shell: Kri­ti­k­ali­tät 3 / Oran­ge

Das Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (BSI) ver­öf­fent­lich­te am 21. Okto­ber 2026 den IT-Sicher­heits­hin­weis BITS‑H Nr. 2026−297981−1132. Die aus­ge­wer­te­te Fas­sung trägt die Ver­si­ons­num­mer 1.1.

Das BSI stuft die Bedro­hung mit Kri­ti­k­ali­tät 3 / Oran­ge ein. Nach der BSI-Klas­si­fi­ka­ti­on bedeu­tet dies, dass Maß­nah­men unver­züg­lich ergrif­fen wer­den müs­sen und mas­si­ve Beein­träch­ti­gun­gen des Regel­be­triebs mög­lich sind.

Die Schwach­stel­len wer­den in der Sicher­heits­be­richt­erstat­tung auch als PHP2Shell bezeich­net. Die­se Bezeich­nung soll die mög­li­che Trag­wei­te der Pro­ble­me ver­deut­li­chen.

Nach Anga­ben des BSI sind ver­wund­ba­re PHP-Ver­sio­nen bis min­des­tens PHP 5 bekannt. Beson­ders kri­tisch ist, dass eine Aus­nut­zung unter bestimm­ten Vor­aus­set­zun­gen weder eine Anmel­dung noch eine Inter­ak­ti­on durch Benut­zer erfor­dert.

Wie bewer­tet das BSI die aktu­el­le Angriffs­la­ge?

Das BSI geht auf­grund der ver­öf­fent­lich­ten tech­ni­schen Details von einer kurz­fris­ti­gen Aus­nut­zung ver­wund­ba­rer Sys­te­me aus. Bereits kurz nach Bekannt­wer­den der Schwach­stel­len wur­den tech­ni­sche Infor­ma­tio­nen und mög­li­che Angriffs­me­tho­den öffent­lich dis­ku­tiert.

Im Sicher­heits­hin­weis vom 21. Okto­ber 2026 waren dem BSI aller­dings noch kei­ne bestä­tig­ten erfolg­rei­chen Angrif­fe bekannt. Es berich­te­te über unbe­stä­tig­te Mel­dun­gen zu ers­ten Angriffs­ver­su­chen.

Die­se Unter­schei­dung ist wich­tig: Eine hohe Wahr­schein­lich­keit zukünf­ti­ger Angrif­fe bedeu­tet nicht, dass bereits jede gefähr­de­te Web­site kom­pro­mit­tiert wur­de.

CERT-EU: Kri­ti­sche PHP-Schwach­stel­len betref­fen zahl­rei­che Ser­ver­kon­fi­gu­ra­tio­nen

Auch CERT-EU ver­öf­fent­lich­te am 21. Okto­ber 2026 eine Sicher­heits­war­nung unter der Ken­nung 2026-018.

Die euro­päi­sche Sicher­heits­stel­le ver­weist auf die bei­den kri­ti­schen Schwach­stel­len und emp­fiehlt die unver­züg­li­che Instal­la­ti­on der bereit­ge­stell­ten Sicher­heits­kor­rek­tu­ren.

Die War­nung betrifft nicht nur eine ein­zel­ne PHP-Kon­fi­gu­ra­ti­on. Ver­schie­de­ne Mög­lich­kei­ten, PHP auf Web­ser­vern zu betrei­ben, müs­sen berück­sich­tigt wer­den.

Wel­che PHP-Betriebs­ar­ten sind betrof­fen?

Das BSI hebt ins­be­son­de­re Apa­che mit mod_php her­vor. Hier wur­de ein Angriffs­weg demons­triert, bei dem eine nicht authen­ti­fi­zier­te Anfra­ge den Feh­ler aus­lö­sen kann, bevor Anwen­dungs­code aus­ge­führt wird.

Eine Sicher­heits­funk­ti­on inner­halb von Word­Press kann einen sol­chen Angriff des­halb nicht zuver­läs­sig ver­hin­dern.

Was haben die Word­fence-Tests gezeigt?

Word­fence unter­such­te die bei­den Sicher­heits­lü­cken in ver­schie­de­nen PHP- und Word­Press-Test­um­ge­bun­gen.

Bei CVE-2026–109619 konn­te Word­fence in einer spe­zi­ell kon­fi­gu­rier­ten Test­um­ge­bung mit PHP 8.5.11 eine Code­aus­füh­rung demons­trie­ren. Ein ver­gleich­ba­rer Test auf einem nor­mal opti­mier­ten Build führ­te dage­gen zu einem Absturz.

Die kor­ri­gier­te PHP-Ver­si­on 8.5.12 blieb bei dem beschrie­be­nen Test sta­bil.

Bei CVE-2026–109618 beob­ach­te­te Word­fence in ver­wund­ba­ren Test­um­ge­bun­gen Feh­ler bezie­hungs­wei­se Abstür­ze. Eine erfolg­rei­che Code­aus­füh­rung wur­de für die­se Schwach­stel­le in den beschrie­be­nen Tests nicht bestä­tigt.

Aus den Test­ergeb­nis­sen lässt sich kei­ne all­ge­mei­ne Ent­war­nung ablei­ten. Unter­schied­li­che PHP-Builds und Ser­ver­kon­fi­gu­ra­tio­nen kön­nen zu unter­schied­li­chen Ergeb­nis­sen füh­ren.

War­um reicht ein Word­Press-Update nicht aus?

Word­Press wird mit PHP aus­ge­führt. Der Word­Press Core, Plug­ins und The­mes sind dabei von der PHP-Lauf­zeit­um­ge­bung zu unter­schei­den.

Wird eine Schwach­stel­le in PHP selbst ent­deckt, muss die zugrun­de lie­gen­de Lauf­zeit­um­ge­bung aktua­li­siert wer­den. Ein Update von Word­Press oder einem Sicher­heits­plug­in kor­ri­giert die­se Kom­po­nen­te nicht.

Das BSI stellt des­halb aus­drück­lich klar, dass ein Update der PHP-Anwen­dung allein nicht aus­reicht.

Dies gilt eben­so für ande­re PHP-basier­te Sys­te­me wie Drup­al, TYPO3, Joom­la, Magen­to oder Next­cloud.

Was emp­fiehlt das BSI, wenn noch kein PHP-Sicher­heits­up­date ver­füg­bar ist?

Das BSI emp­fiehlt, gefähr­de­te PHP-Sys­te­me unver­züg­lich zu aktua­li­sie­ren. Kön­nen Sicher­heits­up­dates nicht kurz­fris­tig instal­liert wer­den, soll­te eine vor­über­ge­hen­de Tren­nung vom Inter­net erwo­gen wer­den.

Web Appli­ca­ti­on Fire­walls und ande­re tech­ni­sche Maß­nah­men kön­nen bekann­te Angriffs­pfa­de erschwe­ren. Nach der BSI-Bewer­tung bie­ten sie jedoch kei­nen voll­stän­di­gen Schutz.

Eine gewöhn­li­che War­tungs­sei­te inner­halb der wei­ter­hin lau­fen­den PHP-Anwen­dung ist nicht mit einer tat­säch­li­chen Tren­nung des Sys­tems vom Inter­net gleich­zu­set­zen.

Wel­che vor­über­ge­hen­den PHP-Work­arounds nennt das BSI?

Das BSI beschreibt in sei­nem Sicher­heits­hin­weis meh­re­re tech­ni­sche Maß­nah­men, die die Angriffs­flä­che vor­über­ge­hend redu­zie­ren kön­nen. Sie rich­ten sich an erfah­re­ne Ser­ver­ad­mi­nis­tra­to­ren.

Wich­tig: Die nach­fol­gen­den Maß­nah­men sind kein Ersatz für Sicher­heits­up­dates. Ände­run­gen an der PHP-Kon­fi­gu­ra­ti­on kön­nen außer­dem die Funk­ti­ons­fä­hig­keit und Sta­bi­li­tät von Anwen­dun­gen beein­flus­sen.

Über­gangs­maß­nah­men für CVE-2026–109618

• Spei­cher­li­mit: Das BSI nennt memory_limit=-1, mög­lichst in einer Kon­fi­gu­ra­ti­on, die Anwen­dun­gen nicht über­schrei­ben kön­nen. Dabei müs­sen mög­li­che Aus­wir­kun­gen auf den Spei­cher­ver­brauch berück­sich­tigt wer­den.
• POST-Anfra­gen begren­zen: Als Bei­spie­le nennt das BSI post_max_size=8M für Anwen­dun­gen ohne Datei-Uploads und post_max_size=32M, wenn Uploads erfor­der­lich sind.
• Upload-Gren­zen: upload_max_filesize soll unter­halb von post_max_size lie­gen.
• Wei­te­re Anfra­ge­be­gren­zun­gen: Anzahl von Ein­ga­be­fel­dern, Mul­ti­part-Tei­len, Hea­dern und Ver­schach­te­lungs­tie­fe kön­nen zusätz­lich beschränkt wer­den.
• Con­tai­ner- und cgroup-Limits: Das BSI emp­fiehlt, geeig­ne­te Begren­zun­gen zur Sicher­stel­lung der Ver­füg­bar­keit zu prü­fen.

Das BSI weist dar­auf hin, dass RLIMIT_AS und RLIMIT_DATA nicht als gleich­wer­ti­ger Ersatz ver­wen­det wer­den soll­ten.

Über­gangs­maß­nah­men für CVE-2026–109619

• Upload-Fort­schritt für Ses­si­ons: session.upload_progress.enabled=0 set­zen und PHP-Worker neu star­ten.
• PHP 8.5: fatal_error_backtraces=0 set­zen und anschlie­ßend die Worker neu star­ten.
• Ver­al­te­te Kon­fi­gu­ra­tio­nen: Ungül­ti­ge oder über­hol­te Ein­stel­lun­gen ent­fer­nen, die vor der Ver­ar­bei­tung von Anfra­gen Dia­gno­se­mel­dun­gen aus­lö­sen.
• Feh­ler­be­hand­lung: Durch exter­ne Anfra­gen aus­lös­ba­re fata­le Feh­ler und Zeit­über­schrei­tun­gen mög­lichst besei­ti­gen.

Das BSI betont, dass ein­zel­ne Ein­stel­lun­gen ledig­lich bestimm­te bekann­te Angriffs­pfa­de erschwe­ren. Auch die Kom­bi­na­ti­on die­ser Maß­nah­men bie­tet kei­nen garan­tier­ten voll­stän­di­gen Schutz.

War­um sind Web Appli­ca­ti­on Fire­walls allein nicht aus­rei­chend?

Web Appli­ca­ti­on Fire­walls (WAF) kön­nen HTTP-Anfra­gen prü­fen und bekann­te Angriffs­mus­ter blo­ckie­ren.

Nach Anga­ben des BSI haben unter ande­rem WAF-Anbie­ter Regeln gegen bis­lang bekann­te Angriffs­pfa­de ver­öf­fent­licht.

Eine WAF kann jedoch nicht gewähr­leis­ten, dass sämt­li­che Vari­an­ten eines Angriffs auf die PHP-Lauf­zeit­um­ge­bung erkannt wer­den.

Das BSI betrach­tet des­halb das Patchen oder die Tren­nung gefähr­de­ter Sys­te­me vom Inter­net als die ent­schei­den­den Schutz­maß­nah­men.

Was müs­sen Unter­neh­men mit Plesk und Mana­ged Hos­ting beach­ten?

Die Ver­öf­fent­li­chung einer kor­ri­gier­ten PHP-Ver­si­on durch das PHP-Pro­jekt bedeu­tet nicht auto­ma­tisch, dass die pas­sen­de Instal­la­ti­ons­da­tei bereits auf jedem Ser­ver ver­füg­bar ist.

Vie­le Hos­ting-Umge­bun­gen ver­wen­den Pake­te, die von Betriebs­sys­tem­an­bie­tern, Hos­ting-Platt­for­men oder Her­stel­lern wie Plesk bereit­ge­stellt wer­den.

Dadurch kön­nen zwi­schen der Ver­öf­fent­li­chung durch das PHP-Pro­jekt und der tat­säch­li­chen Bereit­stel­lung geeig­ne­ter Pake­te zeit­li­che Unter­schie­de ent­ste­hen.

Ein uns vor­lie­gen­der Pro­vi­der-Hin­weis vom 21. Okto­ber 2026 erläu­tert bei­spiels­wei­se, dass der betref­fen­de Anbie­ter bei sei­nen Plesk-Instal­la­tio­nen auf ent­spre­chen­de Her­stel­ler­pa­ke­te ange­wie­sen ist.

Wich­tig: Die­se Aus­sa­ge beschreibt die Situa­ti­on des betref­fen­den Pro­vi­ders zum Zeit­punkt sei­ner Mit­tei­lung. Sie ist kei­ne all­ge­mein­gül­ti­ge Aus­sa­ge über die Ver­füg­bar­keit von Plesk-Sicher­heits­up­dates bei allen Hos­ting-Anbie­tern.

Sind älte­re PHP-Ver­sio­nen eben­falls betrof­fen?

Nach Anga­ben des BSI rei­chen die bekann­ten betrof­fe­nen PHP-Ver­sio­nen bis min­des­tens PHP 5 zurück.

Für die bereits abge­kün­dig­ten PHP-Ver­sio­nen 7.4, 8.0 und 8.1 hat das PHP Secu­ri­ty Team zusätz­lich Back­port-Patches bereit­ge­stellt.

Dar­über hin­aus kön­nen Linux-Dis­tri­bu­tio­nen und LTS-Anbie­ter Sicher­heits­kor­rek­tu­ren für älte­re PHP-Ver­sio­nen ver­öf­fent­li­chen.

Sol­che Back­ports bedeu­ten jedoch nicht, dass die regu­lä­re Unter­stüt­zung einer abge­kün­dig­ten PHP-Ver­si­on wie­der auf­ge­nom­men wur­de.

Das BSI emp­fiehlt des­halb grund­sätz­lich, PHP-Anwen­dun­gen auf wei­ter­hin unter­stütz­te Ver­si­ons­zwei­ge zu migrie­ren.

War­um kön­nen älte­re PHP-Ver­sio­nen plötz­lich abge­schal­tet wer­den?

Ein­zel­ne Hos­ting-Anbie­ter kön­nen aus Sicher­heits­grün­den ent­schei­den, nicht mehr regu­lär unter­stütz­te PHP-Ver­sio­nen aus ihrem Ange­bot zu ent­fer­nen.

Der uns vor­lie­gen­de Pro­vi­der-Hin­weis kün­digt bei­spiels­wei­se an, PHP-Ver­sio­nen unter­halb von 8.2 ab dem 22. Okto­ber 2026 auf den betreu­ten Sys­te­men nicht mehr bereit­zu­stel­len.

Dabei han­delt es sich um eine indi­vi­du­el­le Sicher­heits­ent­schei­dung die­ses Pro­vi­ders, nicht um eine all­ge­mei­ne Abschal­tung sämt­li­cher älte­rer PHP-Ver­sio­nen durch das PHP-Pro­jekt.

Web­site-Betrei­ber, deren Anwen­dun­gen zwin­gend auf älte­re PHP-Ver­sio­nen ange­wie­sen sind, soll­ten drin­gend die Kom­pa­ti­bi­li­tät mit einem unter­stütz­ten PHP-Zweig prü­fen.

Was gilt für Docker-Con­tai­ner und ande­re PHP-basier­te Sys­te­me?

Das BSI weist aus­drück­lich dar­auf hin, dass PHP-basier­te Anwen­dun­gen in Docker-Con­tai­nern unab­hän­gig vom Host­sys­tem aktua­li­siert wer­den müs­sen.

Ein aktua­li­sier­ter Host bedeu­tet nicht auto­ma­tisch, dass inner­halb eines Con­tai­ners bereits eine kor­ri­gier­te PHP-Ver­si­on aus­ge­führt wird.

Betrof­fe­ne Con­tai­ner-Images müs­sen gege­be­nen­falls aktua­li­siert, neu gebaut und neu bereit­ge­stellt wer­den.

Auch Her­stel­ler von Appli­ances und ande­ren Pro­duk­ten mit ein­ge­bet­te­ten PHP-Kom­po­nen­ten müs­sen unter Umstän­den eige­ne Sicher­heits- oder Firm­ware-Updates ver­öf­fent­li­chen.

Wel­che zusätz­li­chen Schutz­maß­nah­men emp­fiehlt das BSI?

Neben den eigent­li­chen Sicher­heits­up­dates emp­fiehlt das BSI, den Zugriff auf Web­an­wen­dun­gen mög­lichst restrik­tiv zu gestal­ten und die betei­lig­ten Kom­po­nen­ten umfas­send zu här­ten.

Ergän­zend kön­nen Web Appli­ca­ti­on Fire­walls ein­ge­setzt wer­den.

Für Linux-Sys­te­me emp­fiehlt das BSI außer­dem, die Sicher­heits­funk­tio­nen SELi­nux und AppAr­mor nach Mög­lich­keit zu kon­fi­gu­rie­ren und ein­zu­set­zen.

Sol­che Mecha­nis­men kön­nen die Aus­wir­kun­gen erfolg­rei­cher Angrif­fe begren­zen. Sie ver­hin­dern jedoch nicht auto­ma­tisch die Aus­nut­zung der bei­den PHP-Schwach­stel­len.

Wor­an erken­nen Betrei­ber, ob ihre Web­site bereits ange­grif­fen wur­de?

Im BSI-Sicher­heits­hin­weis vom 21. Okto­ber 2026 waren noch kei­ne bestä­tig­ten Angrif­fe auf Basis der bei­den Schwach­stel­len bekannt.

Das BSI weist dar­auf hin, dass zu die­sem Zeit­punkt auch noch kei­ne belast­ba­ren, all­ge­mein aner­kann­ten Indi­ca­tors of Com­pro­mi­se (IoCs) vor­la­gen.

Betrei­ber soll­ten expo­nier­te PHP-Web­ser­ver den­noch ver­stärkt auf Auf­fäl­lig­kei­ten über­wa­chen.

Dazu gehö­ren bei­spiels­wei­se uner­war­te­te PHP-Abstür­ze, unge­wöhn­li­che Pro­zes­se, auf­fäl­li­ge Anfra­gen, nicht auto­ri­sier­te Datei­ver­än­de­run­gen und uner­klär­li­che Ände­run­gen an Sys­tem­kon­fi­gu­ra­tio­nen.

Sol­che Auf­fäl­lig­kei­ten kön­nen unter­schied­li­che Ursa­chen haben und sind für sich genom­men kein Beweis für eine Aus­nut­zung der bei­den CVEs.

War­um rei­chen Back­ups allein nicht aus?

Back­ups sind ein zen­tra­ler Bestand­teil eines Sicher­heits­kon­zepts. Sie ermög­li­chen im Scha­dens­fall die Wie­der­her­stel­lung von Datei­en und Daten­ban­ken.

Ein Back­up ver­hin­dert jedoch kei­nen Angriff auf eine ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung.

Bei einer mög­li­chen Kom­pro­mit­tie­rung muss außer­dem geprüft wer­den, ob die vor­han­de­ne Siche­rung tat­säch­lich aus einem ver­trau­ens­wür­di­gen Zustand stammt.

Eine Wie­der­her­stel­lung auf einem wei­ter­hin ver­wund­ba­ren Sys­tem kann dazu füh­ren, dass die Web­site erneut ange­grif­fen wird.

PHP-Sicher­heits­up­dates sicher instal­lie­ren: Pra­xis­leit­fa­den

1. PHP-Ver­si­on fest­stel­len: Prü­fe, wel­che PHP-Ver­si­on tat­säch­lich für die Web­site ver­wen­det wird.
2. Patch­sta­tus kon­trol­lie­ren: Ver­glei­che die instal­lier­te Ver­si­on bezie­hungs­wei­se Paket­re­vi­si­on mit den Sicher­heits­mel­dun­gen des PHP-Pro­jekts oder des zustän­di­gen Her­stel­lers.
3. Hos­ting-Anbie­ter kon­tak­tie­ren: Klä­re bei Mana­ged Hos­ting oder Plesk, ob bei­de CVEs bereits kor­ri­giert wur­den.
4. Back­up erstel­len: Siche­re Web­site-Datei­en, Daten­bank und rele­van­te Kon­fi­gu­ra­tio­nen.
5. PHP aktua­li­sie­ren: Instal­lie­re die pas­sen­de kor­ri­gier­te Ver­si­on oder ein nach­weis­lich gepatch­tes Her­stel­ler­pa­ket.
6. PHP-Pro­zes­se neu star­ten: Stel­le sicher, dass kei­ne ver­wund­ba­ren Worker wei­ter­lau­fen.
7. Web­site tes­ten: Kon­trol­lie­re Word­Press-Backend, Front­end, For­mu­la­re, Shop-Funk­tio­nen, Log­in und wei­te­re geschäfts­kri­ti­sche Pro­zes­se.
8. Pro­to­kol­le prü­fen: Unter­su­che rele­van­te Ser­ver- und Sicher­heits­logs auf Auf­fäl­lig­kei­ten.
9. Doku­men­ta­ti­on aktua­li­sie­ren: Hal­te Ver­si­ons­stand, Patch­sta­tus, Update­zeit­punkt und Funk­ti­ons­prü­fung fest.
10. Lang­fris­ti­ge PHP-Migra­ti­on pla­nen: Erset­ze nicht mehr unter­stütz­te Ver­si­ons­zwei­ge und prü­fe die Kom­pa­ti­bi­li­tät indi­vi­du­el­ler Anwen­dun­gen.

Was bedeu­ten die PHP-Sicher­heits­lü­cken für Unter­neh­men?

Für Unter­neh­men ver­deut­li­chen die bei­den Schwach­stel­len, dass Web­site-Sicher­heit nicht allein aus regel­mä­ßi­gen WordPress‑, Plug­in- und The­me-Updates besteht.

Auch die zugrun­de lie­gen­de Ser­ver­in­fra­struk­tur muss kon­ti­nu­ier­lich über­wacht und aktua­li­siert wer­den.

Beson­ders wich­tig sind kla­re Ver­ant­wort­lich­kei­ten zwi­schen Unter­neh­men, Agen­tur, Hos­ting-Anbie­ter und Ser­ver­ad­mi­nis­tra­ti­on.

Unter­neh­men soll­ten wis­sen, wer Sicher­heits­mel­dun­gen bewer­tet, wer PHP-Updates instal­liert, wer die Funk­ti­ons­fä­hig­keit prüft und wer bei kri­ti­schen Sicher­heits­vor­fäl­len Ent­schei­dun­gen über eine vor­über­ge­hen­de Abschal­tung tref­fen kann.

Ein pro­fes­sio­nel­ler War­tungs­pro­zess berück­sich­tigt des­halb nicht nur die Anwen­dungs­ebe­ne, son­dern auch PHP, Web­ser­ver, Betriebs­sys­tem, Back­ups, Pro­to­kol­lie­rung und Sicher­heits­kon­fi­gu­ra­tio­nen.

Fazit: Kri­ti­sche PHP-Sicher­heits­lü­cken erfor­dern sofor­ti­ge Auf­merk­sam­keit

Die bei­den PHP-Sicher­heits­lü­cken vom 21. Okto­ber 2026 gehö­ren auf­grund ihrer mög­li­chen Aus­wir­kun­gen zu den beson­ders rele­van­ten Sicher­heits­er­eig­nis­sen für Betrei­ber PHP-basier­ter Web­sites.

Mit CVSS v4.0 9,2, einer mög­li­chen nicht authen­ti­fi­zier­ten Remo­te Code Exe­cu­ti­on und der brei­ten Ver­brei­tung von PHP besteht erheb­li­cher Hand­lungs­be­darf.

Das BSI bewer­tet die Situa­ti­on mit Kri­ti­k­ali­tät 3 / Oran­ge und hält eine kurz­fris­ti­ge Aus­nut­zung ver­wund­ba­rer Sys­te­me für wahr­schein­lich.

Web­site-Betrei­ber soll­ten des­halb den tat­säch­li­chen PHP-Patch­sta­tus prü­fen, ver­füg­ba­re Sicher­heits­up­dates unver­züg­lich instal­lie­ren und anschlie­ßend die wich­tigs­ten Funk­tio­nen kon­trol­lie­ren.

Sind pas­sen­de Sicher­heits­up­dates noch nicht ver­füg­bar, müs­sen vor­über­ge­hen­de Schutz­maß­nah­men bis hin zur Tren­nung gefähr­de­ter Sys­te­me vom Inter­net geprüft wer­den.

Lang­fris­tig zeigt der Vor­fall, wie wich­tig ein War­tungs­kon­zept ist, das Word­Press und die gesam­te tech­ni­sche Betriebs­um­ge­bung berück­sich­tigt.

Möch­test Du sicher­stel­len, dass Dei­ne Word­Press-Web­site nicht nur im Backend aktu­ell ist, son­dern auch auf einer sicher gepfleg­ten PHP- und Hos­ting-Umge­bung betrie­ben wird?
Wir unter­stüt­zen Dich bei Word­Press-War­tung, Sicher­heits­up­dates, tech­ni­scher Opti­mie­rung und der Abstim­mung mit Dei­nem Hos­ting-Anbie­ter.
Sprich uns ger­ne an.

Herz­li­che Grü­ße
Dein Team von Stra­te­gie­pool