War­um ein Plug­in bei kri­ti­schen PHP-Sicher­heits­lü­cken nicht aus­reicht!

Nein, ein Word­Press-War­tungs­mo­dus schützt nicht zuver­läs­sig vor Hacker­an­grif­fen auf Sicher­heits­lü­cken in PHP.
Denn ein gewöhn­li­ches War­tungs­mo­dus-Plug­in wird erst inner­halb von Word­Press aus­ge­führt. Zu die­sem Zeit­punkt hat der Web­ser­ver die PHP-Lauf­zeit­um­ge­bung bereits ange­spro­chen. Befin­det sich die Sicher­heits­lü­cke in PHP selbst, kann ein Angriff unter Umstän­den erfol­gen, bevor das Plug­in über­haupt aktiv wird.

Beson­ders deut­lich wird die­ses Pro­blem durch die kri­ti­schen PHP-Sicher­heits­lü­cken CVE-2026–109618 und CVE-2026–109619, die im Okto­ber 2026 bekannt wur­den. Das Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (BSI) stuf­te die Bedro­hung mit Kri­ti­k­ali­tät 3 / Oran­ge ein und for­der­te unver­züg­li­che Sicher­heits­maß­nah­men.

Für Web­site-Betrei­ber stellt sich des­halb eine wich­ti­ge Fra­ge: Reicht es aus, Word­Press über ein Plug­in in den War­tungs­mo­dus zu ver­set­zen, oder muss der öffent­li­che Zugriff auf die Web­site ser­ver­sei­tig gesperrt wer­den?

Die Ant­wort hängt davon ab, wo sich die Schwach­stel­le befin­det und ob Anfra­gen wei­ter­hin die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung errei­chen kön­nen. Bei kri­ti­schen PHP-Schwach­stel­len reicht eine gewöhn­li­che War­tungs­sei­te inner­halb von Word­Press nicht aus.

Was ist ein Word­Press-War­tungs­mo­dus?

Der Word­Press-War­tungs­mo­dus dient dazu, Besu­chern wäh­rend tech­ni­scher Arbei­ten eine alter­na­ti­ve Sei­te anzu­zei­gen. Statt der regu­lä­ren Web­site erscheint bei­spiels­wei­se der Hin­weis, dass die Web­site vor­über­ge­hend nicht erreich­bar ist.

Typi­sche Ein­satz­be­rei­che sind die Über­ar­bei­tung einer Web­site, ein Relaunch, umfang­rei­che Design­än­de­run­gen oder geplan­te War­tungs­ar­bei­ten.

Für die Akti­vie­rung ste­hen ver­schie­de­ne Word­Press-Plug­ins zur Ver­fü­gung. Sie ermög­li­chen häu­fig eine indi­vi­du­ell gestal­te­te War­tungs­sei­te mit Logo, Kon­takt­da­ten und zusätz­li­chen Infor­ma­tio­nen.

Ent­schei­dend ist jedoch: Ein War­tungs­mo­dus ist zunächst eine Funk­ti­on zur Steue­rung der sicht­ba­ren Web­site-Inhal­te. Er ist nicht auto­ma­tisch eine tech­ni­sche Zugriffs­sper­re auf Ser­ver­ebe­ne.

Wie funk­tio­niert ein Word­Press-War­tungs­mo­dus tech­nisch?

Bei einem gewöhn­li­chen War­tungs­mo­dus-Plug­in durch­läuft eine Anfra­ge meh­re­re Ver­ar­bei­tungs­schrit­te.

1. Ein Besu­cher oder Angrei­fer ruft eine URL der Web­site auf.
2. Der Web­ser­ver nimmt die HTTP-Anfra­ge ent­ge­gen.
3. Der Web­ser­ver über­gibt die Anfra­ge gege­be­nen­falls an die PHP-Lauf­zeit­um­ge­bung.
4. PHP beginnt mit der Ver­ar­bei­tung der Anfra­ge.
5. Word­Press wird gela­den.
6. Das War­tungs­mo­dus-Plug­in wird aus­ge­führt.
7. Das Plug­in ent­schei­det, ob die nor­ma­le Web­site oder eine War­tungs­sei­te ange­zeigt wird.

Die eigent­li­che War­tungs­sei­te wird damit erst rela­tiv spät inner­halb der Ver­ar­bei­tungs­ket­te erzeugt.

Eine Sicher­heits­lü­cke, die bereits bei der Ver­ar­bei­tung durch PHP aus­ge­nutzt wer­den kann, wird durch die­se spä­te­re Ent­schei­dung nicht zuver­läs­sig ver­hin­dert.

War­um kann ein Hacker­an­griff trotz akti­vier­tem War­tungs­mo­dus erfol­gen?

Die Ant­wort liegt in der Tren­nung zwi­schen Anwen­dung und Lauf­zeit­um­ge­bung.

Word­Press ist eine PHP-Anwen­dung. Das War­tungs­mo­dus-Plug­in ist wie­der­um ein Bestand­teil die­ser Anwen­dung.

Die PHP-Lauf­zeit­um­ge­bung ist jedoch dafür ver­ant­wort­lich, den Pro­gramm­code über­haupt aus­zu­füh­ren. Wenn dort eine Sicher­heits­lü­cke besteht, kann ein Angrei­fer mög­li­cher­wei­se bereits wäh­rend der PHP-Ver­ar­bei­tung anset­zen.

Ein Plug­in kann grund­sätz­lich nur inner­halb der tech­ni­schen Gren­zen der Umge­bung arbei­ten, in der es aus­ge­führt wird.

Bei den kri­ti­schen PHP-Schwach­stel­len vom Okto­ber 2026 ist dies beson­ders rele­vant. Das PHP Secu­ri­ty Team beschreibt einen demons­trier­ten Angriffs­pfad bei Apa­che mit mod_php, 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.

Ein Word­Press-War­tungs­mo­dus kann einen sol­chen Angriff nicht zuver­läs­sig abweh­ren.

Was ist der Unter­schied zwi­schen War­tungs­mo­dus und ser­ver­sei­ti­ger Sper­re?

Die ent­schei­den­de Fra­ge lau­tet des­halb nicht, ob Besu­cher eine War­tungs­sei­te sehen, son­dern ob öffent­li­che Anfra­gen wei­ter­hin die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung errei­chen kön­nen.

Was bedeu­tet eine ser­ver­sei­ti­ge Abschal­tung der Web­site?

Eine ser­ver­sei­ti­ge Abschal­tung bedeu­tet nicht zwangs­läu­fig, dass der gesam­te Web­ser­ver aus­ge­schal­tet wer­den muss.

Statt­des­sen kann der öffent­li­che Zugriff auf die betrof­fe­ne Web­site oder die PHP-Ver­ar­bei­tung gezielt unter­bun­den wer­den.

Je nach Infra­struk­tur kom­men dafür unter­schied­li­che tech­ni­sche Maß­nah­men infra­ge:

• Fire­wall-Sper­re: Öffent­li­che Ver­bin­dun­gen zur betrof­fe­nen Anwen­dung wer­den blo­ckiert.
• Rever­se-Pro­xy-Sper­re: Anfra­gen wer­den vor der Wei­ter­lei­tung an den PHP-Backend-Dienst abge­fan­gen.
• Web­ser­ver-Kon­fi­gu­ra­ti­on: Apa­che oder Nginx ver­wei­gern den Zugriff auf die betrof­fe­ne Anwen­dung.
• Deak­ti­vie­rung der PHP-Ver­ar­bei­tung: Die ver­wund­ba­re Lauf­zeit­um­ge­bung ist über die öffent­li­che Web­site nicht mehr erreich­bar.
• Netz­werk­iso­la­ti­on: Das betrof­fe­ne Sys­tem wird vor­über­ge­hend vom öffent­li­chen Netz getrennt.

Wel­che Maß­nah­me geeig­net ist, hängt von der Hos­ting-Umge­bung, der ein­ge­setz­ten PHP-Betriebs­art und mög­li­chen wei­te­ren Anwen­dun­gen auf dem Ser­ver ab.

Reicht eine sta­ti­sche HTML-War­tungs­sei­te aus?

Eine rein sta­ti­sche HTML-War­tungs­sei­te kann als vor­über­ge­hen­de Maß­nah­me geeig­net sein, wenn sie voll­stän­dig ohne PHP aus­ge­führt wird und sämt­li­che rele­van­ten PHP-Zugrif­fe gesperrt sind.

Dabei wird die War­tungs­sei­te direkt vom Web­ser­ver oder einem vor­ge­schal­te­ten Rever­se Pro­xy aus­ge­lie­fert.

Der Web­ser­ver darf die Anfra­ge nicht an die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung wei­ter­lei­ten.

Eine Datei mit dem Namen wartung.html allein reicht aller­dings nicht aus. Ent­schei­dend ist die zuge­hö­ri­ge Ser­ver­kon­fi­gu­ra­ti­on.

Wenn bei­spiels­wei­se die Start­sei­te eine sta­ti­sche War­tungs­sei­te anzeigt, gleich­zei­tig aber /wp-login.php, /wp-admin/, /xmlrpc.php oder ande­re PHP-End­punk­te wei­ter­hin erreich­bar sind, besteht die Gefähr­dung mög­li­cher­wei­se fort.

Auch direk­te Auf­ru­fe von PHP-Datei­en in Unter­ver­zeich­nis­sen müs­sen berück­sich­tigt wer­den.

War­um ist eine Word­Press-War­tungs­sei­te nicht mit einer sta­ti­schen HTML-Sei­te gleich­zu­set­zen?

Eine War­tungs­sei­te kann äußer­lich iden­tisch aus­se­hen, obwohl sie tech­nisch auf völ­lig unter­schied­li­che Wei­se aus­ge­lie­fert wird.

Wird die Sei­te durch ein Word­Press-Plug­in erzeugt, muss Word­Press nor­ma­ler­wei­se zunächst gela­den wer­den.

Wird die­sel­be Sei­te dage­gen direkt durch den Web­ser­ver als sta­ti­sches HTML aus­ge­lie­fert, kann eine PHP-Ver­ar­bei­tung ent­fal­len.

Die opti­sche Dar­stel­lung sagt des­halb nichts dar­über aus, ob eine Web­site gegen Angrif­fe auf PHP abge­si­chert ist.

Auch eine vor­ge­schal­te­te War­tungs­sei­te bie­tet nur dann eine geeig­ne­te Iso­la­ti­on, wenn kei­ne alter­na­ti­ven öffent­li­chen Zugriffs­we­ge zur ver­wund­ba­ren PHP-Anwen­dung bestehen.

Wie lässt sich eine Web­site mit Apa­che ser­ver­sei­tig sper­ren?

Apa­che bie­tet ver­schie­de­ne Mög­lich­kei­ten, den Zugriff auf eine Web­site oder bestimm­te Ver­zeich­nis­se zu beschrän­ken.

Dazu gehö­ren bei­spiels­wei­se Zugriffs­kon­trol­len über die Ser­ver­kon­fi­gu­ra­ti­on, vir­tu­el­le Hosts oder vor­ge­schal­te­te Sicher­heits­me­cha­nis­men.

Bei einer sicher­heits­kri­ti­schen Abschal­tung muss sicher­ge­stellt wer­den, dass die Sper­re bereits vor der Aus­füh­rung ver­wund­ba­rer PHP-Kom­po­nen­ten greift.

Beson­de­re Vor­sicht ist bei Apa­che mit mod_php erfor­der­lich. Das PHP Secu­ri­ty Team bewer­tet die­se Betriebs­art im Zusam­men­hang mit den kri­ti­schen PHP-Schwach­stel­len vom Okto­ber 2026 als beson­ders gefähr­det.

Eine ein­fa­che Wei­ter­lei­tung auf eine War­tungs­sei­te oder eine nur inner­halb von Word­Press akti­vier­te Sper­re ist des­halb nicht aus­rei­chend.

Die kon­kre­te Kon­fi­gu­ra­ti­on soll­te durch den Ser­ver­ad­mi­nis­tra­tor vor­ge­nom­men und anschlie­ßend auf ihre Wirk­sam­keit geprüft wer­den.

Wie funk­tio­niert eine ser­ver­sei­ti­ge Sper­re mit Nginx?

Nginx kann HTTP-Anfra­gen bereits ver­ar­bei­ten, bevor sie an einen PHP-FPM-Dienst wei­ter­ge­lei­tet wer­den.

Die­se Archi­tek­tur ermög­licht es grund­sätz­lich, öffent­li­che Anfra­gen durch geeig­ne­te Regeln direkt am Web­ser­ver oder Rever­se Pro­xy abzu­fan­gen.

Dabei kann bei­spiels­wei­se eine sta­ti­sche War­tungs­sei­te aus­ge­lie­fert wer­den, ohne dass eine Ver­bin­dung zum PHP-FPM-Backend her­ge­stellt wird.

Wich­tig ist, dass sämt­li­che rele­van­ten URL-Pfa­de, direk­ten PHP-Auf­ru­fe und alter­na­ti­ven Zugangs­we­ge berück­sich­tigt wer­den.

Eine unvoll­stän­di­ge Nginx-Kon­fi­gu­ra­ti­on kann dazu füh­ren, dass bestimm­te Anfra­gen wei­ter­hin an PHP-FPM wei­ter­ge­reicht wer­den.

Des­halb muss nach der Ein­rich­tung über­prüft wer­den, ob die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung tat­säch­lich nicht mehr öffent­lich erreich­bar ist.

Wel­che Mög­lich­kei­ten bie­tet Plesk?

Plesk ist eine Ver­wal­tungs­ober­flä­che für Hos­ting- und Ser­ver­um­ge­bun­gen. Je nach Berech­ti­gung und Kon­fi­gu­ra­ti­on las­sen sich dort ver­schie­de­ne Ein­stel­lun­gen für Domains, Web­ser­ver und PHP vor­neh­men.

Für eine sicher­heits­kri­ti­sche Sper­re kom­men bei­spiels­wei­se durch den Admi­nis­tra­tor ein­ge­rich­te­te Web­ser­ver-Zugriffs­be­schrän­kun­gen, Ände­run­gen an der Domain-Kon­fi­gu­ra­ti­on oder eine kon­trol­lier­te Deak­ti­vie­rung der betrof­fe­nen PHP-Anwen­dung infra­ge.

Wich­tig: Eine in Plesk ein­ge­rich­te­te War­tungs­sei­te ist nicht auto­ma­tisch gleich­be­deu­tend mit einer voll­stän­di­gen Sper­re der PHP-Lauf­zeit­um­ge­bung.

Eben­so darf nicht davon aus­ge­gan­gen wer­den, dass jede Plesk-Instal­la­ti­on die­sel­ben Funk­tio­nen oder Kon­fi­gu­ra­ti­ons­mög­lich­kei­ten bereit­stellt.

Bei Mana­ged Hos­ting soll­te des­halb der Hos­ting-Anbie­ter aus­drück­lich beauf­tragt wer­den, den öffent­li­chen Zugriff auf die ver­wund­ba­re PHP-Anwen­dung vor der PHP-Ver­ar­bei­tung zu unter­bin­den.

War­um sind Word­fence und ande­re Sicher­heits­plug­ins kein voll­stän­di­ger Ersatz?

Word­Press-Sicher­heits­plug­ins kön­nen wich­ti­ge Schutz­funk­tio­nen bereit­stel­len.

Dazu gehö­ren bei­spiels­wei­se die Erken­nung ver­däch­ti­ger Anfra­gen, Log­in-Schutz, Datei­prü­fun­gen und anwen­dungs­spe­zi­fi­sche Fire­wall-Regeln.

Bei einer Schwach­stel­le in der PHP-Lauf­zeit­um­ge­bung sto­ßen sol­che Maß­nah­men jedoch an tech­ni­sche Gren­zen.

Ein Sicher­heits­plug­in, des­sen Schutz­me­cha­nis­men inner­halb von PHP aus­ge­führt wer­den, kann nicht zuver­läs­sig ver­hin­dern, dass eine Sicher­heits­lü­cke bereits bei der Ver­ar­bei­tung durch PHP aus­ge­nutzt wird.

Das bedeu­tet nicht, dass Sicher­heits­plug­ins grund­sätz­lich wir­kungs­los sind. Sie erfül­len wich­ti­ge Auf­ga­ben inner­halb eines mehr­schich­ti­gen Sicher­heits­kon­zepts.

Sie erset­zen aber weder PHP-Sicher­heits­up­dates noch eine geeig­ne­te ser­ver­sei­ti­ge Iso­la­ti­on bei akut ver­wund­ba­ren Sys­te­men.

Kann eine Web Appli­ca­ti­on Fire­wall vor PHP2Shell schüt­zen?

Eine Web Appli­ca­ti­on Fire­wall (WAF) kann HTTP-Anfra­gen ana­ly­sie­ren und bekann­te Angriffs­mus­ter blo­ckie­ren.

Bei den PHP-Sicher­heits­lü­cken vom Okto­ber 2026 haben ver­schie­de­ne WAF-Anbie­ter zusätz­li­che Schutz­re­geln ver­öf­fent­licht.

Das BSI weist jedoch aus­drück­lich dar­auf hin, dass sol­che Regeln kei­nen voll­stän­di­gen Schutz garan­tie­ren.

Ins­be­son­de­re bei bis­lang unbe­kann­ten Angriffs­tech­ni­ken oder Vari­an­ten kön­nen bestehen­de Fil­ter umgan­gen wer­den.

Eine WAF ist des­halb eine ergän­zen­de Sicher­heits­maß­nah­me, aber kein voll­stän­di­ger Ersatz für das Patchen oder die wirk­sa­me Iso­la­ti­on eines ver­wund­ba­ren Sys­tems.

Was emp­fiehlt das BSI bei kri­ti­schen PHP-Sicher­heits­lü­cken?

Das Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik ver­öf­fent­lich­te am 21. Okto­ber 2026 den IT-Sicher­heits­hin­weis BITS‑H Nr. 2026−297981−1132.

Das BSI stuft die Bedro­hung durch CVE-2026–109618 und CVE-2026–109619 mit Kri­ti­k­ali­tät 3 / Oran­ge ein.

Nach der BSI-Klas­si­fi­ka­ti­on müs­sen bei die­ser Warn­stu­fe Maß­nah­men unver­züg­lich ergrif­fen wer­den.

Das BSI emp­fiehlt ins­be­son­de­re:

• Ver­füg­ba­re PHP-Sicher­heits­up­dates unver­züg­lich instal­lie­ren.
• Den tat­säch­li­chen Patch­sta­tus anhand der Her­stel­ler­infor­ma­tio­nen über­prü­fen.
• Bei nicht kurz­fris­tig ver­füg­ba­ren Patches eine vor­über­ge­hen­de Tren­nung ver­wund­ba­rer Sys­te­me vom Inter­net erwä­gen.
• Web Appli­ca­ti­on Fire­walls und tech­ni­sche Work­arounds ledig­lich als ergän­zen­de bezie­hungs­wei­se über­brü­cken­de Maß­nah­men betrach­ten.
• Expo­nier­te PHP-Web­ser­ver ver­stärkt auf Auf­fäl­lig­kei­ten über­wa­chen.
• Lang­fris­tig auf unter­stütz­te PHP-Ver­sio­nen migrie­ren.

Die War­nung macht deut­lich, dass eine gewöhn­li­che Word­Press-War­tungs­sei­te kei­ne gleich­wer­ti­ge Alter­na­ti­ve zur ser­ver­sei­ti­gen Absi­che­rung dar­stellt.

War­um sind die PHP-Schwach­stel­len vom Okto­ber 2026 beson­ders rele­vant?

Die bei­den Sicher­heits­lü­cken CVE-2026–109618 und CVE-2026–109619 betref­fen die PHP-Lauf­zeit­um­ge­bung selbst.

Bei­de wur­den mit einem CVSS-v4.0‑Wert von 9,2 bewer­tet.

Unter bestimm­ten Vor­aus­set­zun­gen ermög­li­chen sie eine Remo­te Code Exe­cu­ti­on ohne vor­he­ri­ge Anmel­dung.

Am 21. Okto­ber 2026 ver­öf­fent­lich­te das PHP-Pro­jekt die kor­ri­gier­ten Ver­sio­nen:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

CERT-EU bestä­tig­te in sei­nem Secu­ri­ty Advi­so­ry 2026-018 die Dring­lich­keit der Aktua­li­sie­rung und ver­wies auf öffent­lich dis­ku­tier­te Angriffs­tech­ni­ken.

Am 23. Okto­ber 2026 ergänz­te CERT-EU sei­ne Mel­dung um eine wei­te­re, geson­der­te PHP-Schwach­stel­le mit der Ken­nung CVE-2026–115560. Nach Anga­ben des PHP-Pro­jekts betrifft die­se zusätz­li­che Schwach­stel­le eine unge­wöhn­li­che Anwen­dungs­kon­fi­gu­ra­ti­on und wird im regu­lä­ren Ver­öf­fent­li­chungs­zy­klus behan­delt.

Für Web­site-Betrei­ber unter­streicht dies, dass die Bewer­tung von PHP-Sicher­heits­ri­si­ken nicht mit der Instal­la­ti­on eines ein­zel­nen Word­Press-Plug­ins abge­schlos­sen ist.

Wann muss eine Web­site voll­stän­dig vom Inter­net getrennt wer­den?

Eine vor­über­ge­hen­de Tren­nung soll­te ins­be­son­de­re dann geprüft wer­den, wenn eine kri­ti­sche Schwach­stel­le bekannt ist, die betrof­fe­ne Lauf­zeit­um­ge­bung öffent­lich erreich­bar bleibt und ein erfor­der­li­ches Sicher­heits­up­date nicht kurz­fris­tig instal­liert wer­den kann.

Die Ent­schei­dung hängt unter ande­rem von der kon­kre­ten Ver­wund­bar­keit, der Ser­ver­kon­fi­gu­ra­ti­on, der Erreich­bar­keit und der geschäft­li­chen Bedeu­tung der Web­site ab.

Bei den PHP-Sicher­heits­lü­cken vom Okto­ber 2026 emp­feh­len BSI und CERT-EU aus­drück­lich, bei nicht unmit­tel­bar mög­li­cher Aktua­li­sie­rung eine Iso­la­ti­on gefähr­de­ter Sys­te­me in Betracht zu zie­hen.

Eine voll­stän­di­ge Abschal­tung des phy­si­schen oder vir­tu­el­len Ser­vers ist dafür nicht in jedem Fall erfor­der­lich.

Ent­schei­dend ist, dass kei­ne öffent­li­chen Anfra­gen mehr die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung errei­chen kön­nen.

Pra­xis­leit­fa­den: So sichern Unter­neh­men ihre Word­Press-Web­site im Ernst­fall ab

1. Sicher­heits­la­ge bewer­ten:
   Prü­fe, wel­che Schwach­stel­le vor­liegt und wel­che tech­ni­schen Kom­po­nen­ten betrof­fen sind.
2. PHP-Ver­si­on und Patch­sta­tus fest­stel­len:
   Kon­trol­lie­re nicht nur die ange­zeig­te PHP-Ver­si­on, son­dern auch die vom Hos­ting-Anbie­ter bereit­ge­stell­ten Sicher­heits­kor­rek­tu­ren.
3. Hos­ting-Anbie­ter kon­tak­tie­ren:
   Klä­re, wann erfor­der­li­che Sicher­heits­up­dates ver­füg­bar sind und wel­che kurz­fris­ti­gen Schutz­maß­nah­men umge­setzt wer­den kön­nen.
4. Word­Press-War­tungs­mo­dus nicht als Sicher­heits­maß­nah­me betrach­ten:
   Ein gewöhn­li­ches War­tungs­mo­dus-Plug­in ver­hin­dert kei­ne Angrif­fe auf die PHP-Lauf­zeit­um­ge­bung.
5. Ser­ver­sei­ti­ge Sper­re ein­rich­ten:
   Wenn ein erfor­der­li­cher Patch nicht ver­füg­bar ist, soll­te der öffent­li­che Zugriff auf die ver­wund­ba­re PHP-Anwen­dung zuver­läs­sig unter­bun­den wer­den.
6. Sta­ti­sche War­tungs­sei­te optio­nal bereit­stel­len:
   Die­se darf nur ohne PHP-Ver­ar­bei­tung aus­ge­lie­fert wer­den. Alter­na­ti­ve Zugangs­we­ge müs­sen eben­falls gesperrt sein.
7. Wirk­sam­keit über­prü­fen:
   Tes­te, ob direk­te PHP-Auf­ru­fe, Word­Press-End­punk­te und ande­re öffent­li­che Zugangs­we­ge tat­säch­lich blo­ckiert wer­den.
8. Sicher­heits­up­date instal­lie­ren:
   Aktua­li­sie­re die betrof­fe­ne PHP-Lauf­zeit­um­ge­bung bezie­hungs­wei­se instal­lie­re das kor­ri­gier­te Her­stel­ler­pa­ket.
9. PHP-Pro­zes­se neu star­ten:
   Stel­le sicher, dass kei­ne ver­wund­ba­ren PHP-Worker wei­ter­lau­fen.
10. Web­site kon­trol­liert wie­der frei­ge­ben:
    Prü­fe nach dem Update Front­end, Backend, For­mu­la­re und geschäfts­kri­ti­sche Funk­tio­nen, bevor die Sper­re auf­ge­ho­ben wird.

Was bedeu­tet das für Unter­neh­men und Web­site-Betrei­ber?

Für Unter­neh­men zeigt die­ses Bei­spiel, dass eine Web­site nicht allein dadurch sicher ist, dass sie nach außen kei­ne Inhal­te mehr anzeigt.

Die sicht­ba­re Web­site und die tat­säch­lich erreich­ba­ren tech­ni­schen Kom­po­nen­ten sind zwei unter­schied­li­che Ebe­nen.

Ein pro­fes­sio­nel­les Sicher­heits­kon­zept muss des­halb berück­sich­ti­gen, wel­che Sys­te­me hin­ter der Web­site betrie­ben wer­den und an wel­cher Stel­le Sicher­heits­maß­nah­men grei­fen.

Beson­ders wich­tig ist die Zusam­men­ar­beit zwi­schen Web­site-Betrei­ber, Agen­tur und Hos­ting-Anbie­ter.

Wäh­rend eine Agen­tur häu­fig Word­Press, Plug­ins und The­mes betreut, liegt die Admi­nis­tra­ti­on der PHP-Lauf­zeit­um­ge­bung je nach Ver­trags­mo­dell beim Hos­ting-Anbie­ter oder einem geson­der­ten Ser­ver­ad­mi­nis­tra­tor.

Im Sicher­heits­fall müs­sen die Ver­ant­wort­lich­kei­ten ein­deu­tig geklärt sein.

Unter­neh­men soll­ten des­halb nicht erst bei einer kri­ti­schen Sicher­heits­war­nung prü­fen, wer eine Web­site ser­ver­sei­tig sper­ren, PHP aktua­li­sie­ren und die tech­ni­sche Erreich­bar­keit kon­trol­lie­ren kann.

Fazit: Ein Word­Press-War­tungs­mo­dus ersetzt kei­ne ser­ver­sei­ti­ge Sicher­heits­maß­nah­me

Ein Word­Press-War­tungs­mo­dus ist sinn­voll, um Besu­cher über War­tungs­ar­bei­ten zu infor­mie­ren. Als Schutz vor kri­ti­schen PHP-Sicher­heits­lü­cken ist er jedoch nicht aus­rei­chend.

Denn die eigent­li­che Gefähr­dung liegt in die­sem Fall unter­halb der Word­Press-Anwen­dungs­ebe­ne.

Solan­ge öffent­li­che Anfra­gen die ver­wund­ba­re PHP-Lauf­zeit­um­ge­bung errei­chen kön­nen, besteht das Risi­ko grund­sätz­lich fort.

Wenn not­wen­di­ge Sicher­heits­up­dates nicht kurz­fris­tig instal­liert wer­den kön­nen, soll­te des­halb eine geeig­ne­te ser­ver­sei­ti­ge Sper­re oder vor­über­ge­hen­de Iso­la­ti­on der betrof­fe­nen Anwen­dung geprüft wer­den.

Eine sta­ti­sche HTML-War­tungs­sei­te kann dabei eine sinn­vol­le Lösung sein, sofern sie ohne PHP-Ver­ar­bei­tung aus­ge­lie­fert wird und kei­ne alter­na­ti­ven öffent­li­chen Zugangs­we­ge offen­blei­ben.

Die dau­er­haf­te Lösung bleibt jedoch die Instal­la­ti­on der erfor­der­li­chen Sicher­heits­up­dates.

Möch­test Du sicher­stel­len, dass Dei­ne Word­Press-Web­site bei kri­ti­schen Sicher­heits­lü­cken nicht nur eine War­tungs­sei­te anzeigt, son­dern tech­nisch wirk­sam geschützt wird?
Wir unter­stüt­zen Dich bei Word­Press-Sicher­heit, tech­ni­schen Updates, der Prü­fung Dei­ner Hos­ting-Umge­bung und der Abstim­mung not­wen­di­ger Schutz­maß­nah­men mit Dei­nem Hos­ting-Anbie­ter.
Sprich uns ger­ne an.

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