Na kratko: Zend Engine je jedro PHP. Kodo PHP prevede v opcode, jih izvede v navideznem stroju in pri tem upravlja spremenljivke in pomnilnik. Od PHP 4 je v vsaki namestitvi PHP. Ker ranljivosti PHP2Shell ležijo v tem jedru, ne pomagajo vtičniki ali posodobitve CMS-ja, ampak samo posodobljen PHP s ponovnim zagonom.
Kaj je Zend Engine?
Zend Engine je del PHP, ki opravi pravo delo. Vse drugo, na primer povezava s spletnim strežnikom ali razširitve za podatkovne zbirke, temelji na njem. Primerjamo ga lahko z motorjem avtomobila: karoserija in oprema se razlikujeta, motor pa poganja vse.
Po priročniku PHP je ime nastalo iz imen razvijalcev Zeeva Suraskija in Andija Gutmansa. Engine je bil predstavljen sredi leta 1999 in je bil od PHP 4.0, izdanega maja 2000, jedro PHP. Od takrat so ga večkrat temeljito predelali.
| Različica PHP | Engine | Najpomembnejša sprememba po priročniku in RFC |
|---|---|---|
| PHP 4.0 (2000) | Zend Engine | prvo skupno jedro, boljša zmogljivost |
| PHP 5.0 (2004) | Zend Engine 2.0 | nov objektni model |
| PHP 7.0 (2015) | Zend Engine 3.0 | PHPNG: bolj kompaktne podatkovne strukture, AST |
| PHP 8.0 (2020) | nadaljnji razvoj | prevajalnik JIT kot del OPcache |
Gradniki: prevajalnik, navidezni stroj, pomnilnik
Engine deluje v jasno ločenih stopnjah. Od PHP 7 so po RFC o abstraktnem sintaktičnem drevesu do bajtne kode tri faze:
- Lexer: izvorno kodo razdeli na tokene, na primer ključne besede, imena spremenljivk in nize znakov.
- Parser: iz tokenov zgradi abstraktno sintaktično drevo (AST), ki prikazuje strukturo programa.
- Prevajalnik: iz AST ustvari polja op (op arrays), torej sezname opcode, po eno za datoteko in funkcijo.
- Izvajalnik (Zend VM): obdela opcode. Po RFC za JIT ima vsak opcode funkcijo handlerja, ki ga izvede.
- Upravljanje pomnilnika: za vsako zahtevo rezervira in sprosti pomnilnik ter pri tem nadzoruje mejo iz
memory_limit.
Tokene skripte je mogoče prikazati z razširitvijo Tokenizer. To je neškodljivo in poučno:
<?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";
}
}
Izpis prikaže vnose, kot sta T_VARIABLE: $summe ali T_LNUMBER: 2. S prav temi gradniki parser dela naprej.
Kako Zend Engine upravlja spremenljivke?
Vsaka spremenljivka PHP po priročniku leži v vsebniku z imenom zval. Vsebuje tip in vrednost ter podatke za upravljanje, med njimi števec referenc (refcount). Števec pove, koliko imen spremenljivk kaže na isti vsebnik.
<?php
$a = str_repeat('x', 10);
$b = $a; // brez kopiranja, obe kažeta na isto vrednost
$b .= 'y'; // šele zdaj se kopira (copy on write)
unset($a); // števec pade, pomnilnik se sprosti, ko doseže 0
Ko števec doseže nič, engine pomnilnik sprosti. Za krožne sklice med objekti obstaja dodatno čistilec pomnilnika (garbage collector). Več o tem v prispevku Upravljanje pomnilnika v PHP.
Predelava PHPNG za PHP 7 je posegla ravno sem. Po RFC Dmitryja Stogova in Zeeva Suraskija je šlo za bolj kompaktne podatkovne strukture in pametnejši prikaz vrednosti. RFC je navajal pridobitev zmogljivosti od 20 do 110 odstotkov v resničnih aplikacijah.
OPcache in JIT: razširitvi enginea
Brez predpomnilnika engine vsako skripto ob vsaki zahtevi prevede znova. OPcache pripravljene opcode hrani v skupnem pomnilniku. Od PHP 8.0 obstaja še prevajalnik JIT. Po RFC temelji na DynASM, orodju iz projekta LuaJIT, in strojno kodo ustvari neposredno iz bajtne kode. Navidezni stroj ostane nespremenjen; JIT zamenja samo vstopne točke handlerjev.
Za upravljavce to pomeni: OPcache in JIT engine pospešita, a ne spremenita njegovega vedenja ob napakah. Ranljivost v jedru ostane tudi z aktivnim predpomnilnikom.
Zakaj so ranljivosti v enginu posebej težke
Obe ranljivosti PHP2Shell ležita v jedru PHP. Pri CVE-2026-109618 lahko stanje Out of Memory engine prekine, medtem ko so podatki zahteve šele delno inicializirani; pri čiščenju se neveljavni podatki nato obravnavajo kot veljavni. Pri CVE-2026-109619 notranje stanje po sprostitvi pomnilnika ostane in ga lahko uporabi poznejša zahteva v istem workerju.
Popravljene različice 8.5.12, 8.4.27, 8.3.36 in 8.2.35 po priročniku PHP spremenijo tudi vedenje pomnilniške meje: memory_limit je tam mehka meja, nova nastavitev memory_hard_limit_percent določa trdo zgornjo mejo. Priročnik opozarja, da je različica, ki te nastavitve ne pozna, prizadeta zaradi ranljivosti. Pri distribucijah z backporti dodatno šteje dnevnik sprememb paketa.
Engine je naložen v vsakem procesu PHP. Po posodobitvi je zato treba znova zagnati vse workerje PHP-FPM, procese Apache z mod_php in druge storitve PHP.
Kaj se v notranjosti zgodi ob pomanjkanju pomnilnika, opisuje prispevek memory_limit in Out-of-Memory. Uvrstitev same ranljivosti je na strani CVE-2026-109618.
Kako PHP SOS pomaga konkretno?
- Preverjanje različice in stanja paketov: ugotovimo, katero stanje enginea dejansko teče, vključno z backporti vaše distribucije.
- Posodobitev in ponovni zagon: prek storitve popravljanja PHP namestimo posodobitev in preverimo, da ne ostane noben proces s staro kodo.
- Smiselne pomnilniške meje:
memory_limit, novo trdo mejo in meje cgroup uskladimo z vašo aplikacijo. - Preiskava nepravilnosti: zrušitve workerjev ali procese z izhodnim statusom 137 ocenimo in preverimo, ali za njimi lahko stoji napad.
Pogosta vprašanja
Od kod ime Zend Engine?
Ime je sestavljeno iz imen njenih razvijalcev: Zeev Suraski in Andi Gutmans. Po priročniku PHP je bil engine predstavljen sredi leta 1999 in je bil od PHP 4.0 maja 2000 jedro PHP.
Ali je Zend Engine samostojen izdelek, ki ga moram namestiti?
Ne. Zend Engine je stalni sestavni del vsake namestitve PHP. Kdor posodobi PHP, samodejno posodobi tudi engine. S komercialnimi izdelki podjetja Zend nima nobene zveze.
Kaj je opcode?
Opcode je posamezen ukaz za navidezni stroj PHP, na primer seštevanje, klic funkcije ali prireditev. Prevajalnik vsako skripto prevede v zaporedje takih ukazov, ki jih engine nato obdela.
Kaj ima Zend Engine opraviti z memory_limit?
Engine upravlja pomnilnik vsake zahteve in pri tem upošteva mejo iz memory_limit. Od varnostnih izdaj z dne 21. 10. 2026 je ta meja po priročniku mehka, dopolnjuje pa jo trda meja prek memory_hard_limit_percent.