Vulnerabilități critice în PHP: ce trebuie să verifice primăriile și instituțiile la furnizorul de găzduire

Vulnerabilități critice în PHP: ce trebuie să verifice primăriile și instituțiile la furnizorul de găzduire
Două vulnerabilități PHP, cu scor 9,2 din 10, pot permite acces fără autentificare pe serverele afectate. Ce versiuni remediază problema și ce confirmări trebuie cerute furnizorului de găzduire.

Două vulnerabilități critice în PHP au determinat publicarea unor actualizări urgente pe 21 octombrie 2026. Pentru o primărie, o instituție sau o companie care utilizează aplicații web, întrebarea practică este dacă serverele proprii au primit aceste corecții. Un site care se deschide normal poate utiliza în continuare o versiune vulnerabilă.

Defectele sunt identificate prin codurile CVE-2026-109618 și CVE-2026-109619, fiecare având un scor CVSS v4.0 de 9,2 din 10. Aceste vulnerabilități pot permite executarea de cod de la distanță, fără autentificare, pe sistemele afectate. Articolul publicat de Centrul de Formare APSAP explică alerta și măsurile necesare, în baza avertizării DNSC și a documentelor tehnice internaționale.

Ce este PHP și unde îl puteți întâlni în instituție

PHP este un limbaj de programare utilizat pentru dezvoltarea site-urilor și aplicațiilor web. Rulează pe server și procesează, între altele, formulare, operațiuni de autentificare și interacțiuni cu baze de date. WordPress folosește PHP, iar alte aplicații pot include PHP fără ca utilizatorii finali să fie conștienți.

Prin urmare, verificarea trebuie să includă site-ul instituției, subdomeniile și aplicațiile furnizate de terți. Platformele de programări, sistemele de registratură sau alte servicii online sunt exemple pentru care merită solicitarea confirmării tehnologiei utilizate. Simplul fapt că o instituție are un site nu dovedește că acesta rulează PHP; confirmarea trebuie obținută de la administratorul tehnic sau de la furnizor.

De ce poate exista un risc chiar fără o parolă furată

Cele două probleme afectează nucleul PHP și privesc gestionarea memoriei; ele pot fi declanșate prin cereri construite special. În anumite configurații, procesarea vulnerabilă are loc înainte de a rula codul aplicației, astfel încât verificarea parolelor sau actualizarea pluginurilor nu remediază aceste defecte ale serverului.

Conform avizului echipei PHP, toate instalările PHP vulnerabile care procesează cereri web trebuie tratate ca expuse riscului. Aceasta reprezintă o avertizare privind posibilitatea compromiterii, nu o confirmare că fiecare site a fost exploatat.

Oprirea preventivă a unui site poate fi o măsură justificată

Pe 21 octombrie, guvernul olandez a confirmat că site-ul NCSC, centrul național de securitate cibernetică, fusese oprit temporar ca măsură de precauție. Comunicatul menționa că autoritatea nu observase exploatare activă la momentul publicării. Oprirea preventivă și un incident confirmat sunt situații distincte.

CERT-EU recomandă actualizarea imediată. Dacă aceasta nu este posibilă, organizațiile ar trebui să ia în considerare izolarea aplicațiilor expuse de rețelele publice până la aplicarea și verificarea corecției. Decizia trebuie discutată cu echipa tehnică, inclusiv pentru a anunța utilizatorii și a stabili un canal alternativ de comunicare.

Ce versiuni au primit corecțiile

Actualizările publicate de proiectul PHP pe 21 octombrie 2026 sunt:

Ramura utilizatăPrima versiune corectată pentru aceste vulnerabilități
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12

Distribuțiile Linux și alți furnizori pot livra corecții prin pachetele proprii, inclusiv adaptând remedierea pentru o versiune anterioară. Din acest motiv, solicitați identificarea pachetului instalat și confirmarea explicită că acesta remediază ambele vulnerabilități. Pentru PHP 8.1 și versiunile mai vechi, verificați politica de suport a furnizorului și planificați trecerea la o ramură susținută.

Ce să cereți în scris furnizorului de găzduire

O solicitare utilă identifică clar site-urile și aplicațiile vizate și cere răspunsuri verificabile:

  • Ce versiune PHP și ce pachet rulează efectiv fiecare aplicație?
  • Au fost aplicate corecțiile pentru CVE-2026-109618 și CVE-2026-109619? La ce dată și oră?
  • Au fost repornite procesele necesare și s-a verificat versiunea activă după intervenție?
  • Au fost verificate subdomeniile, mediile de test și aplicațiile mai vechi?
  • Au fost analizate jurnalele pentru indicii de compromitere? Dacă actualizarea nu este finalizată, care este termenul estimat și ce măsuri temporare s-au luat?

Răspunsul „avem actualizări automate” descrie un mecanism, dar nu confirmă în mod explicit aplicarea acestei corecții. Păstrați dovezi scrise ale intervenției și desemnați o persoană responsabilă care să urmărească răspunsurile pentru toate sistemele inventariate.

Actualizarea trebuie urmată de verificări

Administratorul trebuie să confirme că serviciile utilizează codul corectat și să verifice funcționalitățile importante pentru utilizatori. Dacă apar indicii de compromitere, investigația trebuie să includă păstrarea jurnaleleor și a altor dovezi. Instalarea actualizării nu demonstrează, de una singură, că sistemul nu fusese compromis anterior.

Pentru aprofundarea evaluării riscurilor, controalelor și neconformităților, consultați cursul „Auditor Securitate Cibernetică” al Centrului de Formare APSAP. Pagina programului prezintă pregătirea online și activitățile practice de audit.


Autor: Mirela-Ionela Brașoveanu, Centrul de Formare APSAP. Adaptare pentru Ghidul Primăriilor, după articolul original. Documentare actualizată la 22 octombrie 2026.

Surse oficiale consultate: avizul PHP și avizul CERT-EU (legate mai sus); informațiile operaționale NCSC-NL; comunicatul guvernului olandez. Alerta DNSC este menționată în articolul APSAP; pagina sa nu a putut fi consultată direct în cadrul acestei verificări.

Distribuie: