PHP2Shell ist der Name, der für die kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 verwendet wird. Serveradministratoren sollten exponierte PHP-Anwendungen identifizieren, Bereiten Sie sich auf die Installation vom Hersteller bestätigter Fixes vor, und entscheiden, ob vorübergehende Zugangsbeschränkungen notwendig sind. Dieser Leitfaden behandelt PHP-Websites zum Shared Hosting, virtuelle und dedizierte Server, und Container-basierte Bereitstellungen.
Aktualisiert: 21 Oktober 2026, nach der PHP-Sicherheitsveröffentlichung. Es sind jetzt korrigierte Upstream-Releases verfügbar. Die Repository-Bereitstellung ist ein separater Schritt: Bestätigen Sie das genaue Paket, das von Ihrem Betriebssystem bereitgestellt wird, Bedienfeld oder Bildbetreuer.
Gepatchte PHP2Shell-Versionen
Der PHP-Sicherheitsankündigung identifiziert diese korrigierten Versionen sowohl für CVE-2026-109618 als auch für CVE-2026-109619:
| PHP-Zweig | Erste korrigierte Upstream-Version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Ein Distributions-Backport behält möglicherweise eine ältere PHP-Versionszeichenfolge bei. Überprüfen Sie die vollständige Paketversion anhand der Herstellerempfehlung. Die Installation einer neuen PHP-Version in einem anderen Verzeichnis ersetzt nicht die Laufzeit, die eine Website bereitstellt.
Für PHP gibt es auch minimale Quell-Backports 7.4, 8.0 Und 8.1. Dies sind Quelländerungen für Paketersteller, nicht automatisch installierte RPM/DEB-Updates oder erneuerte Upstream-Unterstützung.
Wie könnte ein PHP-Remote-Code-Execution-Angriff funktionieren??
Auf allgemeiner Ebene, Ein nicht authentifizierter, webbasierter RCE ermöglicht es einem Angreifer, manipulierte Eingaben an einen erreichbaren Dienst zu übermitteln und eine Ausführung außerhalb des beabsichtigten Verhaltens der Anwendung zu veranlassen. Eine PHP-Laufzeitschwachstelle kann sich auf Anwendungen auswirken, auch wenn es sich um eigenen Code handelt, Plugins und Passwörter sind aktuell.
WordPress-Webhosting
Ab 3,99 $/Monat
Die offiziellen Hinweise beschreiben nun zwei deutliche Mängel: Beschädigung durch nicht genügend Arbeitsspeicher mit teilweise initialisierten Anforderungsdaten, Und abgestandener globaler Staat das kann in einer späteren Anfrage überleben. Dies ist ein Laufzeitproblem, Keine Voraussetzung für ein anfälliges WordPress-Plugin. Die Ausnutzbarkeit hängt von der Ausführungsumgebung ab; „Jede Website gibt mit einer Anfrage Wurzeln“ ist keine berechtigte Schlussfolgerung.
Wenn Code innerhalb eines PHP-Workers ausgeführt wird, Die anfängliche Auswirkung hängt von der Betriebssystemidentität und den Berechtigungen dieses Workers ab. Zu den möglichen Konsequenzen gehört das Auslesen der Anwendungskonfiguration, Abrufen von Datenbankanmeldeinformationen, Ändern beschreibbarer Website-Dateien oder Erstellen von Persistenz. Die Ausführung als Website-Konto bedeutet nicht automatisch die Ausführung als Root. Gemeinsame Anmeldeinformationen, Übermäßige Berechtigungen oder zusätzliche Schwachstellen können den Schaden jedoch erhöhen.
Diese Unterscheidung ist auf gemeinsam genutzten Servern wichtig: Getrennte Abonnementbenutzer und eingeschränkter Dateisystemzugriff können die Auswirkungen eines Vorfalls begrenzen, Sie beheben jedoch nicht die PHP-Schwachstelle selbst.
Welche Websites und Server benötigen Aufmerksamkeit??
Inventarisieren Sie mit dem Internet verbundene PHP-Workloads in WordPress, WooCommerce, WHMCS, Laravel-Anwendungen, benutzerdefinierte APIs, Webmail und andere PHP-basierte Dienste. Produktion einbeziehen, Inszenierung, Vergessene Subdomains, alternative Häfen und Container. Eine Site, die wenig Traffic erhält, kann dennoch eine veraltete Laufzeit aufweisen.
Auf eine selbstverwaltete VPS oder dedizierter Server, Legen Sie fest, wer die PHP-Pakete verwaltet. Auf Managed Hosting, Fragen Sie den Betreiber, welcher Paket-Build Ihr Konto bedient und ob dieser Build Fixes für beide CVEs enthält. Eine Aussage, dass das Hosting-Panel aktualisiert wird, ist kein ausreichender Hinweis auf die Laufzeit.
Schließen Sie die Sicherheit nicht allein von der Hauptversion ab. PHP 8.2 oder 8.3 ist eine Filiale, kein Beweis dafür, dass ein bestimmter Build gepatcht wurde. Umgekehrt, Einige Anbieter portieren Sicherheitskorrekturen zurück, ohne die neueste Versionsnummer der Originalautoren zu übernehmen, Daher sind auch die Paketfreigabe und der Sicherheitshinweis des Anbieters von Bedeutung.
Günstiger VPS-Server
Ab 2,99 $/Monat
Was können Sie tun, bevor ein verifizierter Patch verfügbar ist??
CERT-EU empfiehlt, die Isolierung von mit dem Internet verbundenen PHP-Anwendungen in Betracht zu ziehen, wenn ein sofortiges Patchen nicht möglich ist. Das Ziel besteht darin, nicht vertrauenswürdige Anfragen zu stoppen, bevor sie die anfällige Laufzeit erreichen. Wählen Sie ein Steuerelement aus, das den geschäftlichen Auswirkungen entspricht, und stellen Sie sicher, dass es jeden Weg zur Anwendung abdeckt.
| Vorübergehende Maßnahme | Was es erreicht | Operative Konsequenz |
|---|---|---|
| Erlauben Sie nur vertrauenswürdige IPs oder VPN-Zugriffe am Webserver oder an der Netzwerkgrenze | Verhindert, dass nicht genehmigte Clients die geschützte Anwendung erreichen, wenn alle Einstiegspunkte abgedeckt sind | Öffentliche Kunden und externe Integrationen verlieren möglicherweise den Zugriff |
| Stellen Sie eine statische Wartungsseite bereit und blockieren Sie das öffentliche PHP-Routing | Hält eine öffentliche Bekanntmachung verfügbar, ohne Besucheranfragen an PHP zu senden | Login, Kasse, APIs und andere dynamische Funktionen werden gestoppt |
| Halten Sie die Anwendung mit vorhandener Filterung und Überwachung öffentlich | Behält die Verfügbarkeit bei und kann böswilligen Datenverkehr reduzieren | Es bleibt eine Restbelichtung bestehen; Dies ist keine verifizierte Lösung |
Ein WordPress-Wartungs-Plugin läuft weiterhin über PHP. Nur einschränkend /wp-admin/, Durch das WHMCS-Administratorverzeichnis oder den Plesk-Anmeldeport wird die Gefährdung durch die öffentliche Anwendung nicht entfernt. Bei Verwendung einer statischen Antwort, Stellen Sie sicher, dass die Routen des Front-Controllers gewährleistet sind, direkte PHP-URLs und alternative virtuelle Hosts können es nicht umgehen.
Für Websites hinter einem Reverse-Proxy oder CDN, Überprüfen Sie den direkten Ursprungszugriff sowie den öffentlichen Hostnamen. Wenden Sie Einschränkungen konsequent auf IPv4 an, IPv6 und alternative Überwachungsports. Testen Sie über eine nicht genehmigte externe Verbindung, nicht nur von der vom Administrator zugelassenen Adresse.
Vorübergehende Abhilfemaßnahmen für die PHP-Konfiguration
PHP bestätigt nun, dass die Deaktivierung des Upload-Fortschritts die bekannten sitzungsbezogenen Pfade blockiert, aber nicht jede Variante. Legen Sie dies in der geladenen PHP-Konfiguration auf Serverebene oder im FPM-Pool fest, bevor Sie die Anforderung analysieren:
session.upload_progress.enabled = OffFür PHP 8.5, auch eingestellt:
fatal_error_backtraces = OffStarten Sie jeden relevanten Worker neu. Eine Anwendungsebene ini_set() oder FPM .user.ini reicht hierfür nicht aus. Überprüfen Sie die Pool- und Virtual-Host-Überschreibungen. Diese Maßnahmen reduzieren die spezifische Exposition; Sie ersetzen nicht die korrigierte Binärdatei.
Windows VPS-Hosting
Fernzugriff und vollständige Verwaltung
Die OOM-Beratung bespricht memory_limit=-1 mit externen Speichersteuerungen. Setzen Sie diese Änderung nicht blind auf Shared Hosting um: Das Entfernen des PHP-Limits kann zur Erschöpfung der Ressourcen führen, und zugrunde liegende Allokationsfehler bleiben möglich. Die Beschränkungen der Anforderungsgröße müssen den Anwendungsanforderungen entsprechen. Siehe die offizielle OOM-Beratung bevor Sie diese Schadensbegrenzung entwerfen.
Kann Cloudflare, ein WAF- oder DDoS-Schutz. Ersetzen Sie den Patch?
Eine vom Anbieter validierte Regel kann vorübergehenden Schutz vor einem bekannten Anforderungsmuster bieten, Aber die bloße Aktivierung einer WAF beweist nicht, dass beide CVEs abgedeckt sind. Eine Regel hilft möglicherweise auch nicht, wenn der Verkehr den Ursprung über eine andere Route erreicht.
Netzwerkverfügbarkeitsschutz und Laufzeit-Patching lösen unterschiedliche Probleme. Unser Leitfaden zu DDoS-geschützte VPS-Funktionen und -Grenzwerte erklärt die Verfügbarkeitsseite; Ein PHP RCE erfordert immer noch eine eigene Korrektur. Behalten Sie die vorhandenen Steuerelemente aktiviert, aber wandeln Sie ihre Anwesenheit nicht in eine Behauptung um, dass PHP2Shell gelöst ist.
So patchen Sie PHP auf Servern und Websites
Überprüfen Sie zunächst, ob der Paketanbieter einen Build veröffentlicht hat, der explizit beide CVEs anspricht. Die Upstream-Veröffentlichungszeit und die Verfügbarkeit in einem Hosting-Panel-Repository sind separate Meilensteine. Ein erfolgreiches Update ohne installierte neue Pakete schließt den Vorfall nicht aus.
- Bereiten Sie die Genesung vor: Bestätigen Sie eine aktuelle wiederherstellbare Sicherung und behalten Sie den aktuellen Paket- und Konfigurationsbestand bei. Vermeiden Sie es, das einzige nachweislich funktionierende Backup auszutauschen.
- Passen Sie den Anbieter an: Betriebssystempakete unterscheiden, Laufzeiten des Bedienfelds, Pakete und Container-Images von Drittanbietern.
- Installieren Sie die korrigierten Pakete: Bevorzugen Sie bei Bedarf ein Update innerhalb des vorhandenen unterstützten Zweigs, statt einer ungetesteten Hauptversionsmigration.
- Ersetzen Sie laufende anfällige Prozesse: Befolgen Sie die Neustartanweisungen des Anbieters für die relevanten PHP-FPM-Dienste, Webservermodule oder Anwendungspools.
- Überprüfen Sie jeden betroffenen Workload: Vergleichen Sie die installierten Paketbuilds mit der Empfehlung und bestätigen Sie, dass die Laufzeit jede Domäne tatsächlich bedient.
Wählen Sie die Update-Methode für Ihre Hosting-Umgebung
| Umfeld | Sanierungsansatz | Was zu überprüfen ist |
|---|---|---|
| Selbstverwalteter Linux- oder Windows-Server | Installieren Sie den korrigierten PHP-Build von dem Anbieter, der für die bestehende Installation verantwortlich ist. | Das Paket oder der Binär-Build, Webserver-Integration und laufende Prozesse. |
| Shared oder Managed Hosting | Bitten Sie den Hosting-Betreiber, die korrigierte Laufzeit auf das Konto anzuwenden. | Bestätigung, die sowohl CVEs als auch den PHP-Build abdeckt, der die Website bedient. |
| Hosting-Kontrollfeld | Befolgen Sie die Paketempfehlung und das unterstützte Aktualisierungsverfahren dieses Panel-Anbieters. | Jede aktive PHP-Version und ihre Domänenzuweisungen. |
| Container | Erstellen Sie ein korrigiertes Image oder beziehen Sie es und stellen Sie die laufenden Workloads erneut bereit. | Das Image und der PHP-Build werden in jeder laufenden Instanz erstellt. |
| Benutzerdefinierter Quellcode-Build | Neuaufbau aus einer vom Hersteller bestätigten korrigierten Version unter Verwendung der erforderlichen Erweiterungen und Konfigurationen. | Dass der Webdienst die neue Binärdatei anstelle einer älteren Installation verwendet. |
Es gibt keinen einzigen Update-Befehl, der alle diese Umgebungen sicher abdeckt. Durch die Installation des Standard-PHP-Pakets des Betriebssystems bleibt möglicherweise eine separat installierte Laufzeitumgebung unverändert. Ähnlich, Durch die Installation eines korrigierten Images auf einem Container-Host werden bereits laufende Container nicht ersetzt.
Koordinieren Sie Updates mit Anwendungseigentümern und testen Sie die Funktionen, die von PHP abhängen. Wenn mehrere Versionen nebeneinander existieren, Behandeln Sie jedes einzelne Element als separates Sanierungselement.
Linux-Patch-Befehle: Überprüfen, Aktualisieren, Neustart, Verifizieren
Führen Sie die entsprechenden Befehle auf einem autorisierten Host aus, nachdem Sie die Sicherungen und ein Wartungsfenster überprüft haben. Diese Beispiele verwenden vorhandene Repositorys und installierte Pakete. Sie wechseln weder PHP-Modul-Streams noch fügen sie ein externes Repository hinzu. Überprüfen Sie die vorgeschlagene Transaktion, bevor Sie sie annehmen.
AlmaLinux, Rocky Linux und RHEL mit DNF
rpm -q php-common php-cli php-fpm
dnf --refresh check-update 'php*'
dnf --refresh upgrade 'php*'check-update kehrt zurück 100 wenn Updates verfügbar sind; Das ist kein fehlgeschlagenes Update. Für ein geplantes Update des gesamten Hosts statt nur PHP, verwenden dnf --refresh upgrade. Überprüfen Sie übersprungene oder ausgeschlossene Pakete und Abhängigkeitskonflikte. Entfernen Sie keine Erweiterungen mit --allowerasing lediglich um die Transaktion zu erzwingen. DNF-Befehlsreferenz.
Ubuntu und Debian mit APT
sudo apt-get -o APT::Update::Error-Mode=any update
dpkg-query -W 'php*'
apt-cache policy php8.2-common php8.2-cli php8.2-fpm
sudo apt-get --only-upgrade install php8.2-common php8.2-cli php8.2-fpmDieses Beispiel gilt für ein vorhandenes PHP 8.2 FPM-Installation. Ersetzen Sie den tatsächlich installierten Zweig und schließen Sie die installierten Erweiterungspakete ein; Für die Bereitstellung eines Apache-Moduls ist auch das entsprechende Paket erforderlich. Für ein geplantes allgemeines Update, sudo apt-get --with-new-pkgs upgrade Aktualisiert installierte Pakete und ermöglicht neue Abhängigkeiten, ohne Pakete zu entfernen. Sperren und Abhängigkeitsbeschränkungen können dazu führen, dass Pakete immer noch ausstehen. Siehe die APT-Dokumentation.
Starten Sie die Laufzeit neu, die tatsächlich Anforderungen bearbeitet
Für einen Standard-RPM-PHP-FPM-Dienst:
sudo php-fpm -t && sudo systemctl restart php-fpm
systemctl is-active php-fpmFür ein Standard-Debian/Ubuntu-PHP 8.2 FPM-Service:
sudo php-fpm8.2 -t && sudo systemctl restart php8.2-fpm
systemctl is-active php8.2-fpmPassen Sie die Binärdatei an, Konfigurationspfad und Dienstname für benutzerdefinierte Pools oder Hosting-Panels. Apache mod_php muss nach einem erfolgreichen Konfigurationstest ersetzt werden. Starten Sie PHP-Anwendungs-Worker mit langer Laufzeit gegebenenfalls neu. Ein PHP-Update allein erfordert normalerweise keinen Neustart der gesamten Maschine; Andere aktualisierte Komponenten erfordern möglicherweise einen separat geplanten Neustart.
Bestätigen Sie, was das Update tatsächlich installiert hat
php -v
php --ini
systemctl --failed --no-pagerDiese Kontrollen sind ein Ausgangspunkt, kein Beweis für die Laufzeit jeder Domain. Überprüfen Sie den vollständigen RPM/DEB-Build, die laufende Web-SAPI und alle Pool-Überschreibungen. „Nichts zu tun“ beschreibt nur verfügbare Updates in den konfigurierten Repositories. Fehlender CVE-Text in einem lokalen Änderungsprotokoll ist nicht der Fall, allein, endgültiger Beweis so oder so.
Container und Anbieteranwendungen benötigen ihren eigenen Patch-Pfad
Host-Paketaktualisierungen ersetzen PHP nicht innerhalb eines Container-Images. Inventarbehälter, Erhalten Sie das vom Anbieter bestätigte feste Bild, Erstellen Sie dann die Arbeitslast mit intakten persistenten Volumes und intakter Bereitstellungskonfiguration neu. Das alleinige Abrufen eines Images ersetzt keinen laufenden Container. Docker dokumentiert diese separat als komponieren ziehen Und komponieren.
Für eine produktverwaltete Bereitstellung wie SolusVM, Verwenden Sie den unterstützten Updater und überprüfen Sie jeden PHP-tragenden Dienst, einschließlich API und Worker. Behandeln Sie eine manuelle Paketinstallation in einem kurzlebigen Container nicht als dauerhafte Behebung. Für natives Passbolt, patcht seine Host-PHP-Pakete und behält dabei erforderliche Erweiterungen wie GnuPG bei, Führen Sie dann die Gesundheitsprüfung durch und testen Sie die Authentifizierung und den Passwortzugriff. Für Container-Passbolt, Folgen Sie dem Bildaktualisierungspfad.
Beispiel für ein Bedienfeld: PHP2Shell auf Plesk
Beispiel: PHP auf Plesk prüfen
Der Plesk-Beratung listet Linux-Hosting-PHP-Korrekturen für 8.2–8.5 auf. Bei dieser Rezension, Es ist PHP 7.4/8.0/8.1 und Windows-Pakete bleiben in der Entwicklung, während Panel sw-engine Korrekturen sind geplant 18.0.80#11 Und 18.0.81#4. Überprüfen Sie die Live-Beratung, bevor Sie handeln; Eine geplante Version ist kein installierter Fix.
Inventarisieren Sie Website-Handler getrennt von der Panel-Engine:
sw-engine -v
plesk versionNicht ersetzen sw-engine mit einer Website-PHP-Binärdatei oder ändern Sie deren Symlink. Nutzen Sie die von Plesk unterstützten Updates.
Listen Sie die PHP-Handler in Plesk für Linux auf
Führen Sie diese schreibgeschützten Inventarisierungsbefehle über eine autorisierte SSH-Sitzung aus:
plesk version
plesk bin php_handler --listNotieren Sie die Kennung jedes Handlers, PHP-Version und ausführbarer Pfad. Listen Sie dann die Domänen mit einem bestimmten Handler auf:
plesk bin php_handler --get-usage -id HANDLER_IDErsetzen HANDLER_ID mit einer tatsächlichen Kennung aus der Liste. Diese Befehle folgen dem Plesk PHP-Handler-Dokumentation. Nur zur Überprüfung php -v Das Problem kann möglicherweise übersehen werden, da der Befehlszeilenstandard von der für eine Website ausgewählten Laufzeit abweichen kann.
Erstellen Sie ein kleines Inventar mit einer Domain, Handels-ID, Paketanbieter, Build installiert, Anwendungseigentümer und Korrekturstatus. Beziehen Sie PHP-basierte Hilfsdienste und Container ein, die nicht durch gewöhnliche Website-Zuweisungen repräsentiert werden.
Aktualisieren Sie von Plesk verwaltete PHP-Pakete
Für von Plesk verwaltete Komponentenaktualisierungen, Die offizielle Schnittstelle ist Werkzeuge & Einstellungen → Updates → Komponenten aktualisieren. Die dokumentierte Befehlszeilenalternative lautet:
plesk installer updateDies ist ein Änderungsbefehl: Es installiert verfügbare Plesk-Updates und startet möglicherweise aktualisierte Komponenten neu. Überprüfen Sie die Anweisungen zum Plesk-Update und Ihre Wartungsanforderungen, bevor Sie es ausführen. Es kann kein Fix installiert werden, den die konfigurierten Repositorys noch nicht bereitstellen.
Nachdem die PHP-Binärdateien aktualisiert wurden, Aktualisieren Sie die Plesk-Handlerinformationen bei Bedarf:
plesk bin php_handler --reread
plesk bin php_handler --listDas Aktualisieren des Handler-Inventars ist kein Ersatz für die Wiederinbetriebnahme betroffener Arbeitskräfte.
Was ist mit PHP? 7.4, WordPress und WHMCS?
Der Zeitplan für den PHP-Support Listen 8.2, 8.3, 8.4 Und 8.5 als unterstützte Zweige zum Zeitpunkt dieser Überprüfung. PHP 7.4 liegt außerhalb des Upstream-Supports. Eine Legacy-Installation erfordert daher entweder eine getestete Migration auf eine unterstützte, korrigierter Build oder ein explizit verifizierter Sicherheits-Backport von seinem Paketanbieter.
Wechseln Sie eine ältere WHMCS-Installation nicht direkt von PHP aus 7.4 zu einer beliebigen PHP 8.x-Version. Überprüfen Sie die Kompatibilitätsmatrix der Anwendung, Anforderungen für den ionCube Loader, Zuerst kommerzielle Module und benutzerdefinierte Hooks. Wenn eine sofortige Migration unpraktisch ist und kein verifizierter Backport verfügbar ist, Die Zugangsbeschränkung bleibt eine betriebliche Option.
Für WordPress, Aktualisierung des Kerns, Plugins und Themes bleiben eine nützliche Wartung, es ersetzt jedoch kein PHP-Runtime-Update. Testverwaltung, Medien-Uploads, Geplante Aufgaben und Auschecken nach dem PHP-Wechsel. Für WHMCS, Testen Sie auch die Client-Anmeldung, Bestellungen, Zahlungsrückrufe, Ticketanhänge, Bereitstellung und die ausführbare PHP-Datei des Cron-Jobs.
So überprüfen Sie die Behebung und prüfen auf Gefährdung
Schließen Sie die Behebung erst ab, wenn Sie Beweise für den installierten Fix und den ausgeführten Dienst haben. Notieren Sie die Empfehlung, Paketaufbau, Installationszeit, Worker-Neustart und Anwendungsprüfungen. Verwenden Sie eine authentifizierte oder lokale Diagnose, um die Weblaufzeit zu überprüfen; Verlassen Sie kein Publikum phpinfo() Seite, die die Konfiguration freigibt.
Überprüfen Sie prozessbegleitend Webserver- und PHP-Protokolle, Dateiintegrität und Kontoaktivität. Unerwartete Shell-Prozesse, die von einem Web-Worker gestartet wurden, ungewohnte geplante Aufgaben, Neu geänderte PHP-Dateien oder ungewöhnliche ausgehende Verbindungen erfordern eine Untersuchung. Dabei handelt es sich um allgemeine Vorfallindikatoren, nicht veröffentlichte Unterschriften, die die Ausnutzung dieser bestimmten CVEs belegen.
Bei Verdacht auf Kompromittierung, Isolieren Sie die Arbeitsbelastung, Beweismittel sichern und feststellen, welche Ausweise zugänglich waren. Möglicherweise ist ein Neuaufbau von einer vertrauenswürdigen Basislinie und rotierende offengelegte Geheimnisse erforderlich. Durch die Installation eines Patches wird weder eine vorhandene Web-Shell entfernt noch werden gestohlene Anmeldeinformationen ungültig.
Häufig gestellte Fragen
Ist PHP2Shell eine Sicherheitslücke im WordPress-Plugin??
Die Hinweise betreffen PHP selbst. Ein WordPress-Plugin-Update repariert nicht die zugrunde liegende Laufzeit. Bewerten Sie den PHP-Build, der die Site bedient.
Ist PHP 8.2 automatisch sicher?
NEIN. Ein unterstützter Zweig kann immer noch einen anfälligen Build enthalten. Bestätigen Sie die korrigierte Paketversion anhand der Herstellerempfehlung.
Muss ich den gesamten Server herunterfahren??
Nicht unbedingt. Möglicherweise ist es möglich, einzelne Webanwendungen einzuschränken oder die öffentliche PHP-Ausführung zu stoppen, während unabhängige Dienste weiterhin ausgeführt werden. Überprüfen Sie den Bereich, bevor Sie eine umfassende Netzwerkregel anwenden.
Verhindert HTTPS diesen Angriff??
HTTPS verschlüsselt den Transport. Es stellt nicht sicher, dass der Server die entschlüsselte Anwendungsanfrage sicher verarbeitet, Es ist also kein Ersatz für eine Laufzeitkorrektur.
Kann ich die Sicherheit mithilfe eines Online-Scanners bestätigen??
Ein Scannerergebnis hat Grenzen, insbesondere bevor eine zuverlässige Erkennung möglich ist. Bevorzugen Sie die Herkunft des Pakets, Anbieterbestätigung und Überprüfung der Live-Laufzeit. Führen Sie keine nicht vertrauenswürdigen Exploit-Tools auf Produktionssystemen aus.
Wann sollte der öffentliche Zugang wiederhergestellt werden??
Stellen Sie den Zugriff wieder her, nachdem die relevanten Laufzeiten als gepatcht überprüft wurden, betroffene Prozesse wurden ersetzt, Wesentliche Funktionen bestehen die Tests und alle vermuteten Kompromisse wurden behoben. Überprüfen Sie die Rückrufzustellung und die Geschäftsvorgänge in der Warteschlange erneut, nachdem eine Einschränkung aufgehoben wurde.
Checkliste für Administratoraktionen
- Inventarisieren Sie jede PHP-Laufzeitumgebung und die Anwendungen, die sie bedient.
- Verfolgen Sie beide CVE-Kennungen in den Hinweisen zu PHP und Paketanbietern.
- Wählen Sie temporäre Belichtungssteuerungen, wenn das Patchen nicht möglich ist.
- Installieren Sie für jede betroffene Laufzeit einen verifizierten korrigierten Build.
- Starten Sie die relevanten Prozesse neu und testen Sie die tatsächlichen Webanwendungen.
- Untersuchen Sie verdächtige Aktivitäten unabhängig von der Patch-Aufgabe.
Die Priorität ist ein dokumentierter Pfad von der exponierten Laufzeit zum verifizierten korrigierten Dienst. Bis ein Fix für Ihre Paketquelle verfügbar ist, Treffen Sie die Entscheidung über Verfügbarkeit und Zugriffskontrolle explizit, anstatt eine nicht überprüfte Konfigurationsänderung als Schutz zu betrachten.
