Blog
Systeme aktuell halten: mehr als eine lästige Pflicht
Senior AWS Cloud Architect
Der Oktober 2026 hat eindrücklich gezeigt, wie schnell ein gut laufender Server zum Einfallstor für Angreifende werden kann. Innerhalb einer Woche wurden mit PHP2Shell und Node2Shell gleich zwei kritische Sicherheitslücken bekannt. Beide ermöglichen es Angreifenden, eigenen Code auf betroffenen Systemen ausführen. Und beide wurden bereits kurz nach ihrer Veröffentlichung aktiv ausgenutzt.
Für Sie als unseren Kunden haben wir eine positive Nachricht: Sie sind bereits gut geschützt. Auf den Systemen, die wir für Sie betreiben, spielen wir Sicherheitsupdates automatisch ein. Allerdings kann ein automatisches Update nur Patches installieren, die verfügbar sind. Hat ein Betriebssystem sein Supportende (End of Life, EOL) erreicht, werden dafür keine Patches mehr bereitgestellt. Und genau hier beginnt das Risiko.
Was ist passiert?
Hinter PHP2Shell (CVE-2026-109618, CVE-2026-109619) stecken zwei Speicherfehler im PHP-Interpreter. Betroffen sind die Versionen 5.4 bis 8.5, also mehr als zehn Jahre PHP-Geschichte. Bereits eine nicht authentifizierte Webanfrage kann genügen, um Code auf dem Server auszuführen oder sensible Daten wie Passwörter, Tokens und Schlüssel aus dem Speicher auszulesen. Da die Schwachstellen in der PHP-Runtime und nicht im Anwendungscode liegen, können auch sauber programmierte Anwendungen betroffen sein. Die US-Cybersicherheitsbehörde CISA (Cybersecurity and Infrastructure Security Agency) führt beide Schwachstellen in ihrem Katalog bekannter, aktiv ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) an.
Node2Shell (CVE-2026-111497) betrifft Brotli, eine weit verbreitete Kompressionsbibliothek. Manipulierte komprimierte Daten, etwa in einer Anfrage oder Antwort, können dazu führen, dass ein Prozess abstürzt, Speicherinhalte preisgegeben werden oder Schadcode ausgeführt wird. Brotli ist fester Bestandteil von Node.js, wird aber auch als Systembibliothek bereitgestellt und von vielen weiteren Programmen genutzt. Diese Sicherheitslücke hat die CISA am 27. Oktober 2026 in ihren KEV-Katalog aufgenommen.
So schützen wir Ihre Systeme
Wir betreiben Ihre Umgebung auf AWS und kümmern uns um Orchestrierung, Deployment und Konfiguration. Auf allen von uns verwalteten Systemen installiert unattended-upgrades Sicherheitsupdates automatisch. Sobald der Betriebssystemhersteller einen Fix bereitstellt, wird dieser ohne Ihr Zutun auf Ihren Servern eingespielt. Für PHP2Shell und Node2Shell bedeutete das: Systeme mit unterstützten Betriebssystem-Releases erhielten die gepatchten Pakete kurz nach deren Verfügbarkeit über die jeweiligen Distributionen.
Wo automatische Updates an ihre Grenzen stoßen
Automatische Updates halten ein System innerhalb seiner Betriebssystemversion auf dem neuesten Stand. Sie führen jedoch kein Upgrade auf ein neueres Release aus. Da ein solches Upgrade Auswirkungen auf Runtime-Versionen, Bibliotheken und Systemverhalten haben kann, ist es wichtig, diesen Schritt gemeinsam mit Ihnen zu planen und testen.
Wenn Sie ein Betriebssystem einsetzen, das sein EOL erreicht hat, hat das drei wesentliche Auswirkungen:
- Der Hersteller veröffentlicht keine Sicherheitsfixes mehr. Damit kann auch unattended-upgrades keine neuen Patches installieren.
- Laufzeitumgebungen wie PHP, die über das Betriebssystem bereitgestellt werden, bleiben dauerhaft auf einer unsicheren Version.
- Jede neu entdeckte Sicherheitslücke kommt hinzu, bestehende Lücken werden nicht mehr geschlossen.
Die Art und Weise, wie Ihre Anwendung bereitgestellt wird, hat auch Einfluss darauf, wer für das Einspielen von Sicherheitsfixes zuständig ist:
- Quellcode-Deployment: Ihr Code läuft auf Servern, die wir verwalten. Solange das Betriebssystem-Release unterstützt wird, werden das Betriebssystem und die darüber bereitgestellten Runtimes automatisch mit Sicherheitsupdates versorgt.
- Container-Images auf Elastic Container Service (ECS): Wir halten die Infrastruktur, auf der Ihre Container laufen, auf dem neuesten Stand. Alles innerhalb des Images – also Basis-Betriebssystem, PHP- oder Node.js-Version und Bibliotheken – stammt aus dem von Ihnen bereitgestellten Image. Ein gepatchter Host schließt keine Sicherheitslücke im Image. Deshalb müssen Sie Ihre Container-Images mit aktuellen, unterstützten Basis-Images neu erstellen und bereitstellen.
Zusätzlicher Schutz durch AWS-Services
Patches schließen Sicherheitslücken. Zusätzliche AWS-Sicherheitsdienste helfen, die Zeit bis zur Verfügbarkeit eines Patches zu überbrücken und Angriffe zu erkennen, die trotz Schutzmaßnahmen erfolgreich sind. Wir können Ihre verwaltete Infrastruktur um folgende Dienste erweitern:
- AWS Web Application Firewall (WAF) filtert schädliche Anfragen heraus, bevor sie Ihre Anwendung erreichen. Die WAF ist CloudFront, Application-Load-Balancern oder dem API Gateway vorgeschaltet. AWS hält die verwalteten Regelgruppen auf dem neuesten Stand und stellte bereits am Tag der Veröffentlichung von PHP2Shell passende WAF-Schutzmaßnahmen bereit. Dieses sogenannte „Virtual Patching“ schützt Sie, während die Sicherheitsupdates ausgerollt werden, ersetzt diese aber nicht.
- Amazon GuardDuty analysiert Ihre AWS-Umgebung kontinuierlich auf Anzeichen von Angriffen, etwa Verbindungen zu bekannten bösartigen Hosts oder ungewöhnliche API-Aktivitäten. Mit Runtime Monitoring überwacht GuardDuty zusätzlich EC2-Instanzen und ECS-Container auf verdächtiges Verhalten, zum Beispiel Reverse Shells oder Kryptominer nach erfolgreicher Ausnutzung einer Schwachstelle.
- Amazon Inspector prüft EC2-Instanzen und Container-Images in Amazon Elastic Container Registry (ECR) laufend auf bekannte Schwachstellen. Wird eine neuer Eintrag im Verzeichnis „Common Vulnerabilities and Exposures (CVE)“ veröffentlicht, erkennt der Dienst, welche Systeme und Images betroffen sind – auch solche, die bereits produktiv eingesetzt werden.
- AWS Security Hub führt die Ergebnisse dieser Services zentral zusammen und priorisiert sie. So behalten Sie den Überblick, ohne mehrere Konsolen einzeln prüfen zu müssen.
Diese Services ergänzen aktuelle Systeme, ersetzen sie aber nicht. Auch eine vorgeschaltete WAF ändert nichts daran, dass ein EOL-System Risiken birgt.
Unsere Empfehlungen
- Setzen Sie auf unterstützte Betriebssystem-Releases. Das ist die Grundvoraussetzung für den Schutz Ihrer Systeme und stellt sicher, dass automatische Sicherheitsupdates greifen.
- Planen Sie Upgrades rechtzeitig vor dem EOL, nicht erst danach. Gern informieren wir Sie über den Supportstatus Ihrer Systeme und die relevanten EOL-Termine.
- Nutzen Sie CI/CD-Pipelines, wo immer es möglich ist. Automatisierte Builds und Deployments machen Updates zur Routine statt zum Risiko. Eine Pipeline erstellt, testet und rollt Änderungen jedes Mal auf dieselbe Weise aus. Falls doch etwas schiefgeht, ist ein Rollback schnell erledigt.
- Binden Sie Sicherheitsscans in die Pipeline ein. Tools wie Trivy prüfen Container-Images, Abhängigkeiten und Konfigurationen auf bekannte Schwachstellen, bevor etwas produktiv eingesetzt wird. Konfigurieren Sie die Pipeline so, dass sie bei kritischen Funden abbricht. Scannen Sie auch bereits ausgerollte Images regelmäßig, um neue CVEs zu erkennen, selbst wenn sich Ihr Code nicht geändert hat. Verwenden Sie für Ihre Pipeline-Tools einschließlich der Scanner unveränderliche Referenzen wie Commit-SHAs oder Image-Digests anstelle von Versions-Tags. So bleibt auch Ihre Toolchain vertrauenswürdig.
- Aktualisieren Sie Abhängigkeiten automatisch. Die Abhängigkeiten Ihrer Anwendung, beispielsweise Composer- oder npm-Pakete und Container-Basis-Images, ändern sich ständig. Zusammen bilden sie Ihre Software Bill of Materials (SBOM), ein Verzeichnis all Ihrer Software-Komponenten. Tools wie Dependabot oder Renovate überwachen diese Abhängigkeiten und erstellen automatisch Pull Requests, sobald Updates verfügbar sind. Sicherheitsfixes werden dabei deutlich gekennzeichnet. In Kombination mit einer CI/CD-Pipeline und automatisierten Tests genügt es häufig, einen Pull Request zu prüfen und mergen, um ein Update einzuspielen.
- Erstellen Sie Ihre Container-Images regelmäßig neu. Verwenden Sie aktiv gepflegte Basis-Images und erstellen Sie Ihre Images auch dann neu, wenn sich Ihr Code nicht geändert hat. So werden Sicherheitsfixes berücksichtigt. Mit einer CI/CD-Pipeline lässt sich dieser Vorgang regelmäßig und automatisiert statt manuell durchführen.
- Sprechen Sie uns frühzeitig an. Ein Betriebssystem-Upgrade ist ein gemeinsames Projekt: Wir richten eine Staging-Umgebung ein, in der Sie die Kompatibilität Ihrer Anwendung prüfen. Automatisierte Tests in Ihrer Pipeline beschleunigen diesen Schritt erheblich. Gemeinsam vereinbaren wir anschließend ein Wartungsfenster für die Umstellung auf den Produktivbetrieb. Je früher wir starten, desto besser sind Sie vorbereitet, wenn die nächste kritische Sicherheitslücke bekannt wird.
Fazit
PHP2Shell und Node2Shell werden nicht die letzten Lücken dieser Art bleiben. Auf den von uns verwalteten Systemen spielen wir Sicherheitsfixes weiterhin automatisch ein, sobald sie verfügbar sind. Ihr Beitrag: Sorgen Sie mit unterstützten Betriebssystem-Releases und aktuellen Container-Images dafür, dass Sie auch künftig Sicherheitsfixes für Ihre Systeme erhalten. Sie setzen noch ein älteres Release oder veraltete Container-Images ein? Dann sprechen Sie uns an. Wir planen das Upgrade gemeinsam.
Auch bei den weiteren Themen dieses Beitrags unterstützen wir Sie gern. Wir prüfen den Supportstatus Ihrer Systeme, richten CI/CD-Pipelines ein, integrieren Sicherheitsscans mit Trivy und konfigurieren Dependabot oder Renovate. Darüber hinaus können wir Ihre Umgebung mit AWS WAF, GuardDuty, Inspector und Security Hub erweitern. Kontaktieren Sie uns einfach über unser Serviceportal. Zusammen finden wir den passenden Ansatz für Ihre Umgebung.
Kontakt
Möchten Sie mehr über unsere AWS Managed Services erfahren?
