Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

Die Zend Engine: Das Herz von PHP

Die Zend Engine übersetzt PHP-Code in Opcodes und führt ihn aus. Wer ihre Bausteine kennt, versteht, warum Lücken im Kern wie PHP2Shell nur ein PHP-Update behebt.

Stand 5 Min. LesezeitPHP-Wissen

Kurz gesagt: Die Zend Engine ist der Kern von PHP. Sie übersetzt PHP-Code in Opcodes, führt diese in einer virtuellen Maschine aus und verwaltet dabei Variablen und Speicher. Seit PHP 4 steckt sie in jeder PHP-Installation. Weil die PHP2Shell-Lücken in diesem Kern liegen, helfen keine Plugins oder CMS-Updates, sondern nur ein aktualisiertes PHP mit Neustart.

Was ist die Zend Engine?

Die Zend Engine ist der Teil von PHP, der die eigentliche Arbeit macht. Alles andere, etwa die Anbindung an den Webserver oder Erweiterungen für Datenbanken, setzt auf ihr auf. Man kann sie mit dem Motor eines Autos vergleichen: Karosserie und Ausstattung unterscheiden sich, der Motor treibt alles an.

Laut PHP-Handbuch ist der Name aus den Vornamen der Entwickler Zeev Suraski und Andi Gutmans gebildet. Die Engine wurde Mitte 1999 vorgestellt und war ab PHP 4.0, erschienen im Mai 2000, der Kern von PHP. Seitdem wurde sie mehrfach grundlegend überarbeitet.

PHP-Version Engine Wichtigste Änderung laut Handbuch und RFCs
PHP 4.0 (2000) Zend Engine erster gemeinsamer Kern, bessere Leistung
PHP 5.0 (2004) Zend Engine 2.0 neues Objektmodell
PHP 7.0 (2015) Zend Engine 3.0 PHPNG: kompaktere Datenstrukturen, AST
PHP 8.0 (2020) Weiterentwicklung JIT-Compiler als Teil von OPcache

Die Bausteine: Compiler, virtuelle Maschine, Speicher

Die Engine arbeitet in klar getrennten Stufen. Seit PHP 7 sind es laut RFC zum abstrakten Syntaxbaum drei Phasen bis zum Bytecode:

  1. Lexer: zerlegt den Quelltext in Tokens, etwa Schlüsselwörter, Variablennamen und Zeichenketten.
  2. Parser: baut aus den Tokens einen abstrakten Syntaxbaum (AST), der die Struktur des Programms abbildet.
  3. Compiler: erzeugt aus dem AST Op-Arrays, also Listen von Opcodes, je eine pro Datei und Funktion.
  4. Executor (Zend VM): arbeitet die Opcodes ab. Laut JIT-RFC gehört zu jedem Opcode eine Handler-Funktion, die ihn ausführt.
  5. Speicherverwaltung: reserviert und gibt Speicher für jede Anfrage frei und überwacht dabei die Grenze aus memory_limit.

Die Tokens eines Skripts lassen sich mit der Erweiterung Tokenizer sichtbar machen. Das ist harmlos und lehrreich:

<?php
$code = '<?php $summe = 2 + 3; echo $summe;';
foreach (token_get_all($code) as $token) {
    if (is_array($token)) {
        echo token_name($token[0]), ': ', trim($token[1]), "\n";
    } else {
        echo 'Zeichen: ', $token, "\n";
    }
}

Die Ausgabe zeigt Einträge wie T_VARIABLE: $summe oder T_LNUMBER: 2. Genau mit diesen Bausteinen arbeitet der Parser weiter.

Wie verwaltet die Zend Engine Variablen?

Jede PHP-Variable liegt laut Handbuch in einem Container namens zval. Er enthält Typ und Wert sowie Verwaltungsangaben, darunter einen Referenzzähler (refcount). Der Zähler gibt an, wie viele Variablennamen auf denselben Container zeigen.

<?php
$a = str_repeat('x', 10);
$b = $a;        // kein Kopieren, beide zeigen auf denselben Wert
$b .= 'y';      // erst jetzt wird kopiert (copy on write)
unset($a);      // Zähler sinkt, Speicher wird frei, wenn er 0 erreicht

Erreicht der Zähler null, gibt die Engine den Speicher frei. Für Kreisbezüge zwischen Objekten gibt es zusätzlich einen Garbage Collector. Mehr dazu im Beitrag Speicherverwaltung in PHP.

Die Überarbeitung PHPNG für PHP 7 setzte genau hier an. Laut RFC von Dmitry Stogov und Zeev Suraski ging es um kompaktere Datenstrukturen und eine geschicktere Darstellung von Werten. Der RFC nannte Leistungsgewinne von 20 bis 110 Prozent in realen Anwendungen.

OPcache und JIT: Erweiterungen der Engine

Ohne Cache übersetzt die Engine jedes Skript bei jeder Anfrage neu. Der OPcache hält die fertigen Opcodes im gemeinsamen Speicher bereit. Seit PHP 8.0 gibt es zusätzlich einen JIT-Compiler. Laut RFC basiert er auf DynASM, einem Werkzeug aus dem LuaJIT-Projekt, und erzeugt Maschinencode direkt aus dem Bytecode. Die virtuelle Maschine bleibt dabei unverändert; der JIT ersetzt nur die Einsprungpunkte der Handler.

Für Betreiber heißt das: OPcache und JIT beschleunigen die Engine, ändern aber nichts an ihrem Verhalten bei Fehlern. Eine Lücke im Kern bleibt auch mit aktivem Cache bestehen.

Warum Lücken in der Engine besonders schwer wiegen

Die beiden PHP2Shell-Lücken liegen im Kern von PHP. Bei CVE-2026-109618 kann ein Out-of-Memory-Zustand die Engine unterbrechen, während Anfragedaten erst teilweise initialisiert sind; beim Aufräumen werden ungültige Daten dann als gültig behandelt. Bei CVE-2026-109619 bleibt interner Zustand nach dem Freigeben des Speichers bestehen und kann von einer späteren Anfrage im selben Worker genutzt werden.

Die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 ändern laut PHP-Handbuch auch das Verhalten der Speichergrenze: memory_limit ist dort eine weiche Grenze, eine neue Einstellung memory_hard_limit_percent legt eine harte Obergrenze fest. Das Handbuch weist darauf hin, dass eine Version, die diese Einstellung nicht kennt, von den Lücken betroffen ist. Bei Distributionen mit Backports zählt zusätzlich der Paket-Changelog.

Wichtig

Die Engine ist in jedem PHP-Prozess geladen. Nach dem Update müssen deshalb alle PHP-FPM-Worker, Apache-Prozesse mit mod_php und sonstigen PHP-Dienste neu gestartet werden.

Was im Inneren bei einem Speicherengpass passiert, beschreibt der Beitrag memory_limit und Out-of-Memory. Die Einordnung der Lücke selbst steht unter CVE-2026-109618.

Wie hilft PHP SOS konkret?

  • Version und Paketstand prüfen: Wir ermitteln, welcher Engine-Stand tatsächlich läuft, inklusive Backports Ihrer Distribution.
  • Aktualisieren und neu starten: Über den PHP-Patch-Service spielen wir das Update ein und kontrollieren, dass kein Prozess mit altem Code übrig bleibt.
  • Speichergrenzen sinnvoll setzen: Wir stimmen memory_limit, die neue harte Grenze und cgroup-Grenzen auf Ihre Anwendung ab.
  • Auffälligkeiten untersuchen: Abstürze von Workern oder Prozesse mit Exit-Status 137 ordnen wir ein und prüfen, ob ein Angriff dahinterstehen kann.

Häufige Fragen

Woher hat die Zend Engine ihren Namen?

Der Name setzt sich aus den Vornamen ihrer Entwickler zusammen: Zeev Suraski und Andi Gutmans. Die Engine wurde laut PHP-Handbuch Mitte 1999 vorgestellt und war ab PHP 4.0 im Mai 2000 der Kern von PHP.

Ist die Zend Engine ein eigenes Produkt, das ich installieren muss?

Nein. Die Zend Engine ist fester Bestandteil jeder PHP-Installation. Wer PHP aktualisiert, aktualisiert automatisch auch die Engine. Mit kommerziellen Produkten der Firma Zend hat das nichts zu tun.

Was ist ein Opcode?

Ein Opcode ist ein einzelner Befehl für die virtuelle Maschine von PHP, etwa eine Addition, ein Funktionsaufruf oder eine Zuweisung. Der Compiler übersetzt jedes Skript in eine Folge solcher Befehle, die die Engine dann abarbeitet.

Was hat die Zend Engine mit memory_limit zu tun?

Die Engine verwaltet den Speicher jeder Anfrage und achtet dabei auf die Grenze aus memory_limit. Seit den Sicherheitsreleases vom 21.10.2026 ist diese Grenze laut Handbuch eine weiche Grenze, ergänzt um eine harte Grenze über memory_hard_limit_percent.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe