PHP2Shell: kritične PHP ranjivosti – ovako ih odmah zakrpajte

21. listopada 2026. | PHP | IT sigurnost

Dana 21. listopada 2026. PHP sigurnosni tim objavio je ažuriranja za sve još podržavane PHP verzije. Ona zatvaraju dvije kritične ranjivosti koje su postale poznate pod nazivom PHP2Shell. BSI je o tome izdao upozorenje i zahtijeva da se pogođeni sustavi bez odgode zakrpaju. Tko pokreće web-poslužitelj s PHP-om, trebao bi djelovati još danas. To vrijedi i za sve koji „samo“ pokreću WordPress, Nextcloud ili Joomla, jer te aplikacije rade na PHP-u.

Ovaj članak sažima što se dogodilo, koje su PHP verzije pogođene, koja vam je verzija sada potrebna i kako u nekoliko minuta provjeriti je li vaš poslužitelj zaštićen.

Što se dogodilo? Vremenski slijed

PHP sigurnosni tim unaprijed je najavio objavu ispravaka kako bi hosteri i administratori imali vremena za pripremu. Sama objava dogodila se 21. listopada 2026. BSI je isti dan izdao svoje upozorenje (verzija 1.1).

• 20. listopada 2026.: Prethodno upozorenje PHP sigurnosnog tima da će sljedeći dan izaći sigurnosna ažuriranja.
• 21. listopada 2026., 14:00 UTC (16:00 po srednjoeuropskom ljetnom vremenu): Objavljuju se zakrpe za PHP 8.5, 8.4, 8.3 i 8.2.
• 21. listopada 2026.: BSI upozorava na „kritične ranjivosti koje ugrožavaju web-aplikacije diljem svijeta“ i preporučuje da se bez odgode zakrpaju. Prema navodima BSI-ja veliki su pružatelji hostinga djelomice preventivno isključili poslužitelje s mreže.

Dvije PHP ranjivosti ukratko

Radi se o dvije odvojene pogreške u PHP jezgri: CVE-2026-109618 i CVE-2026-109619. Obje mogu, prema navodima PHP sigurnosnog tima, dovesti do toga da napadač može izvršiti programski kôd na poslužitelju bez prijave (unauthenticated Remote Code Execution). Ranjivosti su ocijenjene s CVSS v4.0: 9,2 (kritično).

Prema procjeni BSI-ja u trenutku objave nije bilo potvrđenih napada, ali je bilo nepotvrđenih naznaka pokušaja iskorištavanja. Kod kritičnih ranjivosti u tako raširenom softveru, prema iskustvu, treba računati s tim da napadači analiziraju ispravke i pripremaju automatizirane napade. Vremenski prozor za zakrpanje stoga je kratak.

Tko je pogođen?

Pogođen je u načelu svaki poslužitelj na kojem radi PHP, neovisno o tome kako je PHP povezan: PHP-FPM, mod_php u Apacheu, php-cgi, FrankenPHP ili LiteSpeed. Rizik je prema PHP sigurnosnom timu najveći kod Apachea s mod_php.

BSI izričito navodi aplikacije koje se temelje na PHP-u i stoga mogu biti također pogođene:

• Sustavi za upravljanje sadržajem: WordPress, Drupal, TYPO3, Joomla
• Sustavi web-trgovina: Magento
• Oblak i pohrana datoteka: Nextcloud
• Sučelja vatrozida: pfSense, OPNsense

Sama aplikacija pritom ne mora biti neispravna. Ranjivost je u PHP-u, pa ažuriranje WordPressa, Nextclouda & Co. samo po sebi ne pomaže. Mora se ažurirati PHP verzija na poslužitelju. Kod vatrozida poput pfSensea i OPNsensea ispravljena PHP verzija stiže putem odgovarajućeg ažuriranja firmwarea proizvođača.

Ove su PHP verzije sigurne

Ranjivosti su ispravljene u sljedećim verzijama. Sve ispod toga smatra se ranjivim.

Ovako provjeravate i ažurirate svoj poslužitelj

1. Utvrditi instaliranu PHP verziju

Na naredbenom retku poslužitelja php -v prikazuje verziju PHP-a za naredbeni redak. Web-poslužitelj može koristiti drugu PHP verziju. Stoga provjerite i verziju PHP-FPM-a odnosno Apache modula, primjerice naredbom php-fpm8.3 -v ili putem stranice koja ispisuje phpinfo() (nju nakon toga odmah ponovno uklonite).

2. Instalirati ažuriranje putem upravitelja paketa

Kod Debiana, Ubuntua, RHEL-a i srodnih sustava ispravljena verzija stiže putem uobičajenog upravitelja paketa, primjerice apt update && apt upgrade ili dnf upgrade. Kod vanjskih izvora poput Sury PPA ili Remi repozitorija novi se paketi obično pojavljuju pravodobno.

3. Ponovno pokrenuti PHP uslugu

Samo ažuriranje paketa nije dovoljno: pokrenuti PHP procesi zadržavaju stari kôd u memoriji. Ponovno pokrenite PHP-FPM (systemctl restart php8.3-fpm) odnosno Apache (systemctl restart apache2) i zatim provjerite jesu li procesi pokrenuti nakon ažuriranja.

4. Hostirane web-stranice

Kod shared hostinga ažuriranje u pravilu provodi pružatelj. U izborniku za kupce obično se PHP verzija može postaviti za svaku web-stranicu. Tamo odaberite jednu od gore navedenih sigurnih verzija ili se kod pružatelja raspitajte o stanju zakrpa. Prema navodima BSI-ja pojedini su pružatelji preventivno isključili poslužitelje s mreže. Ako je vaša stranica nakratko nedostupna, to može biti uzrok.

PHP 8.1 i starije: nema službenog ažuriranja

Za PHP 8.1 i starije više nema službenih sigurnosnih ažuriranja. Operateri takvih sustava imaju dvije mogućnosti:

• Prijeći na podržanu verziju (preporučeno). Što je verzija starija, to je veći trud prilagodbe aplikacije i proširenja, pa prijelaz treba prethodno testirati.
• Prenijeti ispravke unatrag (backport). PHP sigurnosni tim stavio je ispravke na raspolaganje u razvojnim granama na GitHubu. Tko PHP kompilira sam, može te izmjene preuzeti u starije verzije. To je privremeno rješenje i zahtijeva stručno znanje.

I PHP 8.2 podržan je samo do 31. prosinca 2026. Stoga već sada planirajte prelazak na PHP 8.4 ili 8.5 i ne odgađajte ga za prijelaz u novu godinu.

Privremene mjere i pitanje „Isključiti poslužitelj s mreže?“

PHP sigurnosni tim je uz najavu opisao i privremene zaštitne mjere. One smanjuju rizik, ali ne zatvaraju ranjivosti u potpunosti. Ne zamjenjuju ažuriranje i namijenjene su samo premošćivanju vremena do ažuriranja.

Treba li poslužitelj do ažuriranja isključiti s mreže, ovisi o njegovoj važnosti i dostupnosti. BSI navodi da su veliki pružatelji poduzeli taj korak. Kao pravilo palca vrijedi:

• Javno dostupan poslužitelj, ažuriranje je sada moguće: odmah zakrpati, isključivanje nije potrebno.
• Javno dostupan poslužitelj, ažuriranje nije moguće u kratkom roku: ograničiti pristup (primjerice vatrozidom samo za poznate adrese) ili privremeno isključiti uslugu, osobito kod mod_php.
• Poslužitelj dostupan samo interno: zakrpati pravodobno, hitnost je manja.

Česta pitanja

Moram li ažurirati WordPress, Joomla ili Nextcloud?

Ne zbog ove ranjivosti. Ona se nalazi u PHP-u, a ne u aplikaciji. Ažurirajte PHP verziju na poslužitelju. Ažuriranje aplikacije ipak je preporučljivo, neovisno o tome.

Kako mogu prepoznati je li netko već iskoristio ranjivost?

Pouzdanu tvrdnju teško je dati. Sumnjive su nepoznate PHP datoteke u web direktoriju, neuobičajeni procesi pod korisnikom web poslužitelja, novi korisnički računi ili cron zadaci te neuobičajen odlazni mrežni promet. U slučaju konkretne sumnje sustav treba forenzički pregledati i, ako postoji dvojba, ponovno postaviti.

Je li dovoljna Web Application Firewall?

Vatrozid može presresti poznate obrasce napada, ali nije zamjena za ažuriranje. Više o suradnji više slojeva zaštite pročitajte u našem članku Zaštita Odoo 19: vatrozid, 2FA & Web RBL. Ta načela vrijede za svaku web aplikaciju.

Je li Odoo pogođen?

Ne. Odoo je napisan u Pythonu i ne radi na PHP-u. Pogođene bi bile samo PHP aplikacije koje rade na istom poslužitelju.

Gdje mogu pronaći službene informacije?

Najavu PHP sigurnosnog tima pronaći ćete u arhivi vijesti na php.net (unos od 20. listopada 2026.), verzije na php.net/downloads. Upozorenje njemačkog BSI-ja nosi broj 2026-297981-1032 i objavljeno je na bsi.bund.de .

Podrška tvrtke Biricon IT Services

Ako niste sigurni koja PHP verzija radi na vašem poslužitelju ili trebate pomoć pri instaliranju zakrpa, rado ćemo vas podržati: pri popisu svih PHP sustava, pri instaliranju ažuriranja, pri prelasku na podržanu PHP verziju i pri provjeri kompromitiranosti. Kao IT pružatelj usluga brinemo se za poslužitelje, vatrozide i web aplikacije malih i srednjih poduzeća.

Javite nam se odmah

Stanje: 21. listopada 2026. Situacija se može brzo promijeniti; mjerodavne su objave PHP sigurnosnog tima i BSI-ja.