PHP, FortiGate, UniFi: patch-urile urgente din octombrie 2026

Miercuri, anunțul de securitate PHP. Joi dimineață, un e-mail de la Fortinet cu subiectul „Immediate action required” și fără niciun detaliu tehnic. Cu o săptămână înainte, un buletin Ubiquiti. Dacă administrezi serverele unei firme mici, ai primit probabil toate trei și te-ai întrebat dacă e coincidență.

Nu este. Cele trei actualizări au aceeași cauză: producătorii își testează acum codul cu modele AI de frontieră și găsesc în câteva luni vulnerabilități cât găseau înainte în ani. Aceleași modele sunt disponibile și atacatorilor, deci fereastra dintre publicarea patch-ului și primul exploit funcțional s-a redus la zile. Fortinet o spune direct în anunțul său, iar la PHP tentativele de exploatare au început cu patru zile înainte de publicare.

Articolul spune exact ce versiuni instalezi pentru fiecare produs, ce faci în orele până la fereastra de mentenanță și cum verifici că ai terminat. Toate versiunile sunt luate din anunțurile oficiale, verificate pe 22 octombrie 2026, cu linkuri în text.

Completare din 24 octombrie: cititorii ne-au semnalat că aceeași săptămână a adus actualizări critice și pentru nginx, Node.js și GitLab. Le-am adăugat în tabel și într-o secțiune separată, mai jos.

De ce vin toate odată

Din aprilie 2026, Anthropic, OpenAI și Google rulează programe prin care modelele lor caută vulnerabilități în software larg folosit, împreună cu producătorii. Fortinet scrie că a integrat aceste modele în procesul propriu de testare și mulțumește explicit celor trei companii pentru colaborare. Vulnerabilitățile din PHP au fost găsite de Wiz, Calif și OpenAI cu Gemini 4 Argon și GPT-5.6 Sol, conform analizei Wiz.

Consecința practică pentru tine nu e volumul, ci viteza. Fortinet a decis să publice detaliile abia pe 10 noiembrie, pentru că un model AI poate reconstrui exploitul din diferența dintre două versiuni în ore. La PHP, detaliile s-au scurs cu o zi înainte de termen, iar Amazon a văzut tentative de exploatare din 17 octombrie. Regula veche, „aplicăm patch-urile la fereastra de mentenanță de luna viitoare”, nu mai ține.

PHP: două vulnerabilități care afectează orice site

Cele două vulnerabilități, numite „php2shell” de cercetători, permit executarea de cod pe server dintr-o cerere HTTP, fără cont și fără să conteze aplicația de deasupra. WordPress, Drupal, Joomla, un CRM scris intern, toate sunt afectate la fel, pentru că problema este în motorul PHP, nu în aplicație. Anunțul PHP spune că orice instalare care servește cereri web este expusă: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP, LiteSpeed. Riscul cel mai mare este la mod_php, unde exploitul rulează înainte de orice linie din aplicație.

Toate versiunile din ultimul deceniu sunt afectate. Pentru 8.2, 8.3, 8.4 și 8.5 există versiuni corectate. Pentru 7.4, 8.0 și 8.1, echipa PHP a publicat doar patch-uri de sursă, fără pachete. Pentru 7.3 și mai vechi nu există nimic; CISA recomandă scoaterea acestor sisteme de pe internet până la migrare.

Cum aplici patch-ul pe un server Ubuntu sau Debian

Distribuțiile au primit patch-urile înainte de publicare, deci pachetele sunt în depozitele obișnuite.

1. Vezi ce versiune servește cererile, nu doar ce răspunde php -v din terminal, pentru că pot fi diferite:

php-fpm8.3 -v
apt list --installed 2>/dev/null | grep -E '^php|^libapache2-mod-php'

2. Actualizează și repornește procesele:

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm apache2

3. Verifică din exterior. Într-un fișier temporar v.php cu conținutul <?php echo PHP_VERSION; vezi versiunea reală servită, apoi șterge fișierul.

Pentru Docker, reconstruiești imaginea de la php:8.3-fpm sau echivalent și repornești containerul. Pentru cPanel, Plesk sau găzduire partajată, versiunea se schimbă din panou sau de către furnizor; întreabă-l în scris dacă a aplicat 8.3.36 sau echivalentul. WordPress nu are nevoie de o actualizare separată.

Ce faci până aplici patch-ul

PHP publică o setare care blochează calea de atac confirmată pentru CVE-2026-109619. Se pune în configurația pool-ului FPM sau în php.ini, nu prin ini_set() sau .user.ini, pentru că acelea se aplică prea târziu:

php_admin_value[session.upload_progress.enabled] = 0

Apoi repornești toate procesele PHP. Pe PHP 8.5 se adaugă și fatal_error_backtraces = 0. PHP spune clar că aceste setări reduc expunerea, dar nu fac instalarea sigură. Dacă site-ul trece prin Cloudflare, regulile WAF publicate pe 21 octombrie blochează vectorii cunoscuți; dacă nu trece, este un argument bun pentru a-l pune în spatele unui tunel.

Semnele de exploatare, după Wiz: cereri multipart neobișnuite urmate de erori de memorie, răspunsuri 500 repetate, cookie-uri PHPSESSID foarte mari sau malformate, procese PHP care pornesc shell-uri. Amazon recomandă ca investigația să înceapă de la 17 octombrie.

FortiGate: actualizare critică fără detalii

Fortinet a publicat pe 21 octombrie actualizările pentru FortiMail și FortiAuthenticator, iar pe 22 octombrie pe cele pentru FortiOS, FortiManager și FortiAnalyzer. Versiunile corectate sunt în tabelul de mai sus. Detaliile vulnerabilităților apar pe pagina PSIRT abia pe 10 noiembrie, deci nu știi ce se exploatează și cum. Fortinet cere tratarea ca prioritate, nu ca mentenanță de rutină, începând cu echipamentele expuse pe internet.

Cum aplici patch-ul

1. Inventariază echipamentele și notează pe fiecare ramura curentă (7.2, 7.4, 7.6 sau 8.0). Ținta este prima versiune corectată din aceeași ramură, nu un salt de ramură în grabă.
2. Fă backup la configurație din System › Configuration › Backup, sau cu execute backup config din consolă.
3. Verifică traseul de upgrade în System › Fabric Management sau pe pagina de upgrade path a Fortinet; unele salturi cer o versiune intermediară.
4. Aplică upgrade-ul pe FortiManager înainte de FortiGate-urile administrate de el, altfel riști incompatibilitate.
5. După repornire, confirmă versiunea în System › Status și testează VPN-ul și politicile principale.

Ce faci până la fereastra de mentenanță

Vulnerabilitățile Fortinet din ultimii ani au fost aproape toate în interfața de administrare sau în portalul SSL-VPN. Fortinet recomandă explicit aceleași lucruri: restricționarea accesului HTTPS și SSH la IP-uri de încredere sau dezactivarea lui pe interfața externă, FortiManager niciodată expus pe internet, MFA pe toți administratorii. Din consolă:

config system interface
    edit "wan1"
        set allowaccess ping
    next
end
config system admin
    edit "admin"
        set trusthost1 10.0.0.0 255.255.255.0
    next
end

Prima comandă lasă pe interfața externă doar ping. A doua limitează contul de administrator la rețeaua internă. Dacă administrezi echipamentul de la distanță, intri prin VPN, nu prin portul de management.

UniFi: buletine la câteva săptămâni

Ubiquiti publică din vară buletine de securitate aproape lunar. Buletinul 067 a avut 22 de vulnerabilități, 21 cu scor peste 9.0, inclusiv o ocolire a autentificării pe UniFi OS. Buletinele 069 din 22 septembrie și 070 din 14 octombrie sunt clasificate „High”; conținutul lor se citește direct pe pagina Ubiquiti, pentru că nu este reluat de alte surse. Trei vulnerabilități din buletinul 064 sunt în catalogul CISA de vulnerabilități exploatate.

Pașii sunt aceiași la fiecare buletin:

1. În consola UniFi, Settings › Control Plane › Updates (sau Console Settings › Updates pe versiunile mai vechi): actualizezi UniFi OS, apoi aplicațiile Network, Protect, Access, Talk, Connect, fiecare la versiunea minimă din buletin.
2. Activezi actualizările automate pentru aplicații, dar lași UniFi OS pe aprobare manuală, ca să controlezi repornirea.
3. Verifici că portul 443 al consolei nu este redirecționat din router spre internet. Accesul de la distanță se face prin contul UI cu MFA sau prin VPN, nu prin port forwarding.
4. Dispozitivele adoptate (switch-uri, access point-uri) primesc firmware-ul din aceeași pagină; buletinele includ uneori și versiuni minime pentru ele.

nginx, Node.js și GitLab: completarea din 24 octombrie

Trei produse pe care le găsești pe aproape orice server de aplicații au avut și ele versiuni de securitate în aceeași săptămână. Două dintre ele au același profil ca PHP: executare de cod fără autentificare, în cod vechi de peste zece ani.

nginx a publicat pe 14 octombrie versiunile 1.30.6 și 1.31.7, care corectează cinci vulnerabilități. Trei sunt depășiri de buffer pe care F5 le notează 9.2, cu posibilă executare de cod, dar fiecare cere o configurație anume: directiva alias combinată cu rewrite (afectează versiunile de la 0.1.29 încoace), evaluarea de variabile în map și blocuri similare, sau aio activ. A patra permite ocolirea verificării certificatului de client când sunt active TLS session tickets, a cincea privește HTTP/3. nginx însuși le notează „medium”, pentru că executarea de cod cere ASLR dezactivat sau ocolit. Verifici cu nginx -v și nginx -T | grep -E 'alias|aio|map|ssl_session_tickets'; dacă niciuna nu apare, riscul este mic, dar actualizarea rămâne cea mai simplă soluție. Pe Ubuntu și Debian, pachetul vine din depozitele distribuției, cu același apt upgrade ca pentru PHP.

Node.js a publicat pe 21 octombrie versiunile 26.12.1, 24.22.1 și 22.23.4, cu zece vulnerabilități. Cea mai gravă, CVE-2026-111497, numită „Node2Shell”, este în decodorul Brotli: un flux comprimat malformat scrie în afara buffer-ului și poate duce la executare de cod. Un server Node simplu nu decomprimă singur corpul cererilor. Riscul apare când aplicația folosește Express 5 sau body-parser cu decompresie, când face fetch() către servere pe care nu le controlezi, sau când folosește direct node:zlib. Versiunile 20, 23 și 25 au ieșit din suport și nu primesc fix. Verifici cu node -v; actualizezi prin nvm, prin pachetele NodeSource sau reconstruind imaginea Docker de la node:24 sau node:22. Bun are fix-ul în 1.4.4.

GitLab este cazul cel mai înșelător. Pe 12 octombrie a corectat CVE-2026-97229, o depășire de întreg în compilatorul de expresii regulate, CVSS 10.0. Pe 21 octombrie a publicat alt bug din același compilator, CVE-2026-110264, tot 10.0, cu cod afectat din GitLab 7.0, din 2014. Instanțele actualizate pe 12 octombrie sunt din nou vulnerabile, pentru că versiunile de atunci (19.4.2, 19.3.5, 19.2.8) stau cu un patch sub cele noi. GitLab nu publică condițiile de exploatare și nu oferă workaround, deci nu te poți exclude prin configurație. Versiunile corectate sunt în tabel; pentru ramurile 18.11 până la 19.2, fix-urile au fost publicate în afara politicii obișnuite de suport. GitLab.com rulează deja versiunea corectată, deci acest punct privește doar instalările self-managed. Verifici versiunea în Admin › Overview sau cu gitlab-rake gitlab:env:info.

Ce poți face de mâine, indiferent de producător

Săptămâna asta se repetă. Programele AI de testare au găsit zeci de mii de vulnerabilități care încă nu au fost patch-uite, iar producătorii le livrează în valuri. Patru lucruri reduc efortul la următorul val:

1. Un inventar scris cu fiecare echipament și aplicație expusă pe internet, versiunea curentă și cine o actualizează. Fără el, pierzi prima zi căutând ce ai.
2. Nicio interfață de administrare pe internet. Firewall, consolă UniFi, panou de hosting, phpMyAdmin: toate în spatele unui VPN sau al unui tunel cu autentificare. Majoritatea vulnerabilităților critice din 2026 sunt în interfețe de management.
3. O fereastră de mentenanță săptămânală agreată cu firma, de exemplu marți la 7:00, în care actualizările critice se aplică fără discuții suplimentare.
4. Abonare la anunțurile producătorilor: PSIRT Fortinet, buletinele Ubiquiti, lista de anunțuri PHP, nginx-announce, blogul de securitate Node.js, lista GitLab. E-mailul de la Fortinet a ajuns la clienții înregistrați cu o zi înainte de presă, iar cazul GitLab arată că un patch din 12 ale lunii nu te scutește de cel din 21.

Unde nu se potrivește

Recomandările de mai sus presupun că ai acces de administrator la echipamente și la server. Pe găzduire partajată nu controlezi versiunea PHP la nivel de sistem, ci doar din panoul furnizorului, iar dacă furnizorul nu a actualizat, singura opțiune este mutarea. Pe echipamente Fortinet ieșite din suport, cum sunt modelele care nu mai primesc 7.2, nu există versiune corectată; ele se înlocuiesc sau se scot de pe internet. Pentru PHP 7.x și 8.0, patch-urile de sursă cer recompilare, lucru pe care nu îl recomandăm într-o firmă mică; migrarea la 8.3 este de obicei mai ieftină decât întreținerea unei versiuni compilate manual.

Cum procedăm noi

La clienții cu management IT externalizat, inventarul există deja: Brio Endpoint Manager ține versiunile de sistem și de aplicații pe servere Windows și Linux și citește configurația FortiGate, deci în dimineața anunțului știm în câteva minute ce echipamente sunt afectate și care sunt expuse. Actualizările PHP și de sistem intră în ferestrele de mentenanță configurate per client, iar echipamentele de rețea se actualizează manual, cu backup înainte și test după. Interfețele de administrare sunt închise din prima zi a contractului, nu după primul incident.

Dacă ai un FortiGate, o consolă UniFi sau un site PHP și nu ești sigur ce versiune rulează sau cine ar trebui să o actualizeze, scrie-ne cu modelul echipamentului sau adresa site-ului. Îți spunem în aceeași zi dacă ești afectat și ce trebuie făcut, iar dacă vrei, facem actualizarea noi, cu backup înainte.