PHP2Shell, die Nextcloud-Panik und ein neues Projekt: fxcloud

Gestern habe ich mich erst über den PHP-Gau lustig gemacht. Ein kritisches Remote-Code-Execution-Loch, CVSS 9.2, in der am weitesten verbreiteten Server-Sprache der Welt – ja toll, habe ich gedacht, das geht mich nichts an, mein Blog ist statisch, kein PHP, keine Datenbank, kein App-Server. Fünf Minuten später saß ich mit einem kalten Kaffee vor der Konsole und habe gezählt, wie viele PHP-Instanzen ich eigentlich im Internet habe stehen.

Die Antwort war: mehr als mir lieb war.

Was gestern wirklich passiert ist

Am 21. Oktober 2026 hat das PHP-Team Sicherheits-Updates veröffentlicht – zwei Schwachstellen, die beide als kritisch gelten (CVSS 9.2) und beide unauthentifizierte Remote-Code-Execution ermöglichen:

1. CVE-2026-109618 – RCE via OOM-Corruption: Wenn eine Anfrage genau im richtigen Moment das memory_limit erreicht, kann PHP interne Anfrage-Daten nur unvollständig initialisiert zurücklassen. Die Aufräumroutine behandelt sie später als gültig – und räumt Speicher ab, der nie initialisiert wurde. Bei Apache mit mod_php konnte gezeigt werden, dass eine einzige nicht-authentifizierte Anfrage reicht, und das bevor irgendein Anwendungscode läuft.
2. CVE-2026-109619 – RCE via stale Global State: Interner Zustand einer Anfrage kann überleben, nachdem der dahinterstehende Speicher freigegeben wurde. Die nächste Anfrage auf demselben Worker greift dann auf diesen Speicher zu – Use-After-Free, und ebenfalls mit demonstrierter RCE.

In den Medien wird das Ding schon „PHP2Shell" genannt, in Anlehnung an Log4Shell. Das BSI hat gewarnt, das niederländische NCSC hat seine eigene Website vorsorglich offline genommen, CERT-EU hat zum sofortigen Patchen aufgerufen. Betroffen ist im Grunde jede PHP-Version, die Webanfragen verarbeitet – also Nextcloud, WordPress, Drupal, TYPO3, Joomla, Magento, pfSense, OPNsense und ein gutes Stück mehr. Palo Alto Networks zählt über 22 Millionen potenziell verwundbare Instanzen, die im Internet sichtbar sind.

Gepatcht ist in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alles ältere bekommt keine Updates mehr vom PHP-Projekt. „Aktualisieren" ist die einzige echte Lösung – Workarounds reduzieren nur die Angriffsfläche, machen aber nichts sicher.

Warum mein anfängliches Lachen ziemlich schnell verstummte

Weil ich nicht nur dieses statische Blog betreibe, auf dem du gerade liest. Nein:

• Eine private Nextcloud, öffentlich erreichbar, mit Dateien, Kalender, Kontakten – mein komplettes digitales Leben.
• Eine Nextcloud für meinen Verein, mit Daten von ein paar Dutzend Menschen, die sich darauf verlassen, dass das Ding läuft und sicher ist.
• Ein WordPress für denselben Verein – Redaktions-Workflow, Veranstaltungsseiten, die ganze Mischung aus Core, Plugins und Themes.

Plötzlich war da keine distanzierte Verklärtheit mehr, sondern die leise, sehr konkrete Frage: Ist davon irgendwas gerade angreifbar? Und die zweite Frage gleich dahinter: Und wenn nicht heute – wie lange noch, bis wieder so etwas kommt?

Denn das ist das eigentlich Unangenehme. Nicht dieser eine Patch. Sondern die Erkenntnis, dass ich bei Nextcloud und WordPress nicht einfach „PHP aktualisieren" kann und gut ist. Ich hänge an einem ganzen Ökosystem: Die Nextcloud-Version muss zur PHP-Version passen, die Apps müssen zur Nextcloud-Version passen, WordPress-Plugins hinken oft hinterher, und irgendwas crasht immer genau dann, wenn man es nicht beobachtet. Dazu eine Datenbank, ein App-Server, regelmäßig Updates – und eine Angriffsfläche, die mit jeder installierten App wächst.

Mein Blog funktioniert übrigens deshalb so gut, weil es keine dieser Abhängigkeiten hat. Statisch, nginx, fertig. Kein PHP, kein MySQL, kein laufender Prozess, den man patchen muss, bevor der Exploit da ist. Genau diesen Luxus wollte ich auch für meine privaten Daten.

Weg von Nextcloud – aber wohin?

Die Entscheidung für privat war schnell getroffen: Ich will weg von Nextcloud. Nicht, weil Nextcloud schlechte Software ist – die Leute da arbeiten ernsthaft und gut. Aber weil „Alles-auf-einmal"-Plattformen automatisch die maximale Angriffsfläche bieten. Kalender, Kontakte, Dateien, Talk, Office, Notes, Whiteboard – alles hängt an einem PHP-Kern, und wenn der Kern wackelt, wackelt alles.

Die Frage ist nur: Wohin? Und hier wird es unschön, denn es gibt keine perfekte Antwort:

• Syncthing – super für Geräte-zu-Geräte-Sync, aber kein Web-Zugriff, keine Share-Links, kein „irgendwo anhängen und Datei laden".
• Seafile – Dateien-fokussiert, schnell, aber trotzdem Server plus MySQL/MariaDB. Nicht gerade die Reduktion, die ich suche.
• OpenCloud – moderner Go-Nachfolger von ownCloud, interessant, aber jung und ohne Kalender/Kontakte.
• bewCloud – schlank, Deno/TypeScript, vielversprechend, aber wieder eine andere Laufzeitumgebung, die ich betreiben und am Leben halten muss.
• Einfach bleiben – also Nextcloud patchen und hoffen. Der Weg des geringsten Widerstands, aber mit dem Wissen von gestern irgendwie unbefriedigend.

Kein Modell passt so richtig. Also habe ich, wie man es als Linux-User irgendwann mal macht, beschlossen: Wenn die Antwort nicht existiert, baut man sie sich halt selbst.

fxcloud – aus Sorge wurde ein Nebenprojekt

Genau so ist fxcloud entstanden. Kein durchdachter Business-Plan, kein „ich gründe jetzt ein Produkt", sondern die etwas panische Erkenntnis von gestern Abend, kombiniert mit der Tatsache, dass ich eh keine Langeweile hatte. Ein Vibecoding-Projekt: Ich beschreibe, was ich will, die KI schreibt die meiste Kohle, ich korrigiere, teste, verwerfe, diskutiere – und am Ende steht etwas, das es vorher nicht gab.

fxcloud ist eine Nextcloud-inspirierte persönliche Cloud in einem einzigen Rust-Binary. Kein externer Datenbank-Server, kein separater Frontend-Build, keine Haufen von Abhängigkeiten. Man startet die Binary, öffnet den Browser, erstellt einen Account – und hat eine vertraute Login- plus Dateiexplorer-Erfahrung. SQLite ist eingebettet, die Frontend-Assets auch. Einfach laufen lassen.

Was heute schon funktioniert:

• User-Accounts mit Argon2id-Password-Hashing
• Sessions als HttpOnly-Cookies, serverseitig gespeichert, mit Ablauf und Aufräum-Job
• Dateiexplorer im Nextcloud-Stil: Ordnerbaum, Breadcrumbs, Ordner anlegen, Dateien per Button oder Drag & Drop hochladen, herunterladen, umbenennen, löschen
• WebDAV unter /dav/ – das heißt: Nextcloud-Desktop-Client, rclone, Cyberduck, Windows „Netzlaufwerk verbinden" und macOS Finder funktionieren bereits
• Saubere, modulare Architektur in Rust (axum, rusqlite, tokio) – damit auch mal jemand anderes als die KI und ich darin vorbeischauen kann

Alles konfigurierbar per Umgebungsvariablen, ein hardening-tauglicher systemd-Unit liegt bei, hinter einem Reverse Proxy mit HTTPS läuft es genauso. Lizenz: MIT.

Warum ausgerechnet Rust?

Die naheliegende Frage: Wenn ich doch eh mit der KI vibecode, warum dann nicht PHP, Go, TypeScript oder einfach das, was die meisten Nextcloud-Alternativen ohnehin nutzen? Weil bei mir die letzten 48 Stunden den Ausschlag gegeben haben – und um genau eine Sache geht es mir hier: Sicherheit, und zwar so wenig Angriffsfläche wie möglich.

Rust ist keine magische Sicherheitsschicht. Ein Programm in Rust kann genauso Unsinn tun wie jedes andere: falsche Logik, schlampige Authentifizierung, SQL-Injection, wenn man die Parametrierung vergisst. Moderne Sprachen machen einen Code nicht automatisch sicher.

Aber: Richtig verwendet erhöhen sie die Sicherheit drastisch – und zwar in einer Kategorie von Fehlern, die gestern im PHP-Advisory zentral war.

Die beiden CVEs von gestern – OOM-Corruption und Use-After-Free – gehören zu genau jenen Schwachstellen, die in Rust im Safe-Sprachteil grundsätzlich nicht vorkommen. Kein manuelles Freigeben von Speicher, kein Zugriff auf bereits freigegebenen Speicher, keine Buffer-Overflows, kein Undefined Behaviour, das in der Praxis zum RCE führt. Das ist kein Zufall, sondern das Kernversprechen des Ownership- und Borrow-Checkers: Der Compiler erzwingt sichere Speicherverwaltung zur Laufzeit, statt sie deinem Bauchgefühl zu überlassen.

Dazu kommt das Typsystem: Ganze Klassen von Fehlern – verwirrte Einheiten, uninitialisierte Felder, vergessene None-Fälle – fallen nicht im Betrieb auf, sondern beim Kompilieren. Ich bekomme keine Laufzeit-Überraschungen à la „ups, der Pointer war doch schon frei", sondern eine verständliche Compiler-Meldung, die ich beheben kann, bevor Code jemals einem Internet ausgesetzt wird.

Und das ist der Punkt, der für fxcloud am meisten zählt: Weniger Angriffsfläche als ein PHP-Ökosystem.

Baustein	Nextcloud/PHP	fxcloud
Laufzeit	PHP-Interpreter + Extensions	eine statische Binary
Datenbank	MySQL/MariaDB/PostgreSQL separat	SQLite eingebettet
App-Ökosystem	Dutzende Apps, jede ein Risiko	eingebaute Features
Memory-Safety	nicht garantiert	durch Sprache erzwungen
Patch-Fenster	oft Wochen (PHP → NC → Apps)	ein cargo build

Kein separater DB-Server, der patchen will. Keine PHP-Extensions, von denen ich nicht einmal alle kenne. Keine Plugin-Schere, in der ein einziges Update den ganzen Haufen zum Beben bringt. Eine Binary, die ich auf den Server kopiere, starte, und die läuft – bis ich selbst entscheide, sie upzudaten.

Das ist kein Rust-Fanatismus. Ich hätte mit Go oder einer sauberen TypeScript-Stack-Umgebung ähnliche Reduktion erreichen können. Aber Rust kombiniert zwei Dinge, die für dieses Projekt wichtig sind: die Speicher-Sicherheit, die genau die Klasse von Bugs trifft, die uns gestern aufgeschreckt hat, und die Möglichkeit, ein schlankes Binary ohne schweres Laufzeit-Ökosystem auszuliefern. Genau das ist die Richtung, in die ich mit fxcloud will: so wenig Angriffsfläche wie möglich. Und was noch übrig bleibt, soll aus einer Sprache kommen, die mir die gefährlichsten Fehler schon beim Kompilieren erspart.

Natürlich bleibt die Logik-Fehler-Sicherheit an mir hängen. Aber eine Welt, in der ich mich um Authentifizierung und Datenlogik kümmern muss – nicht aber um Use-After-Free und Buffer-Overflows –, ist eine Welt, in der ich nachts ruhiger schlafe. Und nach den letzten zwei Tagen ist mir das einiges wert.

Was fxcloud (noch) nicht kann – und das ehrlich gesagt

Das hier ist kein vorzeigbares Produkt. Es ist ein Wochenendprojekt, das seit heute Morgen auf GitHub liegt. Aktuell fehlt unter anderem:

• Datei-Freigabe zwischen Users, Rechte, Gruppen
• Versionierung und Papierkorb
• Kalender und Kontakte (CalDAV/CardDAV)
• Dateivorschauen im Browser (Bilder, Text, PDF)
• Ein Admin-Konzept – der erste registrierte User ist „nur" ein User

Die Roadmap-Liste auf GitHub ist entsprechend lang, die To-do-Liste noch länger. Aber genau das ist der Punkt, an dem es interessant wird.

Mitmachen statt zuschauen

Ich lass euch bewusst am Entstehungsprozess mitwirken. Das Projekt liegt öffentlich auf GitHub: github.com/floyd54/fxcloud. Wer mag:

• Issues aufmachen – für Bugs, aber vor allem für Ideen und „das würde ich anders machen"
• PRs schicken – Code-Beiträge sind willkommen, aber ehrliche Architektur-Kritik ist fast noch wertvoller
• Ausprobieren – cargo build --release, starten, hochladen, kaputt machen, Bescheid geben
• Oder einfach hier unter dem Artikel kommentieren, was ihr von so einem Ansatz haltet

Ich bin kein Rust-Entwickler vom Fach und kein Security-Researcher. Ich bin ein Linux-User, der gestern zu viel Kaffee getrunken hat und beschlossen hat, dass seine Nextcloud zu komplex für seine Nerven ist. Genau deshalb freue ich mich über jede Rückmeldung von Leuten, die das besser können als ich.

Und der Verein?

Keine Sorge: Die Vereins-Nextcloud und das Vereins-WordPress verschwinden nicht über Nacht. Beides ist gepatcht und wird beobachtet. Ein Verein braucht etwas, das läuft – nicht etwas, das gerade beim ersten Commit steht. Aber die richtige Frage für den Verein ist langfristig dieselbe wie für mich privat: Wollen wir weiter eine riesige PHP-Plattform am Leben erhalten, oder wechseln wir irgendwann auf etwas Schlankeres, sobald es reif dafür ist? Bis dahin: patchen, und im Zweifel den Zugriff so eng wie möglich halten.

Fazit

Aus „hehe, was ein PHP-Gau" wurde innerhalb eines Abends eine Bestandsaufnahme meiner eigenen Angriffsflächen, ein ziemlich klares „ich will da raus" und ein neues Projekt auf GitHub. Vielleicht ist das der gesündeste Umgang mit Sicherheitspaniken: erst mal patchen, dann den Status quo hinterfragen, und wenn die Antwort unbefriedigend ist – halt selbst bauen.

Ach ja: Wenn du selbst PHP betreibest – patchen. Heute. Nicht morgen. php -v ansehen, Distribution-Pakete einspielen, PHP-FPM neustarten. Das ist der langweilige Teil, aber er hilft sofort. Der aufregende Teil – also fxcloud – findet parallel statt.

Und wenn du magst, schau auf github.com/floyd54/fxcloud vorbei und sag mir, ob das der richtige Weg ist. Ich bin gespannt.