# Blog: PHP2Shell, Server-Sicherheit und Notfallhilfe

> Blog zu PHP2Shell und Server-Sicherheit: Lage, Hosting, Erkennung, Härtung, sichere Entwicklung, Management und Entscheidungshilfen.

Quelle: https://phpsos.de/blog/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

Einordnung der Lage, Anleitungen für Admins und Entscheidungshilfen für die Geschäftsführung. Sortiert nach Thema, jeder Artikel mit Quellen.

- [PHP2Shell: Was belegt ist und was nicht](https://phpsos.de/blog/php2shell-was-belegt-ist/): Ein Faktencheck zu PHP2Shell: Welche Aussagen aus Primärquellen stammen, welche aus Medienberichten und welche Behauptungen sich nicht halten lassen.
- [Warum die PHP-Lücke vor dem Patch bekannt wurde](https://phpsos.de/blog/php-luecke-vorzeitig-bekannt/): Laut Berichten wurden Details zu PHP2Shell vor Ablauf des Embargos öffentlich. Wir erklären den Ablauf und was er für Ihre Patch-Planung bedeutet.
- [Behörden nehmen Websites vom Netz: Was Unternehmen daraus lernen](https://phpsos.de/blog/behoerden-webseiten-offline/): Mainz, die hessische Landesregierung und das BKA nahmen Websites vorsorglich vom Netz. Was Unternehmen daraus für die eigene Entscheidung lernen können.
- [BSI-Warnstufe Orange: Was die Einstufung bedeutet](https://phpsos.de/blog/bsi-warnstufe-orange-erklaert/): Das BSI stuft PHP2Shell mit 3 / Orange ein. Was die Skala aussagt, was nicht, und wie Unternehmen die Einstufung in Entscheidungen übersetzen.
- [Was CERT-EU und CERT-Bund zu PHP2Shell raten](https://phpsos.de/blog/cert-eu-empfehlungen-php/): Die offiziellen Stellen sind sich einig: sofort patchen, sonst isolieren. Wir vergleichen die Empfehlungen und zeigen, wie Isolieren praktisch aussieht.
- [Cloudflare-Schutzregeln gegen PHP2Shell: Was sie leisten und was nicht](https://phpsos.de/blog/cloudflare-waf-php2shell/): Cloudflare hat früh Schutzregeln gegen PHP2Shell ausgerollt. Warum das hilft, warum es das PHP-Update trotzdem nicht ersetzt und welche Einstellungen Sie prüfen sollten.
- [22,6 Millionen exponierte Instanzen: Zahlen richtig einordnen](https://phpsos.de/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel und andere nennen sehr unterschiedliche Zahlen zu PHP2Shell. Wir erklären, was gezählt wurde und welche Zahl für Sie wirklich zählt.
- [PHP2Shell in fünf Minuten: Briefing für die Geschäftsführung](https://phpsos.de/blog/php2shell-briefing-geschaeftsfuehrung/): Die PHP-Sicherheitslücke PHP2Shell auf einer Seite für Entscheider: Lage, Risiko, fünf Fragen an die IT und die Entscheidungen für heute.
- [Die PHP-Sicherheitslücke einfach erklärt](https://phpsos.de/blog/php-luecke-einfach-erklaert/): PHP2Shell für Nicht-Techniker: mit Alltagsbildern, einem kleinen Glossar und drei typischen Ausgangslagen, was Sie als Website-Betreiber tun sollten.
- [PHP2Shell: 15 Fragen von Hosting-Kunden](https://phpsos.de/blog/fragen-von-hosting-kunden/): Ihre Website liegt beim Hoster und Sie wollen wissen, was Sie bei PHP2Shell selbst tun müssen? Hier die 15 häufigsten Fragen mit kurzen Antworten.
- [Warum ein WordPress-Update gegen PHP2Shell nicht hilft](https://phpsos.de/blog/warum-wordpress-update-nicht-hilft/): Viele Betreiber haben nach den Schlagzeilen WordPress aktualisiert und fühlen sich sicher. Warum das bei PHP2Shell ins Leere geht und was stattdessen zählt.
- [PHP2Shell und Log4Shell: Was die Lücken gemeinsam haben](https://phpsos.de/blog/php2shell-und-log4shell/): Viele vergleichen PHP2Shell mit Log4Shell aus dem Jahr 2021. Was der Vergleich trägt, wo er hinkt und welche Lehren von damals heute helfen.
- [Massenscans nach ungepatchtem PHP: So laufen automatisierte Angriffe](https://phpsos.de/blog/automatisierte-massenscans/): Nach PHP2Shell suchen Angreifer das Internet automatisiert nach verwundbaren Servern ab. Wie das abläuft, warum Größe keine Rolle spielt und was Sie schützt.
- [Das Zeitfenster zwischen Patch und Angriff](https://phpsos.de/blog/zeitfenster-patch-angriff/): Bei PHP2Shell gab es Angriffsversuche schon vor dem Patch. Wir erklären die Phasen des Zeitfensters, wie Sie Ihr eigenes messen und wie Sie es verkürzen.
- [Nach PHP2Shell: Warum weitere Meldungen wahrscheinlich sind](https://phpsos.de/blog/weitere-php-meldungen/): PHP2Shell ist mit dem Patch vom 21. Oktober nicht abgeschlossen. Warum Folgemeldungen zu erwarten sind und wie Sie Ihr Team darauf einstellen.
- [PHP2Shell: Das Lagebild der ersten Woche](https://phpsos.de/blog/lagebild-erste-woche/): Eine Woche nach dem ersten beobachteten Angriffsversuch: der Stand zu Patches, Behördenwarnungen, Angriffen und Abschaltungen, sauber nach Quellen getrennt.
- [Gefährliche Falschtipps zu PHP2Shell, die gerade kursieren](https://phpsos.de/blog/gefaehrliche-falschtipps/): Cookies blockieren, Fehlermeldungen verstecken, nur das CMS aktualisieren: Neun Ratschläge zu PHP2Shell, die falsche Sicherheit erzeugen, und was wirklich zählt.
- [PHP-Version im Hosting-Kundenbereich ändern](https://phpsos.de/blog/php-version-hosting-aendern/): Wie Sie im Kundenbereich Ihres Hosters die PHP-Version umstellen, welche Version Sie wählen und was Sie vorher und nachher prüfen.
- [Debian und Ubuntu: Ist mein PHP-Paket gepatcht?](https://phpsos.de/blog/debian-ubuntu-paket-gepatcht/): Welche PHP-Pakete Debian und Ubuntu gegen PHP2Shell korrigiert haben, wie Sie den installierten Stand exakt vergleichen und woran der Nachweis scheitert.
- [RHEL, AlmaLinux und Rocky Linux: PHP-Patch prüfen](https://phpsos.de/blog/rhel-almalinux-rocky-php/): Was Red Hat zu PHP2Shell veröffentlicht hat, wie Sie auf RHEL und den Nachbauten den Paketstand belegen und warum ein Reload nicht genügt.
- [Das sury.org-Repository: PHP-Pakete aus Drittquelle](https://phpsos.de/blog/sury-repository-php/): Viele Debian- und Ubuntu-Server beziehen PHP aus dem sury-Repository. Was das für Updates, Nachweise und alte PHP-Versionen nach PHP2Shell bedeutet.
- [Das Remi-Repository: PHP auf RHEL-Systemen aktuell halten](https://phpsos.de/blog/remi-repository-php/): Remi liefert aktuelle PHP-Versionen für die RHEL-Familie, als Modul oder parallel installierbar. So prüfen Sie den Stand nach PHP2Shell und vermeiden vergessene Zweige.
- [Warum php -v nach dem Update dieselbe Nummer zeigt](https://phpsos.de/blog/php-v-zeigt-alte-nummer/): Das Update lief, doch php -v meldet die alte Version. Meist ist das ein Backport und kein Fehler. So unterscheiden Sie harmlose von echten Problemen.
- [CVE-Nummern im Paket-Changelog nachweisen](https://phpsos.de/blog/cve-im-changelog-nachweisen/): Wer Geschäftsführung, Prüfern oder Versicherern einen PHP-Patch belegen muss, braucht mehr als eine Versionsnummer. So wird der Changelog-Eintrag zum Nachweis.
- [Hoster wechseln nach einem Sicherheitsvorfall: Worauf achten?](https://phpsos.de/blog/hoster-wechseln-nach-vorfall/): Nach einem Vorfall ist der Wunsch nach einem neuen Hoster verständlich. Damit der Wechsel nicht den Angreifer mitnimmt, kommt es auf Reihenfolge und Auswahl an.
- [Mehrere PHP-Versionen auf einem Server: Jede einzeln patchen](https://phpsos.de/blog/mehrere-php-versionen-server/): Auf vielen Servern laufen drei, vier oder mehr PHP-Installationen nebeneinander. Nach PHP2Shell muss jede gefunden, aktualisiert und neu gestartet werden.
- [Alte PHP-Versionen im Hosting-Panel abschalten](https://phpsos.de/blog/alte-php-versionen-abschalten/): PHP2Shell ist ein guter Anlass, alte PHP-Versionen loszuwerden. So gehen Sie in drei Phasen vor, damit keine Website und kein Cronjob unbemerkt ausfällt.
- [Plesk: PHP-Handler verstehen (FPM, FastCGI, Apache-Modul)](https://phpsos.de/blog/plesk-php-handler/): Welchen PHP-Handler Plesk für eine Website nutzt, entscheidet über Isolation, Konfiguration und Risiko. Ein Vergleich mit Blick auf PHP2Shell.
- [CloudLinux und alt-php: Was Hosting-Kunden wissen sollten](https://phpsos.de/blog/cloudlinux-alt-php/): Auf CloudLinux-Servern laufen Websites oft mit eigenen alt-php-Paketen. Jede dieser Versionen braucht ihren eigenen Patch, und nur der Serverbetreiber kann ihn einspielen.
- [PHP auf NAS, Firewalls und Appliances: die vergessenen Systeme](https://phpsos.de/blog/php-auf-nas-und-appliances/): Nicht nur Webserver nutzen PHP. Auch NAS-Systeme, Firewalls und Fachgeräte mit Weboberfläche können betroffen sein. Patchen kann dort meist nur der Hersteller, die Erreichbarkeit regeln Sie selbst.
- [PHP bei Cloud- und PaaS-Anbietern: Wer patcht die Laufzeit?](https://phpsos.de/blog/paas-php-laufzeit/): Auf Plattformdiensten hängt der PHP-Patch vom Betriebsmodell ab. Entscheidend ist die Laufzeit, die tatsächlich ausliefert, nicht die lokale Umgebung oder der Anwendungscode.
- [Offizielle PHP-Docker-Images: Tags, Digests und Neubau](https://phpsos.de/blog/offizielle-php-docker-images/): Ein Tag des offiziellen PHP-Images ist ein Zeiger, der mit der Zeit auf neue Stände wandert. Wer weiß, was Tag, Variante und Digest bedeuten, wählt das richtige Image und kann den Patch-Stand belegen.
- [CI/CD: PHP-Images automatisch neu bauen](https://phpsos.de/blog/php-images-in-ci-neu-bauen/): Ein Image veraltet auch ohne Codeänderung. Mit zeitgesteuerten Builds, einer Versionsprüfung und einem Rollout per Digest kommen PHP-Patches zuverlässig in Produktion.
- [Langzeitsupport für alte PHP-Versionen: Optionen und Grenzen](https://phpsos.de/blog/langzeitsupport-alte-php-versionen/): Wer nicht sofort von PHP 8.1 oder älter wechseln kann, findet Langzeitsupport bei Distributionen, Drittanbietern und kommerziellen Diensten. Was diese Wege leisten, was Sie schriftlich brauchen und wo die Grenzen liegen.
- [PHP unter Windows aktualisieren](https://phpsos.de/blog/php-unter-windows-aktualisieren/): Unter Windows gibt es kein automatisches PHP-Update. Wer die richtige Variante wählt, den Download prüft und alle Prozesse neu startet, bringt den PHP2Shell-Patch sauber auf jeden Rechner.
- [Warnsignal: Der Webserver startet eine Shell](https://phpsos.de/blog/webserver-startet-shell/): Startet ein PHP-FPM- oder Webserver-Prozess eine Shell, ist das eines der stärksten Warnsignale für einen Einbruch. So prüfen Sie den Prozessbaum, ordnen Ausnahmen ein und überwachen das Muster dauerhaft.
- [Verdächtige Prozesse auf Linux-Servern finden](https://phpsos.de/blog/verdaechtige-prozesse-linux/): Schadprozesse tarnen sich mit harmlosen Namen, laufen aus temporären Ordnern oder von gelöschten Dateien. Mit wenigen lesenden Befehlen finden Sie Auffälligkeiten und ordnen sie ein.
- [Versteckte Cronjobs als Hintertür erkennen](https://phpsos.de/blog/cronjobs-als-hintertuer/): Angreifer nutzen geplante Aufgaben, um nach einer Bereinigung zurückzukehren. So prüfen Sie Crontabs, cron-Verzeichnisse, systemd-Timer und at-Aufträge vollständig und erkennen verdächtige Einträge.
- [Kürzlich geänderte Dateien auf dem Webserver finden](https://phpsos.de/blog/geaenderte-dateien-finden/): Nach einem möglichen Einbruch zählt, was sich auf dem Server verändert hat. So suchen Sie nach Zeitfenstern, nutzen mtime und ctime richtig und gleichen gegen Pakete, Git und Backups ab.
- [PHP-Dateien im Upload-Ordner: Fundstellen richtig deuten](https://phpsos.de/blog/php-dateien-im-upload-ordner/): Eine PHP-Datei im Upload-Ordner ist fast immer ein Alarmzeichen, aber nicht jede ist Schadcode. So bewerten Sie den Fund, ohne Spuren zu zerstören, und klären, ob sie jemand aufgerufen hat.
- [Verschleierten PHP-Code erkennen](https://phpsos.de/blog/verschleierter-php-code/): Unlesbarer PHP-Code mit eval und base64_decode ist ein klassisches Zeichen für eingeschleusten Schadcode. Welche Muster Sie suchen, wie Sie sie gefahrlos finden und wann Verschleierung legitim ist.
- [Ausgehende Verbindungen eines Servers prüfen](https://phpsos.de/blog/ausgehende-verbindungen-pruefen/): Ein Webserver antwortet vor allem auf Anfragen. Baut er selbst Verbindungen zu unbekannten Zielen auf, kann das Steuerung durch Angreifer oder Datenabfluss bedeuten. So prüfen und begrenzen Sie ausgehenden Verkehr.
- [Fremde Admin-Konten in CMS und Server finden](https://phpsos.de/blog/fremde-admin-konten-finden/): Ein unbekannter Administrator ist oft die einfachste Hintertür. So suchen Sie Ebene für Ebene nach fremden Konten, auch nach solchen, die die Oberfläche versteckt.
- [Unbekannte SSH-Schlüssel finden und entfernen](https://phpsos.de/blog/ssh-schluessel-pruefen/): Ein eingeschleuster SSH-Schlüssel öffnet Angreifern die Tür, auch wenn alle Passwörter geändert sind. So finden Sie jede authorized_keys-Datei und prüfen jeden Eintrag.
- [Kryptominer auf dem Webserver: Anzeichen und Vorgehen](https://phpsos.de/blog/kryptominer-auf-dem-server/): Dauerhaft volle CPU, ohne dass mehr Besucher kommen: Das kann ein Kryptominer sein. So prüfen Sie die Last, finden den Prozess und seine Neustartmechanismen und gehen geordnet vor.
- [Der Server verschickt Spam: Ursachen finden](https://phpsos.de/blog/server-verschickt-spam/): Unzustellbare Mails, Sperrlisten, Beschwerden: Wenn der eigene Server Spam versendet, steckt meist ein Skript oder ein gekapertes Postfach dahinter. So finden Sie die Quelle.
- [SEO-Spam und fremde Seiten im Google-Index](https://phpsos.de/blog/seo-spam-im-google-index/): Plötzlich ranken Seiten zu Arzneimitteln oder Markenware unter Ihrer Domain. So finden Sie heraus, woher der SEO-Spam kommt, und bekommen ihn wieder aus dem Index.
- [Die Website leitet auf fremde Seiten um](https://phpsos.de/blog/website-leitet-um/): Besucher landen auf Gewinnspielen oder dubiosen Shops, Sie selbst sehen aber nichts? So finden Sie die Schicht, in der die Weiterleitung steckt, und beseitigen sie.
- [Beweise sichern, bevor Sie den Server neu aufsetzen](https://phpsos.de/blog/beweise-sichern-vor-neuinstallation/): Ein Neuaufbau beseitigt den Angreifer, aber auch alle Spuren. Wer vorher eine Stunde in die Beweissicherung investiert, kann später sagen, was passiert ist.
- [Die Zeitleiste eines Vorfalls erstellen](https://phpsos.de/blog/zeitleiste-eines-vorfalls/): Wann kam der Angreifer, was tat er, wann wurde es bemerkt? Eine saubere Zeitleiste beantwortet diese Fragen und ist Grundlage für Meldungen, Versicherung und Bericht.
- [CMS-Kerndateien mit dem Original vergleichen](https://phpsos.de/blog/cms-kerndateien-vergleichen/): Der Vergleich mit einem sauberen Original zeigt jede veränderte Datei, unabhängig davon, ob ein Scanner sie kennt. So bauen Sie den Abgleich für WordPress, Composer-Projekte und Systempakete auf.
- [Die Datenbank auf eingeschleusten Code prüfen](https://phpsos.de/blog/datenbank-auf-schadcode-pruefen/): Wer nur Dateien prüft, übersieht die Hälfte. So durchsuchen Sie Inhalte, Einstellungen, Trigger und Konten der Datenbank nach eingeschleustem Code, lesend und auf einer Kopie.
- [Malware-Scanner für Websites: Was sie finden und was nicht](https://phpsos.de/blog/grenzen-von-malware-scannern/): Der Scanner meldet nichts, also alles gut? Nicht unbedingt. Welche Arten von Website-Scannern es gibt, was jede sieht und was sie grundsätzlich nicht sehen kann.
- [PHP-FPM-Pools pro Website isolieren](https://phpsos.de/blog/php-fpm-pools-isolieren/): Ein eigener Pool je Website ist der Anfang, nicht das Ende. So prüfen Sie bestehende Pools und härten Sockets, Endungen, Status-Seiten, Ressourcen und Logs.
- [memory_limit richtig setzen](https://phpsos.de/blog/memory-limit-richtig-setzen/): memory_limit begrenzt den Speicher je PHP-Anfrage. Nach PHP2Shell rät php.net vorübergehend zum Gegenteil. Was im Normalbetrieb, im Übergang und nach dem Update gilt.
- [post_max_size und upload_max_filesize sinnvoll begrenzen](https://phpsos.de/blog/post-max-size-upload-limits/): Upload-Grenzen wirken an drei Stellen: im Webserver, in PHP und in der Anwendung. So setzen Sie die Werte stimmig, auch mit den Übergangswerten von php.net zu PHP2Shell.
- [session.upload_progress abschalten: richtig und dauerhaft](https://phpsos.de/blog/session-upload-progress-abschalten/): Die Abhilfe gegen CVE-2026-115560 und eine der PHP2Shell-Übergangsmaßnahmen ist schnell gesetzt. Damit sie hält, muss sie an der richtigen Stelle stehen, gesperrt sein und nach jedem Update wieder geprüft werden.
- [expose_php und Server-Header: Versionsangaben verbergen](https://phpsos.de/blog/expose-php-versionsangaben/): PHP, Nginx und Apache nennen ihre Versionsnummer standardmäßig in jeder Antwort. Das schützt nicht vor Angriffen, liefert Scannern aber eine bequeme Trefferliste. So stellen Sie es ab und behalten den Überblick trotzdem.
- [display_errors off: Fehlerausgaben in der Produktion abschalten](https://phpsos.de/blog/display-errors-produktion/): Sichtbare PHP-Fehlermeldungen verraten Pfade, Datenbanknamen und Versionen. So schalten Sie sie in PHP, im Framework und im Webserver ab, ohne die Fehler aus den Augen zu verlieren.
- [php_admin_value: Einstellungen gegen Überschreiben sperren](https://phpsos.de/blog/php-admin-value-sperren/): Eine Sicherheitseinstellung nützt wenig, wenn die Anwendung sie mit einer Zeile Code wieder ändert. Mit php_admin_value und php_admin_flag legen Sie Werte für PHP-FPM und Apache verbindlich fest.
- [Speichergrenzen mit systemd und cgroups setzen](https://phpsos.de/blog/speichergrenzen-systemd-cgroups/): php.net empfiehlt als PHP2Shell-Übergangsmaßnahme memory_limit=-1 und eine Speichergrenze außerhalb von PHP. So setzen Sie diese Grenze mit systemd und cgroups, ohne dass ein einzelner Worker den ganzen Dienst mitreißt.
- [Nginx für PHP sicher konfigurieren](https://phpsos.de/blog/nginx-fuer-php-absichern/): Die meisten Schwachstellen in Nginx-Setups für PHP stecken nicht in Nginx, sondern in wenigen Zeilen der PHP-Location. So konfigurieren Sie die Übergabe an PHP-FPM so, dass nur gewollte Skripte ausgeführt werden.
- [Apache für PHP sicher konfigurieren](https://phpsos.de/blog/apache-fuer-php-absichern/): Apache ist flexibel, und genau das macht ihn anfällig für Fehlkonfiguration. So binden Sie PHP über PHP-FPM an, schließen .htaccess als Hintertür und stellen die wichtigsten Kernoptionen sicher ein.
- [PHP-Ausführung in Upload-Ordnern verbieten](https://phpsos.de/blog/php-in-uploads-verbieten/): Eine Webshell braucht zwei Dinge: einen Ordner, in den sie geschrieben werden kann, und einen Server, der sie ausführt. So nehmen Sie ihr das zweite, und zwar in jedem beschreibbaren Ordner, nicht nur in uploads.
- [Upload-Anfragen am Rand filtern: Chancen und Risiken](https://phpsos.de/blog/upload-anfragen-am-rand-filtern/): Fachautoren schlagen vor, Upload-Anfragen außerhalb echter Upload-Pfade am Proxy zu blockieren, bis PHP gepatcht ist. Das kann helfen, aber auch Formulare und Bestellungen lahmlegen. So gehen Sie kontrolliert vor.
- [ModSecurity und OWASP Core Rule Set einsetzen](https://phpsos.de/blog/modsecurity-owasp-crs/): Eine eigene Web Application Firewall mit ModSecurity und dem OWASP Core Rule Set ist kostenlos und mächtig, aber kein Selbstläufer. So wählen Sie die Engine, starten ohne Ausfälle und stimmen die Regeln ab.
- [Fail2ban für Webserver einrichten](https://phpsos.de/blog/fail2ban-fuer-webserver/): Fail2ban sperrt Adressen, die in den Logs wiederholt auffallen. Für Webserver bringt es fertige Filter mit, und mit wenigen Zeilen kommen eigene dazu. So richten Sie es ein, ohne sich selbst oder Ihre Kunden auszusperren.
- [Firewall für Webserver: Nur nötige Ports öffnen](https://phpsos.de/blog/firewall-fuer-webserver/): Ein Webserver braucht nach außen meist nur zwei Ports. Trotzdem lauschen auf vielen Servern Datenbanken, PHP-FPM oder Verwaltungsoberflächen im Internet. So finden Sie offene Dienste und schließen, was nicht gebraucht wird.
- [Automatische Sicherheitsupdates auf Linux-Servern](https://phpsos.de/blog/automatische-sicherheitsupdates/): Laut Berichten lieferten Distributionen PHP-Backports teils noch am 21. Oktober 2026 aus, dem Tag der Patches. Wer automatische Sicherheitsupdates nutzt, hatte sie schnell auf dem Server. Damit sie auch wirken, braucht es Neustarts, Drittquellen und Kontrolle.
- [Least Privilege: Rechte des Webserver-Benutzers](https://phpsos.de/blog/rechte-des-webserver-benutzers/): Eingeschleuster Code läuft mit den Rechten des Webserver-Benutzers. Was dieses Konto darf, entscheidet, wie weit ein Angreifer kommt. So beschränken Sie Shell, sudo, Cron, Datenbank und Dateisystem auf das Nötige.
- [Admin-Bereiche per IP, VPN oder Zusatzschutz abschirmen](https://phpsos.de/blog/admin-bereiche-abschirmen/): Warum das Backend einer Website nicht für die ganze Welt erreichbar sein muss und wie Sie es per IP-Freigabe, VPN oder vorgeschalteter Anmeldung abschirmen, ohne sich selbst auszusperren.
- [TLS und HTTPS richtig konfigurieren](https://phpsos.de/blog/tls-https-richtig-konfigurieren/): Welche TLS-Versionen und Cipher Suites ein Webserver heute anbieten sollte, woran sich die Empfehlungen orientieren und wie Sie Nginx, Apache und ausgehende PHP-Verbindungen prüfen.
- [CIS-Benchmarks und BSI-Bausteine für Webserver](https://phpsos.de/blog/cis-benchmarks-bsi-bausteine/): Welche Härtungsstandards es für Linux-Webserver gibt, wie sich CIS-Benchmarks und IT-Grundschutz-Bausteine unterscheiden und wie Sie daraus eine prüfbare Vorgabe für Ihre PHP-Server machen.
- [Passwörter in PHP sicher speichern: password_hash richtig einsetzen](https://phpsos.de/blog/passwoerter-in-php-speichern/): Wie Entwickler Passwörter in PHP mit password_hash und password_verify speichern, das passende Verfahren wählen und alte MD5- oder SHA-1-Hashes ohne Passwort-Reset für alle Nutzer ablösen.
- [CSRF-Schutz in PHP-Anwendungen](https://phpsos.de/blog/csrf-schutz-php/): Wie Entwickler Cross-Site Request Forgery in PHP-Anwendungen verhindern: Tokens für jede verändernde Anfrage, Herkunftsprüfung im Header und SameSite-Cookies als zusätzliche Schicht.
- [Eingaben in PHP validieren und filtern mit filter_var](https://phpsos.de/blog/eingaben-validieren-php/): Wie Entwickler Eingaben in PHP mit filter_var, filter_input_array und Erlaubnislisten prüfen, welche Filter veraltet sind und warum Validierung Prepared Statements und Ausgabekodierung nicht ersetzt.
- [Command Injection in PHP verhindern](https://phpsos.de/blog/command-injection-php/): Wie Entwickler Command Injection in PHP vermeiden: Systembefehle durch PHP-Funktionen ersetzen, proc_open ohne Shell nutzen, Argumente prüfen und gefährliche Stellen im Bestandscode finden.
- [Server-Side Request Forgery (SSRF) in PHP verhindern](https://phpsos.de/blog/ssrf-in-php/): Wie Entwickler verhindern, dass eine PHP-Anwendung im Auftrag Fremder interne Systeme abfragt: Erlaubnislisten, Protokollbeschränkung, Prüfung der aufgelösten Adresse und Grenzen im Netzwerk.
- [XML External Entities (XXE) in PHP verhindern](https://phpsos.de/blog/xxe-in-php/): Wie Entwickler XML in PHP sicher verarbeiten: Standardverhalten von libxml, riskante Optionen wie LIBXML_NOENT, Schutz mit Entity-Loader und LIBXML_NO_XXE und typische versteckte XML-Eingänge.
- [Type Juggling in PHP: Lose Vergleiche als Sicherheitsrisiko](https://phpsos.de/blog/type-juggling-php/): Warum lose Vergleiche mit == in PHP zu Sicherheitslücken führen können, was sich mit PHP 8.0 geändert hat und wie Sie Vergleiche in Logins, Tokens und Berechtigungen robust schreiben.
- [Sichere Zufallszahlen und Tokens in PHP mit random_bytes](https://phpsos.de/blog/sichere-tokens-php/): Wie Entwickler in PHP Tokens für Passwort-Links, API-Schlüssel und Einmalcodes erzeugen: kryptografisch sichere Quellen, ausreichende Länge, Speicherung als Hash und begrenzte Gültigkeit.
- [Zugangsdaten und .env-Dateien richtig schützen](https://phpsos.de/blog/env-dateien-schuetzen/): Wie Sie Datenbankpasswörter, API-Schlüssel und andere Geheimnisse in PHP-Projekten schützen: .env-Dateien außerhalb des Webroots, Sperren im Webserver, enge Rechte und geordneter Austausch nach einem Vorfall.
- [Öffentlicher .git-Ordner: Ein unterschätztes Datenleck](https://phpsos.de/blog/git-ordner-oeffentlich/): Warum ein per Git ausgerollter Webroot den kompletten Quellcode samt Historie preisgeben kann, wie Sie das prüfen, sofort sperren und das Deployment dauerhaft ohne .git-Ordner aufbauen.
- [Backup-Dateien im Webroot: .zip, .sql und .bak](https://phpsos.de/blog/backup-dateien-im-webroot/): Warum Datenbank-Dumps, Archive und Sicherungskopien im öffentlichen Verzeichnis zu den häufigsten Datenlecks gehören, wie Sie sie finden, sperren und klären, ob sie abgerufen wurden.
- [phpinfo()-Dateien: Warum sie verschwinden müssen](https://phpsos.de/blog/phpinfo-dateien-entfernen/): Nach PHP2Shell legen viele Admins schnell eine info.php an. Warum solche Dateien ein Datenleck sind, wie Sie sie finden und welche Prüfwege besser sind.
- [Abhängigkeiten aktuell halten: Composer, npm und Plugins](https://phpsos.de/blog/abhaengigkeiten-aktuell-halten/): Ein Projekt besteht aus drei Paketwelten: Composer, npm und CMS-Plugins. Wie Sie alle drei mit einem festen Rhythmus, klarer Zuständigkeit und Tests aktuell halten.
- [Sicherheits-Code-Review für PHP-Projekte](https://phpsos.de/blog/sicherheits-code-review-php/): Wie Teams eigenen PHP-Code gezielt auf Sicherheitslücken durchsehen: Arten von Reviews, kritische Funktionen, sinnvolle Werkzeuge und eine Prüfliste.
- [Sicher loggen: Fehler protokollieren ohne Datenleck](https://phpsos.de/blog/sicher-loggen-php/): Logs helfen bei Fehlersuche und Forensik, werden aber schnell selbst zum Datenleck. Was PHP-Anwendungen protokollieren sollten, was nie und wie man Logs schützt.
- [REST-APIs in PHP absichern](https://phpsos.de/blog/rest-api-php-absichern/): Schnittstellen sind oft schlechter geschützt als die Website davor. Die wichtigsten Regeln für REST-APIs in PHP, von der Objektberechtigung bis zur Ratenbegrenzung.
- [IT-Dienstleister-Verträge: Sicherheitspflichten klar regeln](https://phpsos.de/blog/dienstleistervertrag-sicherheit/): PHP2Shell hat gezeigt, wie oft unklar ist, wer patchen muss. Welche Sicherheitspflichten in Verträge mit Agentur, Hoster und IT-Dienstleister gehören.
- [Auftragsverarbeitung, wenn Dienstleister auf Server zugreifen](https://phpsos.de/blog/auftragsverarbeitung-serverzugriff/): Wer Externe an Server mit Kundendaten lässt, braucht meist einen AVV. Was Art. 28 DSGVO verlangt und wie Sie Zugriffe im Notfall datenschutzgerecht organisieren.
- [Schwachstellenmanagement für den Mittelstand](https://phpsos.de/blog/schwachstellenmanagement-mittelstand/): Kein Mittelständler kann jede Meldung sofort abarbeiten. Ein schlanker Kreislauf aus Erfassen, Bewerten, Entscheiden und Nachweisen sorgt dafür, dass das Wichtige zuerst passiert.
- [Wissen, was läuft: Inventar aller Websites und Server](https://phpsos.de/blog/inventar-websites-server/): Bei PHP2Shell scheiterten viele nicht am Patch, sondern an der Frage, wo überhaupt PHP läuft. So bauen Sie ein Inventar aller Websites und Server auf.
- [Patch-Management als Prozess statt Feuerwehr](https://phpsos.de/blog/patch-management-prozess/): Wer nur patcht, wenn es brennt, verliert im Ernstfall Zeit. Wie ein Patch-Management-Prozess mit festen Klassen, Fenstern und Nachweisen Routine und Notfall verbindet.
- [Notfallkontakte: Wer muss wann informiert werden?](https://phpsos.de/blog/notfallkontakte-liste/): Im Ernstfall zählt, wen man erreicht und wann. Wie Sie eine Liste der IT-Notfallkontakte aufbauen, mit Auslösern, Stellvertretungen und den Angaben, die jeder Anruf braucht.
- [Was ein gehackter Server kostet: Die Kostenposten](https://phpsos.de/blog/kostenposten-eines-hacks/): Ein gehackter Webserver verursacht mehr Kosten als die Reparatur. Welche Kostenposten anfallen und wie Sie mit eigenen Zahlen ein Budget für Vorsorge begründen.
- [Kunden nach einem Vorfall informieren](https://phpsos.de/blog/kunden-nach-vorfall-informieren/): Ob Pflicht oder freiwillig: Wie Sie nach einem Vorfall entscheiden, wen Sie informieren, welche Kanäle sicher sind und wie Ihr Kundenservice vorbereitet ist.
- [Die Lieferkette im Web: Agentur, Hoster, Plugin-Anbieter](https://phpsos.de/blog/lieferkette-agentur-hoster/): PHP2Shell hat gezeigt, wie viele Glieder zwischen einem Patch und Ihrer Website liegen. Wie Sie die Lieferkette Ihrer Website kennen, absichern und Ausfälle einzelner Glieder abfangen.
- [Sicherheitsbewusstsein für Admins und Redakteure: Security Awareness im Web-Team](https://phpsos.de/blog/sicherheitsbewusstsein-redaktion/): Wer Websites pflegt, entscheidet täglich über Sicherheit, oft ohne es zu merken. So schulen Sie Admins und Redakteure rollengerecht und ohne Folienschlacht.
- [Notfallübung am Tisch: Einen Webserver-Vorfall durchspielen](https://phpsos.de/blog/notfalluebung-am-tisch/): Eine Übung am Tisch kostet einen Nachmittag und zeigt, ob Ihr Notfallplan trägt. Hier finden Sie ein fertiges Drehbuch für einen Vorfall auf einem PHP-Webserver.
- [ISO 27001 und TISAX: Was Webserver betrifft](https://phpsos.de/blog/iso-27001-tisax-webserver/): Wer ein ISMS nach ISO 27001 betreibt oder ein TISAX-Label hat, muss Webserver mitdenken. Hier steht, welche Anforderungen sie berühren und welche Nachweise nach PHP2Shell zählen.
- [VdS 10000: Informationssicherheit für kleine und mittlere Unternehmen](https://phpsos.de/blog/vds-10000-kmu/): Die VdS 10000 ist ein schlanker Rahmen für Informationssicherheit im Mittelstand. Was sie verlangt, was 2025 neu kam und was das für Websites und Webserver heißt.
- [Lessons Learned: Nach dem Vorfall besser werden](https://phpsos.de/blog/lessons-learned-nach-vorfall/): Nach dem Vorfall ist vor dem nächsten. Eine strukturierte Nachbesprechung ohne Schuldzuweisung macht aus einer schlechten Woche einen messbaren Fortschritt.
- [Patchen, abschalten oder abwarten? Eine Entscheidungshilfe bei der PHP-Lücke](https://phpsos.de/blog/patchen-abschalten-abwarten/): Bei einer kritischen PHP-Lücke müssen Verantwortliche schnell entscheiden. Diese Hilfe ordnet die drei Optionen, nennt Kriterien und zeigt, wann Abwarten vertretbar ist.
- [WAF oder Update: Warum Sie beides brauchen](https://phpsos.de/blog/waf-oder-update/): Eine Web Application Firewall kann Angriffe abfangen, schließt aber keine Lücke im PHP-Interpreter. Wann eine WAF hilft, wo sie endet und wie Sie beides sinnvoll kombinieren.
- [Server neu aufsetzen oder bereinigen? Die Entscheidung nach einem Befall](https://phpsos.de/blog/neu-aufsetzen-oder-bereinigen/): Nach einem Einbruch stehen zwei Wege offen: den Server bereinigen oder neu aufbauen. Welche Kriterien entscheiden, und warum die Reihenfolge wichtiger ist als die Wahl.
- [Selbst beheben oder Dienstleister holen? Eine ehrliche Abwägung](https://phpsos.de/blog/selbst-beheben-oder-dienstleister/): Nicht jede Sicherheitslage braucht externe Hilfe. Mit diesen Kriterien und einem kurzen Selbsttest entscheiden Sie, ob Ihr Team PHP2Shell allein bewältigt oder Unterstützung braucht.
- [Einen IT-Sicherheitsdienstleister auswählen: 12 Fragen vor dem Auftrag](https://phpsos.de/blog/sicherheitsdienstleister-auswaehlen/): Unter Zeitdruck einen guten Sicherheitsdienstleister zu finden ist schwer. Diese zwölf Fragen helfen, Angebote sachlich zu vergleichen, ohne auf Werbeversprechen hereinzufallen.
- [Managed Hosting oder eigener Server? Der Sicherheitsvergleich](https://phpsos.de/blog/managed-oder-eigener-server/): PHP2Shell war ein Stresstest für jedes Betriebsmodell. Der Vergleich zeigt, wann Managed Hosting sicherer ist, wann der eigene Server, und welche Mischformen sich bewähren.
- [PHP-Upgrade oder Backport? Die Entscheidung für Altsysteme](https://phpsos.de/blog/php-upgrade-oder-backport/): Für alte PHP-Versionen gibt es nach PHP2Shell mehrere Wege: Backport der Distribution, Drittquelle, Quell-Patch, Langzeitsupport oder Upgrade. Was jeder Weg taugt und wie lange er trägt.
- [Nach dem Hack das CMS wechseln? Wann es hilft und wann nicht](https://phpsos.de/blog/cms-wechsel-nach-hack/): Nach einem Einbruch ist das Vertrauen ins CMS oft weg. Doch ein neues System löst selten die eigentliche Ursache. Wann der Wechsel sinnvoll ist und wie er sauber gelingt.
- [Statische Websites: Weniger PHP, weniger Angriffsfläche](https://phpsos.de/blog/statische-website-alternative/): Eine statische Website liefert fertige HTML-Dateien aus und braucht kein PHP auf dem Server. Das senkt die Angriffsfläche deutlich, bringt aber eigene Grenzen und Pflichten mit.
- [Pentest, Bug Bounty oder Schwachstellenscan? Das passende Prüfverfahren wählen](https://phpsos.de/blog/pentest-bugbounty-scan/): Scan, Penetrationstest und Bug Bounty prüfen Websites auf ganz unterschiedliche Weise. Was jedes Verfahren leistet, wo es versagt und welche Reihenfolge für Ihr Unternehmen passt.