Wenn Entwickler an die MISRA-C- oder MISRA-C++-Richtlinien denken, denken sie sofort an eingebettete Systeme: Automotive-ECUs, Flugsteuerungssoftware, Medizintechnik und Robotik-Rover. Die verbreitete Wahrnehmung: Diese Regeln – die dynamische Speicherfallen verbieten, Zeigerarithmetik einschränken und abrupte Kontrollsprünge untersagen – seien ausschließlich für Systeme gedacht, bei denen ein Softwareabsturz körperlichen Schaden verursachen kann.
Jüngste hochkarätige Sicherheitsvorfälle zerstören diese Annahme.
Die Entdeckung der kritischen „PHP2Shell“-Remote-Code-Execution-Schwachstellen (CVE-2026-109618 und CVE-2026-109619) im Kern der PHP-Engine zeigt, wie Low-Level-Fehler in Speicher- und Kontrollflussverwaltung in C weltweit High-Level-Webanwendungen kompromittieren können.
Schaut man genau hin, warum diese Schwachstellen entstanden sind, erkennt man Musterbeispiele für Verstöße gegen zentrale Sicherheitsprinzipien, die MISRA-Standards seit Jahrzehnten verbieten. Darum ist die Philosophie der MISRA-Konformität für jeden Softwareentwickler wichtig – ob Mikrocontroller oder Web-Runtimes.
Die Illusion der Isolation: High-Level-Sprache, Low-Level-Engine
PHP ist eine interpretierte High-Level-Skriptsprache, auf die sich Millionen von Webanwendungen und Content-Management-Systeme verlassen. Webentwickler schreiben sauberen, ausdrucksstarken Code und vertrauen darauf, dass die Laufzeitumgebung Speicherverwaltung, Typsicherheit und Aufräumarbeiten im Hintergrund übernimmt.
Die zugrunde liegende Engine von PHP (die Zend Engine) ist jedoch vollständig in C geschrieben.
Existiert eine Schwachstelle im C-Kern, werden Sicherheitsmechanismen auf Anwendungsebene vollständig irrelevant. Ein nicht authentifizierter Angreifer braucht keine Lücke in Ihrer PHP-Skriptlogik; er kann die zugrunde liegende Runtime-Engine ausnutzen, um vollständige Remote Code Execution (RCE) zu erlangen.
PHP2Shell: Die Embedded-Sicherheits-Albträume, die es verursachten
Das PHP2Shell-Advisory hebt zwei kritische Schwachstellen hervor, die vollständig auf gefährliche C-Programmierkonstrukte zurückgehen:
1. CVE-2026-109618: Out-of-Memory(OOM)-Zustandskorruption
Was passiert ist: Wenn eine eingehende Anfrage einen Out-of-Memory-Fehler auslöst, verlässt sich PHP auf Cs Standardmechanismus longjmp(), um den aktuellen Ausführungskontext abrupt abzubrechen und herauszuspringen.
Der C-Defekt: Da longjmp() das normale Stack-Unwinding überspringt, blieben mitten im Aufbau befindliche Datenstrukturen teilweise initialisiert. Als später die Aufräumroutine der Anfrage lief, behandelte sie diesen ungültigen, halbfertigen Speicher als gültige Daten – ein Speicherkorruptionsvektor, der zu RCE führt.
2. CVE-2026-109619: Veralteter globaler Zustand & Use-after-free
Was passiert ist: Hochperformante Worker-Prozesse (wie PHP-FPM) verarbeiten Tausende von Anfragen sequenziell und verwenden denselben Prozessspeicher-Pool wieder.
Der C-Defekt: Globale Zustandszeiger, die temporär in den Anfragespeicher zeigten, wurden beim Beenden nicht ordnungsgemäß zurückgesetzt. Nach dem Freigeben des Speichers überlebte der globale Zeiger – eine Use-after-free-Bedingung, bei der eine nachfolgende Anfrage desselben Workers veraltete, hängende Speicherzustände las und darauf verzweigte.
Was hat das mit MISRA zu tun?
Wer die Regeln von MISRA C und MISRA C++ prüft, findet genau diese Muster explizit verboten – in sicherheitskritischen Umgebungen:
- Das Verbot von setjmp und longjmp (MISRA C Regel 21.4 / MISRA C++ Regel 17-0-5): MISRA verbietet nicht-lokale Sprünge vollständig, weil sie das strukturelle Standard-Cleanup umgehen, Ressourcen verwaist zurücklassen und Speicher in unbestimmte Zustände versetzen. PHPs Verlass auf longjmp()-artige Abbrüche zur Behandlung fataler Fehler ist genau das Anti-Pattern, das MISRA verhindert.
- Deterministische Zustandsverwaltung: MISRA-Regeln erzwingen eine strikte Lebenszyklusverfolgung für Variablen und Speicher. Nicht initialisierte Variablen, hängende Zeiger und die Wiederverwendung veralteter globaler Zustände über Schleifen oder Routinen hinweg lösen Pflicht-Warnungen der statischen Analyse aus.
Kurz gesagt: Die Schwachstellen, die das PHP-Ökosystem erschütterten, sind Dinge, die ein rigoroses MISRA-konformes Static-Analysis-Tool sofort melden würde.
Die Lehre: Defensive Programmierung gilt überall
Wir neigen dazu, Softwareentwicklung in Silos aufzuteilen:
- Embedded/Sicherheitskritisch: Braucht strikte statische Analyse, MISRA-Konformität, Nulltoleranz gegenüber Speicherfehlern und formale Verifikation.
- Enterprise/Web/Cloud: Verlässt sich auf schnelle Iterationen, automatische Garbage Collection und High-Level-Sprachsicherheit.
PHP2Shell beweist, dass diese Grenze eine Fata Morgana ist. Enterprise-Webinfrastruktur ist nur so sicher wie die nicht verwalteten Low-Level-C/C++-Runtimes, Compiler und Abhängigkeiten, auf denen sie läuft.
Während Teams zunehmend KI-Agenten und automatisierte Werkzeuge (wie CppDepend) in ihre Workflows integrieren, um technische Schulden, zyklomatische Komplexität und strukturelle Integrität zu steuern, bleibt der Kernauftrag klar: Sichere Codierstandards sollten nicht nur Autos und Herzschrittmachern vorbehalten sein. Die rigorose Disziplin struktureller Code-Governance, striktes Ressourcen-Lebenszyklusmanagement und automatisierte statische Analyse auf alle Softwareschichten anzuwenden, ist der einzige Weg, moderne Tech-Stacks von systemischen Low-Level-Fehlern zu isolieren.