Self-Hosting
Heute Nachmittag, 16 Uhr: Das PHP-Projekt veröffentlicht Updates gegen zwei kritische Schwachstellen. CERT-EU warnt, ein Proof-of-Concept kursiert schon, und die übliche Uhr läuft: Stunden bis Tage, dann gibt’s die ersten Exploits in freier Wildbahn.
Normalerweise wäre das für mich ein Fall wie bei wp2shell – sofort patchen, Logs checken, nervös auf die Uhr schauen. Diesmal nicht. Und genau das ist der Punkt.
Was an den PHP-Lücken Sache ist
- Zwei Code-Einschleusungs-Schwachstellen, die Remote Code Execution ermöglichen
- Betroffen ist laut Berichten praktisch jede PHP-Version seit PHP 5 – die Fehler stecken tief im Code
- Unbestätigten Berichten zufolge zielt ein kursierender Proof-of-Concept auf LiteSpeeds
lsphp8-Server-API - Der naheliegende Workaround (
session.upload_progress.enabled = 0) reduziert die Angriffsfläche höchstens, schützt aber nicht vollständig – patchen bleibt Pflicht - CERT-EU und andere Stellen raten zu zügigem Patchen, teils sogar dazu, PHP-Server notfalls kurz offline zu nehmen, bis der Patch sitzt
Das ist kein Nischenproblem. PHP treibt nach wie vor einen riesigen Teil des Webs an – WordPress, Shopsysteme, selbstgebastelte Legacy-Anwendungen, halb das Internet eben.
Ich geb’s zu: Ich hab mir das langweilig vorgestellt. Docker-Container hochziehen, Domain dran, fertig. Discourse installieren, dachte ich, ist eine Sache von einer Stunde.
Es wurde ein ganzer Samstagnachmittag. Der Container war das kleinste Problem. Die eigentliche Geschichte ist eine über DNS-Records, drei verschiedene E-Mail-Anbieter und die Erkenntnis, dass meine Domain gar nicht dort liegt, wo ich dachte.
Am Ende lief alles. Und ich bin seitdem ziemlich verliebt in dieses Forum.
Ich geb’s zu: Als die Meldung über die neue kritische WordPress-Lücke reinkam, hab ich erstmal kurz geschluckt. Nicht wegen der Lücke selbst – die kommen und gehen –, sondern wegen des Datums. Ich hatte am 17.07. gepatcht. Die ersten Exploit-Versuche liefen laut meinen Logs am 18.07. an.
Ein Tag. Das war’s.
Hätte ich das Update aufgeschoben – “mach ich nächste Woche, ist ja nur ein Blog” – wäre ich vermutlich mit dabei gewesen.
Ich geb’s zu: Ich habe jahrelang einfach Cloudflare Tunnels genommen. War bequem. Hat funktioniert. Und irgendwann hab ich aufgehört, darüber nachzudenken, was da eigentlich mit meinem Traffic passiert.
Dann stolperte ich über Pangolin – und plötzlich hatte ich dieses unangenehme Jucken im Hinterkopf:
„Muss das wirklich alles über Cloudflares Server laufen?”
Kurze Antwort: nein. Lange Antwort: dieser Blogpost.
Was ist Pangolin überhaupt?
Pangolin ist ein Open-Source-Projekt von Fossorial – übrigens ein YC 2025-Unternehmen, was zeigt, dass da mehr dahintersteckt als ein Wochenendprojekt. Im Kern ist es eine selbst gehostete Alternative zu Cloudflare Tunnels, die auf WireGuard basiert und gleichzeitig Reverse Proxy, VPN und Zero-Trust-Zugriffskontrolle in einem vereint.