113 Artikel

Blog: PHP2Shell, Server-Sicherheit und Notfallhilfe

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

WhatsApp-Notfall

Lage und Einordnung Hosting und Distributionen Erkennung und Forensik Härtung und Konfiguration Sichere Entwicklung Management und Recht Entscheidungshilfen

Lage und Einordnung

17 Artikel

001

PHP2Shell: Was belegt ist und was nicht

Ein Faktencheck zu PHP2Shell: Welche Aussagen aus Primärquellen stammen, welche aus Medienberichten und welche Behauptungen sich nicht halten lassen.

Weiterlesen →002

Warum die PHP-Lücke vor dem Patch bekannt wurde

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.

Weiterlesen →003

Behörden nehmen Websites vom Netz: Was Unternehmen daraus lernen

Mainz, die hessische Landesregierung und das BKA nahmen Websites vorsorglich vom Netz. Was Unternehmen daraus für die eigene Entscheidung lernen können.

Weiterlesen →004

BSI-Warnstufe Orange: Was die Einstufung bedeutet

Das BSI stuft PHP2Shell mit 3 / Orange ein. Was die Skala aussagt, was nicht, und wie Unternehmen die Einstufung in Entscheidungen übersetzen.

Weiterlesen →005

Was CERT-EU und CERT-Bund zu PHP2Shell raten

Die offiziellen Stellen sind sich einig: sofort patchen, sonst isolieren. Wir vergleichen die Empfehlungen und zeigen, wie Isolieren praktisch aussieht.

Weiterlesen →006

Cloudflare-Schutzregeln gegen PHP2Shell: Was sie leisten und was nicht

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.

Weiterlesen →007

22,6 Millionen exponierte Instanzen: Zahlen richtig 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.

Weiterlesen →008

PHP2Shell in fünf Minuten: Briefing für die Geschäftsführung

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.

Weiterlesen →009

Die PHP-Sicherheitslücke einfach erklärt

PHP2Shell für Nicht-Techniker: mit Alltagsbildern, einem kleinen Glossar und drei typischen Ausgangslagen, was Sie als Website-Betreiber tun sollten.

Weiterlesen →010

PHP2Shell: 15 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.

Weiterlesen →011

Warum ein WordPress-Update gegen PHP2Shell 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.

Weiterlesen →012

PHP2Shell und Log4Shell: Was die Lücken gemeinsam haben

Viele vergleichen PHP2Shell mit Log4Shell aus dem Jahr 2021. Was der Vergleich trägt, wo er hinkt und welche Lehren von damals heute helfen.

Weiterlesen →013

Massenscans nach ungepatchtem PHP: So laufen automatisierte Angriffe

Nach PHP2Shell suchen Angreifer das Internet automatisiert nach verwundbaren Servern ab. Wie das abläuft, warum Grösse keine Rolle spielt und was Sie schützt.

Weiterlesen →014

Das Zeitfenster zwischen Patch und 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.

Weiterlesen →015

Nach PHP2Shell: Warum weitere Meldungen wahrscheinlich sind

PHP2Shell ist mit dem Patch vom 21. Oktober nicht abgeschlossen. Warum Folgemeldungen zu erwarten sind und wie Sie Ihr Team darauf einstellen.

Weiterlesen →016

PHP2Shell: Das Lagebild der ersten Woche

Eine Woche nach dem ersten beobachteten Angriffsversuch: der Stand zu Patches, Behördenwarnungen, Angriffen und Abschaltungen, sauber nach Quellen getrennt.

Weiterlesen →017

Gefährliche Falschtipps zu PHP2Shell, die gerade kursieren

Cookies blockieren, Fehlermeldungen verstecken, nur das CMS aktualisieren: Neun Ratschläge zu PHP2Shell, die falsche Sicherheit erzeugen, und was wirklich zählt.

Weiterlesen →

Hosting und Distributionen

18 Artikel

018

PHP-Version im Hosting-Kundenbereich ändern

Wie Sie im Kundenbereich Ihres Hosters die PHP-Version umstellen, welche Version Sie wählen und was Sie vorher und nachher prüfen.

Weiterlesen →019

Debian und Ubuntu: Ist mein PHP-Paket gepatcht?

Welche PHP-Pakete Debian und Ubuntu gegen PHP2Shell korrigiert haben, wie Sie den installierten Stand exakt vergleichen und woran der Nachweis scheitert.

Weiterlesen →020

RHEL, AlmaLinux und Rocky Linux: PHP-Patch prüfen

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.

Weiterlesen →021

Das sury.org-Repository: PHP-Pakete aus Drittquelle

Viele Debian- und Ubuntu-Server beziehen PHP aus dem sury-Repository. Was das für Updates, Nachweise und alte PHP-Versionen nach PHP2Shell bedeutet.

Weiterlesen →022

Das Remi-Repository: PHP auf RHEL-Systemen aktuell halten

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.

Weiterlesen →023

Warum php -v nach dem Update dieselbe Nummer zeigt

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.

Weiterlesen →024

CVE-Nummern im Paket-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.

Weiterlesen →025

Hoster wechseln nach einem Sicherheitsvorfall: Worauf achten?

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.

Weiterlesen →026

Mehrere PHP-Versionen auf einem Server: Jede einzeln patchen

Auf vielen Servern laufen drei, vier oder mehr PHP-Installationen nebeneinander. Nach PHP2Shell muss jede gefunden, aktualisiert und neu gestartet werden.

Weiterlesen →027

Alte PHP-Versionen im Hosting-Panel 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.

Weiterlesen →028

Plesk: PHP-Handler verstehen (FPM, FastCGI, Apache-Modul)

Welchen PHP-Handler Plesk für eine Website nutzt, entscheidet über Isolation, Konfiguration und Risiko. Ein Vergleich mit Blick auf PHP2Shell.

Weiterlesen →029

CloudLinux und alt-php: Was Hosting-Kunden wissen sollten

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.

Weiterlesen →030

PHP auf NAS, Firewalls und Appliances: die vergessenen Systeme

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.

Weiterlesen →031

PHP bei Cloud- und PaaS-Anbietern: Wer patcht die 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.

Weiterlesen →032

Offizielle PHP-Docker-Images: Tags, Digests und Neubau

Ein Tag des offiziellen PHP-Images ist ein Zeiger, der mit der Zeit auf neue Stände wandert. Wer weiss, was Tag, Variante und Digest bedeuten, wählt das richtige Image und kann den Patch-Stand belegen.

Weiterlesen →033

CI/CD: PHP-Images automatisch 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.

Weiterlesen →034

Langzeitsupport für alte PHP-Versionen: Optionen und Grenzen

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.

Weiterlesen →035

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.

Weiterlesen →

Erkennung und Forensik

18 Artikel

036

Warnsignal: Der Webserver startet eine 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.

Weiterlesen →037

Verdächtige Prozesse auf Linux-Servern finden

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.

Weiterlesen →038

Versteckte Cronjobs als Hintertür erkennen

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.

Weiterlesen →039

Kürzlich geänderte Dateien auf dem Webserver 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.

Weiterlesen →040

PHP-Dateien im Upload-Ordner: Fundstellen richtig deuten

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.

Weiterlesen →041

Verschleierten PHP-Code erkennen

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.

Weiterlesen →042

Ausgehende Verbindungen eines Servers prüfen

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.

Weiterlesen →043

Fremde Admin-Konten in CMS und Server 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.

Weiterlesen →044

Unbekannte SSH-Schlüssel finden und entfernen

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.

Weiterlesen →045

Kryptominer auf dem Webserver: Anzeichen und Vorgehen

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.

Weiterlesen →046

Der Server verschickt Spam: Ursachen finden

Unzustellbare Mails, Sperrlisten, Beschwerden: Wenn der eigene Server Spam versendet, steckt meist ein Skript oder ein gekapertes Postfach dahinter. So finden Sie die Quelle.

Weiterlesen →047

SEO-Spam und fremde Seiten 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.

Weiterlesen →048

Die Website leitet auf fremde Seiten 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.

Weiterlesen →049

Beweise sichern, bevor Sie den Server neu aufsetzen

Ein Neuaufbau beseitigt den Angreifer, aber auch alle Spuren. Wer vorher eine Stunde in die Beweissicherung investiert, kann später sagen, was passiert ist.

Weiterlesen →050

Die Zeitleiste eines Vorfalls erstellen

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.

Weiterlesen →051

CMS-Kerndateien mit dem Original 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.

Weiterlesen →052

Die Datenbank auf eingeschleusten Code prüfen

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.

Weiterlesen →053

Malware-Scanner für Websites: Was sie finden und was nicht

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.

Weiterlesen →

Härtung und Konfiguration

20 Artikel

054

PHP-FPM-Pools pro Website 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.

Weiterlesen →055

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.

Weiterlesen →056

post_max_size und upload_max_filesize sinnvoll begrenzen

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.

Weiterlesen →057

session.upload_progress abschalten: richtig und dauerhaft

Die Abhilfe gegen CVE-2026-115560 und eine der PHP2Shell-Übergangsmassnahmen ist schnell gesetzt. Damit sie hält, muss sie an der richtigen Stelle stehen, gesperrt sein und nach jedem Update wieder geprüft werden.

Weiterlesen →058

expose_php und Server-Header: Versionsangaben verbergen

PHP, Nginx und Apache nennen ihre Versionsnummer standardmässig 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.

Weiterlesen →059

display_errors off: Fehlerausgaben in der Produktion abschalten

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.

Weiterlesen →060

php_admin_value: Einstellungen gegen Überschreiben 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.

Weiterlesen →061

Speichergrenzen mit systemd und cgroups setzen

php.net empfiehlt als PHP2Shell-Übergangsmassnahme memory_limit=-1 und eine Speichergrenze ausserhalb von PHP. So setzen Sie diese Grenze mit systemd und cgroups, ohne dass ein einzelner Worker den ganzen Dienst mitreisst.

Weiterlesen →062

Nginx für PHP sicher konfigurieren

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.

Weiterlesen →063

Apache für PHP sicher konfigurieren

Apache ist flexibel, und genau das macht ihn anfällig für Fehlkonfiguration. So binden Sie PHP über PHP-FPM an, schliessen .htaccess als Hintertür und stellen die wichtigsten Kernoptionen sicher ein.

Weiterlesen →064

PHP-Ausführung in Upload-Ordnern 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.

Weiterlesen →065

Upload-Anfragen am Rand filtern: Chancen und Risiken

Fachautoren schlagen vor, Upload-Anfragen ausserhalb 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.

Weiterlesen →066

ModSecurity und OWASP Core Rule Set einsetzen

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.

Weiterlesen →067

Fail2ban für Webserver einrichten

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.

Weiterlesen →068

Firewall für Webserver: Nur nötige Ports öffnen

Ein Webserver braucht nach aussen meist nur zwei Ports. Trotzdem lauschen auf vielen Servern Datenbanken, PHP-FPM oder Verwaltungsoberflächen im Internet. So finden Sie offene Dienste und schliessen, was nicht gebraucht wird.

Weiterlesen →069

Automatische Sicherheitsupdates auf Linux-Servern

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.

Weiterlesen →070

Least Privilege: 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.

Weiterlesen →071

Admin-Bereiche per IP, VPN oder Zusatzschutz 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.

Weiterlesen →072

TLS und 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.

Weiterlesen →073

CIS-Benchmarks und BSI-Bausteine für Webserver

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.

Weiterlesen →

Sichere Entwicklung

16 Artikel

074

Passwörter in PHP sicher speichern: password_hash richtig einsetzen

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.

Weiterlesen →075

CSRF-Schutz in PHP-Anwendungen

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.

Weiterlesen →076

Eingaben in PHP validieren und filtern mit filter_var

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.

Weiterlesen →077

Command Injection in PHP verhindern

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.

Weiterlesen →078

Server-Side Request Forgery (SSRF) in PHP verhindern

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.

Weiterlesen →079

XML External Entities (XXE) in PHP verhindern

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.

Weiterlesen →080

Type Juggling in PHP: Lose Vergleiche als Sicherheitsrisiko

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.

Weiterlesen →081

Sichere Zufallszahlen und Tokens in PHP mit random_bytes

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.

Weiterlesen →082

Zugangsdaten und .env-Dateien richtig schützen

Wie Sie Datenbankpasswörter, API-Schlüssel und andere Geheimnisse in PHP-Projekten schützen: .env-Dateien ausserhalb des Webroots, Sperren im Webserver, enge Rechte und geordneter Austausch nach einem Vorfall.

Weiterlesen →083

Öffentlicher .git-Ordner: Ein unterschätztes Datenleck

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.

Weiterlesen →084

Backup-Dateien im Webroot: .zip, .sql und .bak

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.

Weiterlesen →085

phpinfo()-Dateien: Warum sie verschwinden müssen

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.

Weiterlesen →086

Abhängigkeiten aktuell halten: Composer, npm und Plugins

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.

Weiterlesen →087

Sicherheits-Code-Review für PHP-Projekte

Wie Teams eigenen PHP-Code gezielt auf Sicherheitslücken durchsehen: Arten von Reviews, kritische Funktionen, sinnvolle Werkzeuge und eine Prüfliste.

Weiterlesen →088

Sicher loggen: Fehler protokollieren ohne Datenleck

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.

Weiterlesen →089

REST-APIs in 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.

Weiterlesen →

Management und Recht

14 Artikel

090

IT-Dienstleister-Verträge: Sicherheitspflichten klar regeln

PHP2Shell hat gezeigt, wie oft unklar ist, wer patchen muss. Welche Sicherheitspflichten in Verträge mit Agentur, Hoster und IT-Dienstleister gehören.

Weiterlesen →091

Auftragsverarbeitung, wenn Dienstleister auf Server zugreifen

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.

Weiterlesen →092

Schwachstellenmanagement für den 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.

Weiterlesen →093

Wissen, was läuft: Inventar aller Websites und 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.

Weiterlesen →094

Patch-Management als Prozess statt Feuerwehr

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.

Weiterlesen →095

Notfallkontakte: Wer muss wann informiert werden?

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.

Weiterlesen →096

Was ein gehackter Server kostet: Die Kostenposten

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.

Weiterlesen →097

Kunden nach einem 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.

Weiterlesen →098

Die Lieferkette im Web: Agentur, Hoster, Plugin-Anbieter

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.

Weiterlesen →099

Sicherheitsbewusstsein für Admins und Redakteure: Security Awareness im Web-Team

Wer Websites pflegt, entscheidet täglich über Sicherheit, oft ohne es zu merken. So schulen Sie Admins und Redakteure rollengerecht und ohne Folienschlacht.

Weiterlesen →100

Notfallübung am Tisch: Einen Webserver-Vorfall durchspielen

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.

Weiterlesen →101

ISO 27001 und TISAX: Was Webserver betrifft

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.

Weiterlesen →102

VdS 10000: Informationssicherheit für kleine und mittlere Unternehmen

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 heisst.

Weiterlesen →103

Lessons Learned: Nach dem Vorfall besser werden

Nach dem Vorfall ist vor dem nächsten. Eine strukturierte Nachbesprechung ohne Schuldzuweisung macht aus einer schlechten Woche einen messbaren Fortschritt.

Weiterlesen →

Entscheidungshilfen

10 Artikel

104

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

WhatsApp-Notfall Anrufen