PHP2Shell? Jetzt schnell und sicher reagieren.

Für die betroffenen Wartungszweige sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie jeweils spätere Releases gepatcht. Diese Versionen wurden am 21. Oktober 2026 veröffentlicht. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Dort ist ein Upgrade auf eine unterstützte Version nötig – oder du klärst mit deinem Hoster, ob er ein Sicherheits-Backport-Paket anbietet.

Nein. Die Schwachstelle liegt im PHP-Core. CMS-Updates bleiben wichtig, ersetzen aber kein Update der PHP-Runtime. Nach dem Update sollten auch PHP-FPM-, Apache- oder andere Worker neu gestartet und die Anwendung getestet werden.

Eine WAF, Netzwerkisolation oder restriktive Regeln können die Angriffsfläche vorübergehend reduzieren. Sie sind aber keine dauerhafte Behebung: Die PHP-Sicherheitsupdates müssen auf allen betroffenen Runtimes eingespielt werden.

Ja. Prüfe, ob dein Hoster die Sicherheitsupdates bereits eingespielt hat und welche PHP-Version für deine Website aktiv ist. Läuft sie noch auf PHP 8.1 oder älter, wechsle auf einen unterstützten Zweig. Bei vielen Hostern stellst du die PHP-Version selbst im Kund:innenmenü ein – die Installation des Updates übernimmt der Hoster.

Ja. Aktuell offiziell bestätigt betroffen sind Palo Alto Networks Firewalls mit PAN-OS sowie die Management-Appliance Panorama. Das betrifft nicht automatisch Router oder Firewalls anderer Hersteller: Entscheidend ist, ob die Verwaltungsoberfläche oder Firmware eine betroffene PHP-Runtime nutzt. Prüfe daher immer die Herstellerhinweise und Updates – besonders bei von außen erreichbaren Verwaltungsoberflächen.

Nein. KI kann helfen, Informationen einzuordnen oder Checklisten vorzubereiten, kann aber deine konkrete Infrastruktur nicht verlässlich prüfen, Updates nicht kontrolliert einspielen und keinen Sicherheitsvorfall bewerten. Dafür brauchst du erfahrene PHP-, Security- oder DevOps-Expert:innen, die eure Systeme, Abhängigkeiten und den sicheren Rollout prüfen.

Deine persönliche Ansprechperson unterstützt von der Bedarfsklärung bis zur Auswahl. Für die Vorauswahl berücksichtigt Junico unter anderem relevante Skills, Verfügbarkeit, Honorar und Projekterfahrung – damit du nicht selbst viele Profile vergleichen musst.

Je nach betroffenem System können Angreifer:innen Code ausführen, sensible Daten auslesen oder manipulieren und Dienste beeinträchtigen. Daraus können Betriebsunterbrechungen, Folgekosten und bei einem Datenschutzvorfall auch Melde-, Kommunikations- und Vertrauensrisiken entstehen. Wie hoch das Risiko tatsächlich ist, hängt davon ab, welche Systeme erreichbar sind und ob es bereits Hinweise auf einen Angriff gibt.

Ja. Dass eine Website unauffällig läuft, ist kein Entwarnungssignal. Prüfe zuerst alle öffentlich erreichbaren PHP-Anwendungen und aktualisiere sie auf die von PHP freigegebene Sicherheitsversion. Eine erfahrene Fachperson kann dabei Abhängigkeiten, Wartungsfenster und mögliche Auswirkungen auf eure Anwendung bewerten.

Nein. Die Schwachstelle steckt in PHP selbst – also in der Software, auf der WordPress läuft. Geschlossen wird sie nur durch ein PHP-Update auf dem Server. WordPress- und Plugin-Updates bleiben wichtig, schließen diese Sicherheitslücke aber nicht.

Nicht zuverlässig. Bei Apache mit mod_php kann ein Angriff bereits vor dem Anwendungscode ausgelöst werden. Ein Plugin innerhalb von WordPress greift dann zu spät. Nur das PHP-Update schließt die Sicherheitslücke zuverlässig.

Wenn du den Server nicht kurzfristig aktualisieren kannst, kann es sinnvoll sein, öffentlich erreichbare PHP-Dienste vorübergehend vom Internet zu trennen. Stimme das mit deinem Hoster oder einer erfahrenen Fachperson ab, damit kritische Funktionen kontrolliert abgeschaltet und nach dem Update geprüft wieder freigegeben werden.

Suche nach ungewöhnlichen Requests, Prozessen oder Änderungen an Dateien, kontrolliere Authentifizierungs- und Webserver-Logs und prüfe sensible Secrets. Bei belastbaren Hinweisen sollte die Person, die den Incident übernimmt, einen klaren Untersuchungs- und Kommunikationsplan festlegen.

Hilfreich sind: betroffene Domains oder Services, PHP-Versionen, Hosting oder Cloud-Umgebung, eingesetzte CMS oder Frameworks, Zugänge bzw. Freigabeprozess, Logs und die gewünschte Reaktionszeit. Teile keine Zugangsdaten in der öffentlichen Ausschreibung – Details klärst du erst im geschützten Austausch.

Ja. Du kannst deinen Auftrag kostenlos ausschreiben. Service- und Community Fees entstehen transparent erst dann, wenn es zu einer erfolgreichen Vermittlung und einer Rechnung durch die:den Freelancer:in kommt.