Hallo Modellbahner,
schön, dass Sie hier vorbeischauen, doch leider ist gerade jetzt hier noch nicht viel zu sehen.
Der Grund: Unser altes Redaktionssystem Typo3, das wir seit 2006 betreiben, mussten wir wegen der Sicherheitslücken rund um PHP vom Netz nehmen, es hat den gesamten Server gefährdet, das konnten wir nicht verantworten. Wenn Sie sich für die Details interessieren, unter meinen Vorworten ist der gesamte Umstand erläutert.
Die gute Nachricht: Nach vielen Gesprächen haben wir uns entschlossen, „Modellbahntechnik aktuell 2.0“ mit einem anderen, modernen CMS zu starten.
Und noch eine gute Nachricht: Es wird auch eine neue Magazin-Ausgabe geben, #82 ist in Arbeit!
Bis allerdings wieder alles wie gewünscht steht, wird einige Zeit vergehen. Ebenso ist derzeit keine Aussendung des Info-Newsletters möglich, wir bitten um Ihr Verständnis. Schauen Sie einfach von Zeit zu Zeit vorbei, wie der Stand der Dinge ist.
Mit besten Modellbahner-Grüßen
Rudolf Ring
Die Sicherheitslücken PHP2Shell
Unter der Bezeichnung „PHP2Shell“ (bestehend aus den Schwachstellen CVE-2026-109618 und CVE-2026-109619) wurden im Oktober 2026 zwei extrem kritische Sicherheitslücken im Kern der Programmiersprache PHP bekannt. Da PHP als Fundament für einen Großteil des Webs dient – darunter Content-Management-Systeme wie WordPress, Joomla, TYPO3 oder Shopware –, wird diese Bedrohung zu den schwerwiegendsten der letzten Jahre gezählt.
Hier sind die wichtigsten Aspekte der Bedrohung im Detail:
1. Wie funktionieren die Lücken?
Beide Schwachstellen liegen tief im Interpreter von PHP und betreffen die Art und Weise, wie die Programmiersprache mit dem Arbeitsspeicher (Memory Management) umgeht:
- Das Speicherlimit-Problem (CVE-2026-109618): Wenn ein PHP-Skript während der Ausführung an sein konfiguriertes Speicherlimit stößt, bricht der Interpreter den Prozess ab. Dabei kann es unter bestimmten Bedingungen zu Fehlern in der Fehlerbehandlung kommen, die von Angreifern gezielt provoziert werden.
- Der „Use-After-Free“-Fehler (CVE-2026-109619): Hierbei bleiben Daten beziehungsweise Speicherbereiche einer Anfrage im Arbeitsspeicher erhalten, obwohl sie längst als freigegeben markiert wurden. Eine nachfolgende, speziell präparierte Anfrage kann diese verwaisten Reste (stale global state) auslesen oder manipulieren.
2. Warum ist die Bedrohung so gefährlich?
- Remotekontrolle ohne Authentifizierung: Angreifer benötigen keinerlei Zugangsdaten oder Benutzerkonten. Ein einzelner, speziell präparierten HTTP-Request (zum Beispiel über manipulierte Upload-Formulare oder Cookie-Daten) reicht aus.
- Volle Server-Übernahme („Shell“): Gelingt der Angriff, können Kriminelle eigenen Programmcode direkt auf dem Webserver ausführen. Das bedeutet im schlimmsten Fall die vollständige Kontrolle über den Server, das Auslesen sensibler Datenbanken, die Installation von Schadsoftware (Ransomware, Backdoors) oder die Umleitung von Website-Besuchern.
- Enorme Verbreitung: Da die Schwachstelle im PHP-Interpreter selbst und nicht erst in einer Website-Anwendung sitzt, sind potenziell alle Webseiten und Applikationen betroffen, die auf einer ungepatchten PHP-Version laufen.
3. Welche Versionen sind betroffen?
Betroffen sind im Prinzip alle älteren, noch im Umlauf befindlichen Hauptversionen von PHP (zurückreichend bis zu älteren Zweigen). Das betrifft sowohl moderne Umgebungen als auch veraltete Installationen, die oft auf Firmen- oder Kundenservern unbemerkt weiterlaufen.
4. Was muss jetzt getan werden?
- Sofortiges Update einspielen: Die Entwickler haben Notfall-Patches veröffentlicht. Die Lücken sind erst ab den Versionen PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 (bzw. neuer) behoben.
- Das Problem mit alten Versionen: Für bereits ausgelaufene Versionen (wie PHP 8.1 oder älter, für die es keinen offiziellen Support mehr gibt) stellen die Core-Entwickler keine direkten Binär-Updates bereit. Hier müssen Administratoren auf vom Linux-Distributionen bereitgestellte Backports zurückgreifen oder – was dringend angeraten wird – zeitnah auf eine unterstützte PHP-Version upgraden.
Eingeschränkte Workarounds: Sicherheitsbehörden wie das BSI betonen, dass reine Server-Einstellungen oder Web Application Firewalls (WAF) keinen hundertprozentigen Schutz bieten, da die Logikfehler tief im Quellcode des Interpreters greifen. Ein Update des Systems oder – im Notfall bei Handlungsunfähigkeit – die temporäre Trennung vom Netz sind die einzigen verlässlichen Schritte.