Šta je novo?

php2shell (CVE-2026-109618, CVE-2026-109619)

  • Začetnik teme Začetnik teme Aleksa
  • Datum pokretanja Datum pokretanja

Aleksa

Zapažen
Učlanjen(a)
01.01.1970
Poruke
114
Poena
20
Cudi me da nije pomenuto na forumu.
Veoma opasna ranjivost.
Instalirajte novu verziju PHP sto je pre moguce.

 
Zamisli zakasnio si 😁
 

Prilozi

  • IMG_5321.webp
    IMG_5321.webp
    56.2 KB · Pregleda: 103
Ja sam stari korisnik jos od ranih dana. Prilikom forumskih softverskih tranzicija datum se izgubio. Taj datum je verovatno 0 ili tako nesto u Linux epoch.
 
Ne resava se ovaj problem instalacijom nove verzije posto su pogodjene sve verzije od 5.x do ove poslednje vec patch-om koji treba da se pojavi ili se u medjuvremenu pojavio, nisam ispratio sta su objavili danas u 16h. Elem, postoji sitan hack koji je resavao trenutno problem ali nije trajno resenje i plus je uticao na neke funkcionalnosti oko upload-a.
 
Zanimljiv detalj iz teksta je da su na OOM problem naišli još 2024, ali se rešavanje razvuklo zbog kompatibilnosti, komplikacija oko samog fixa i manjka ljudi koji dovoljno dobro poznaju PHP internals. Tek kada su eksterni istraživači demonstrirali RCE, problem je dobio puni prioritet.

Inače, zakrpe su već objavljene: PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12.

Ko koristi PHP iz repozitorijuma Linux distribucije, neka proveri konkretan security update. Zakrpe se često backportuju, pa samo php -v nije pouzdan pokazatelj da li je ranjivost otklonjena. Nakon ažuriranja treba restartovati PHP-FPM, odnosno Apache ako se koristi mod_php.

Privremene mitigacije iz zvaničnog advisory-ja samo smanjuju rizik. Nijedna nije potpuna zamena za zakrpu.

 
Nije bas tako. Na problemu je mesecima radila ozbilja ekipa ljudi. Par dana pre objavljivanje patch-a, neko iz chainguard.dev ekipe je objavio na cemu se radi, nisu slucajno naboli problem ovi koji su objavili

 
Nisam ni tvrdio da niko nije radio na problemu, niti da je dovoljno samo preći na noviju verziju PHP-a. Poenta je u onome što i sama PHP fondacija navodi: za OOM problem su znali još 2024, ali je rad na zakrpi mesecima zapinjao zbog kompatibilnosti, različitih pristupa i manjka resursa. Tek kad je Calif 11. avgusta prijavio RCE sa istim uzrokom, problem je dobio najviši prioritet. Dakle, nije sporan trud ljudi, već koliko je vremena trebalo da se upali crveni alarm. Isto važi i za Chainguard - to što su 21. oktobra prekršili embargo i izbacili kontejnerske imidže par sati ranije jeste napravilo haos oko koordinisane objave, ali nema nikakve veze sa samim otkrivanjem propusta niti sa tim što je rešavanje ubrzano još u avgustu.

Što se same zaštite tiče, bitna je konkretna zakrpa, a ne samo broj verzije. Izašle su zakrpljene verzije 8.2.35, 8.3.36, 8.4.27 i 8.5.12, dok za starije grane mora da se proveri da li je distribucija uradila backport ispravke. Privremeni workaround (session.upload_progress.enabled=0) gasi samo praćenje napretka uploada kroz sesiju (ne i sam upload fajlova), ali ne pokriva sve vektore napada i svakako nije zamena za patch.

Pritom, priča nije skroz završena tim prvim zakrpama - PHP tim je 23. oktobra objavio upozorenje i za CVE-2026-115560 koji nije obuhvaćen ovim izdanjima. Doduše, zahteva prilično specifičnu kombinaciju podešavanja i koda u samoj aplikaciji, ali je svakako preporuka da session.upload_progress.enabled ostane isključen do narednog redovnog izdanja gde god postoji rizik.

Izvori:

https://thephp.foundation/blog/2026...ease-and-how-were-strengthening-php-security/

https://www.php.net/archive/2026.php
 
Nazad
Vrh Dno