---
title: "PHP2Shell și Node2Shell: e afectat site-ul tău? | Murarum"
description: "PHP și Node.js au corectat pe 21 octombrie 2026 vulnerabilități critice. Ce site-uri sunt expuse, ce versiuni le repară și ce întrebi agenția sau hostingul."
url: https://murarum.ro/articole/vulnerabilitati-php-node-octombrie-2026
language: ro
alternate_en: https://murarum.ro/en/insights/php-node-vulnerabilities-october-2026
---

7 min de citit · Mentenanță

# Când PHP și Node.js au avut vulnerabilități critice în aceeași săptămână, site-ul tău cine l-a păzit?

Dacă site-ul tău rulează pe PHP, cum rulează WordPress și multe alte CMS-uri, a fost expus la vulnerabilitățile critice corectate pe 21 octombrie 2026 până la actualizarea PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35\. O aplicație Node.js a fost expusă doar dacă decomprimă date Brotli trimise de un atacator; versiunile corectate sunt 22.23.4, 24.22.1 și 26.12.1\. Ce a decis care site-uri au fost protejate a fost dacă exista cineva care se simte responsabil de ele: tehnologia a contat mai puțin, pentru că PHP și Node.js au primit corecții în aceeași zi.

De Mircea Muraru · 26 octombrie 2026

Actualizat la 23 octombrie 2026: am adăugat avertizarea suplimentară publicată de PHP, CVE-2026-115560.

## Ce s-a întâmplat pe 21 octombrie

Pe 21 octombrie 2026, PHP și Node.js au publicat actualizări de securitate pentru vulnerabilități evaluate cu scorul CVSS 9.2, critic, în înregistrările CVE. Cercetătorii și presa le numesc PHP2Shell și Node2Shell. Numele nu vin de la proiectele în sine: PHP2Shell circulă în presa de securitate și la firmele din domeniu, iar Node2Shell e numele dat de echipa de cercetare Imperva.

PHP2Shell înseamnă două vulnerabilități, CVE-2026-109618 și CVE-2026-109619\. Amândouă sunt erori de memorie prin care un atacator poate rula cod pe server fără să se autentifice. PHP spune că e afectată orice instalare care servește pagini web, iar riscul cel mai mare e pe Apache cu mod\_php, unde atacul demonstrat funcționează înainte să ruleze codul site-ului. PHP 8.1 și versiunile mai vechi nu au primit nicio corecție. Pe 23 octombrie, PHP a mai publicat o problemă mai mică, legată de prima, CVE-2026-115560.

Node2Shell este CVE-2026-111497, o eroare în biblioteca de decomprimare Brotli inclusă în Node.js. Node.js o evaluează ca severitate ridicată. Contează doar când aplicația decomprimă date Brotli controlate de un atacator. Node.js 20 și versiunile mai vechi nu primesc corecție.

De ce te privește dacă ai doar un site de prezentare? Execuția de cod de la distanță înseamnă că altcineva rulează programele lui pe serverul tău: poate citi mesajele din formulare și baza de date, îți poate schimba paginile sau poate folosi serverul ca să atace alte site-uri. Anunțurile oficiale sunt pe [php.net](https://www.php.net/) și pe [blogul Node.js](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases).

Le exploatează cineva? PHP și Node.js nu au raportat exploatare reală, iar catalogul CISA al vulnerabilităților exploatate nu includea niciuna dintre cele trei pe 23 octombrie. Rapid7 spune că nu a observat exploatare reală pentru PHP, dar a primit semnalări de încercări de exploatare. E motiv suficient să faci actualizarea săptămâna aceasta.

În România, multe site-uri de IMM rulează pe hosting shared, unde versiunea de PHP se alege dintr-un meniu în panoul de control, iar actualizarea pachetelor o face furnizorul. După lansare, de obicei nimeni nu mai verifică ce versiune e selectată și dacă furnizorul a instalat deja corecțiile.

## Cum afli dacă te privește

### Ce întrebi agenția sau firma de hosting

- Ce versiune de PHP sau Node.js rulează azi site-ul nostru în producție și a fost actualizată după 21 octombrie?
- Dacă e PHP 8.1 sau mai vechi, care e planul de trecere la o versiune suportată, având în vedere că nu există corecție?
- Dacă e Node.js: aplicația decomprimă date Brotli venite din afară, de exemplu Express 5.0-5.3 sau body-parser 2.0-2.3 care acceptă cereri comprimate Brotli, fetch() care citește Brotli de pe un server pe care nu-l controlăm, sau zlib folosit direct? Un server HTTP simplu nu decomprimă Brotli singur.
- Cine face actualizarea și cine ne confirmă în scris că s-a făcut?

### Semnalele că nu răspunde nimeni

Dacă întrebarea rămâne fără răspuns 24 de ore, consideră că răspunsul e „nimeni”. La fel când răspunsul se plimbă între părți: agenția spune că PHP-ul îl actualizează hostingul, hostingul spune că versiunea o alege clientul. Alte semnale: nimeni nu știe versiunea, accesul la server e pe numele unui programator plecat, iar ultima modificare a fost lansarea. Dacă site-ul depinde de conturile unei singure agenții, citește [cum alegi un CMS fără să depinzi de agenție](https://murarum.ro/articole/cms-fara-dependenta-de-agentie).

## Ce am făcut: am fost acolo de la început și transparenți cu fiecare client

Mai important decât orele exacte au fost trei lucruri: am fost acolo din prima zi, i-am spus fiecărui client direct unde se află și problema s-a rezolvat. Pentru fiecare platformă construită sau cunoscută de noi, cu contract sau fără, am urmat aceeași ordine:

1. Inventarul. Am listat ce platforme ale clienților rulează PHP și care Node.js, cu versiunea exactă din producție. Pentru aplicațiile Node.js am verificat dacă codul decomprimă date Brotli venite din afară.
2. Un mesaj către fiecare client, pe limba afacerii: ce s-a întâmplat, dacă site-ul lui e expus, ce propunem și de ce avem nevoie de la el.
3. Acolo unde expunerea era reală și corecția nu putea fi aplicată imediat, am propus punerea site-ului în mentenanță până la aplicarea ei.
4. Am aplicat corecțiile, sau i-am cerut furnizorului de hosting să le aplice, și am testat fluxurile importante: formulare, autentificare, plăți.
5. Am confirmat în scris fiecărui client: versiunea de dinainte, versiunea de după și ce am verificat.

Rezultatul: toate platformele expuse de care ne ocupăm au fost actualizate, iar fiecare client a știut la fiecare pas ce se întâmplă, ce înseamnă pentru afacerea lui și ce urmează. Niciun client nu a trebuit să ne întrebe dacă e afectat.

Site-ul nostru rulează pe Next.js și Node.js. A doua zi după publicarea corecțiilor am trecut producția pe Node.js 22.23.4 și Next.js 16.4.2 și am verificat că, în codul nostru, nu decomprimăm cereri trimise comprimat Brotli.

Un model de mesaj, pe care îl poți adapta sau cere agenției tale:

> Pe 21 octombrie, PHP și Node.js au publicat corecții pentru vulnerabilități critice prin care un atacator poate rula cod pe server. Site-ul dumneavoastră rulează pe \[PHP / Node.js, versiunea\]. Site-ul \[este / nu este\] expus. Vă propunem actualizarea pe \[data\], \[fără întrerupere / cu o scurtă perioadă în mentenanță\]. Dacă actualizarea nu se poate face azi, vă recomandăm să ținem site-ul în mentenanță până atunci. Avem nevoie de acordul dumneavoastră \[și de acces la contul de hosting\]. Vă confirmăm în scris când am terminat, cu versiunea de dinainte și de după.

## De ce am făcut-o și pentru clienții fără contract

O parte din site-urile verificate au fost livrate ca proiect, fără un acord de mentenanță după lansare. Le-am verificat oricum, pentru că atunci când e vorba de site-ul lor, suntem agenția lor.

Partea incomodă: totul a mers pe bunăvoință. A depins de faptul că am avut timp în săptămâna respectivă, că mai aveam acces și că clientul a răspuns repede. Pe un asemenea model nu se poate baza nimeni, și tocmai de aceea există [mentenanța](https://murarum.ro/cum-lucram/mentenanta): un acord scris prin care cineva urmărește tehnologiile site-ului, cu un timp de reacție stabilit dinainte.

## „Punem site-ul în mentenanță” e o decizie de business

Un site oprit până la corecție costă: ore fără cereri de ofertă, comenzi sau rezervări. Un site expus lăsat online costă altfel: date ale clienților, pagini modificate de altcineva, un server folosit pentru atacuri și discuția cu clienții de după. Un programator îți poate spune dacă ești expus. Decizia de a opri site-ul îi aparține celui care conduce firma. Ajung cincisprezece minute și întrebările de mai jos:

1. Site-ul e expus? Pentru PHP, da, până rulează o versiune corectată. Pentru Node.js, doar dacă decomprimă date Brotli venite din afară.
2. Corecția se poate aplica azi? Dacă da, o aplici și nu mai e nevoie de mentenanță.
3. Ce date ține site-ul: formulare cu date personale, conturi de clienți, plăți?
4. Cât te costă o zi fără site: ce cereri, comenzi sau rezervări poți numi?
5. O pagină simplă, cu telefonul și adresa de email, poate ține locul site-ului o zi?
6. Cine decide și cine le spune clienților?

Dacă site-ul e expus, ține date ale clienților și nu poate fi corectat azi, o pagină simplă pentru o zi costă de obicei mai puțin decât alternativa.

## Ce trebuie să conțină un contract de mentenanță

Ca să nu depinzi de bunăvoință, contractul ar trebui să spună:

- Timpul de reacție la vulnerabilitățile critice, scris și stabilit pentru site-ul tău.
- Cine urmărește avertizările de securitate pentru tehnologiile exacte ale site-ului: limbaj, framework, CMS și principalele dependențe.
- Actualizări planificate de versiune majoră, ca să nu rămâi pe o versiune care nu mai primește corecții, cum au rămas săptămâna aceasta PHP 8.1 și Node.js 20.
- Un backup testat: cât de des se face, unde se păstrează și când s-a încercat ultima dată o restaurare.
- Un om anume pe care îl poți suna.

Pentru unele lucruri nu merită să plătești: un pachet de ore de suport care se resetează lunar, fără nicio evidență a ce s-a verificat; disponibilitate non-stop pentru orice problemă mică a unui site de prezentare; actualizări automate pentru tot, netestate, care schimbă un risc pe altul. Nivelurile noastre sunt pe pagina de [mentenanță](https://murarum.ro/cum-lucram/mentenanta). Platformele construite prin [dezvoltare software](https://murarum.ro/servicii/dezvoltare-software) se predau cu documentație și conturi pe numele firmei tale, ca oricine le întreține să poată lucra de acolo.

## Zece întrebări pentru site-ul tău, săptămâna aceasta

1. Ce versiune de PHP sau Node.js rulează azi site-ul în producție?
2. A fost actualizată după 21 octombrie 2026 și la ce versiune?
3. Dacă e PHP 8.1 sau mai vechi, ori Node.js 20 sau mai vechi, când trecem pe o versiune suportată?
4. Dacă e Node.js, aplicația decomprimă date Brotli venite din afară?
5. Cine urmărește avertizările de securitate pentru tehnologiile noastre, cu nume și prenume?
6. Cine are acces să actualizeze serverul și e contul pe numele firmei noastre?
7. Când s-a făcut ultimul backup și când s-a testat ultima dată o restaurare?
8. E scris undeva timpul de reacție la vulnerabilitățile critice?
9. Cine decide punerea site-ului în mentenanță și cine anunță clienții?
10. Dacă agenția noastră n-ar mai răspunde de mâine, ar putea altcineva să preia site-ul din documentația și conturile pe care le avem?

## Întrebări frecvente

### Site-ul meu WordPress e afectat de PHP2Shell?

WordPress rulează pe PHP, iar PHP spune că e afectată orice instalare care servește pagini web până la versiunile 8.5.12, 8.4.27, 8.3.36 sau 8.2.35\. PHP 8.1 și versiunile mai vechi nu au primit corecție, deci un site pe ele trebuie mutat pe o versiune suportată. Întreabă hostingul sau agenția ce versiune rulează în producție.

### Aplicația mea Node.js e afectată de Node2Shell (CVE-2026-111497)?

Doar dacă decomprimă date Brotli pe care le poate controla un atacator: Express 5.0-5.3 sau body-parser 2.0-2.3 care acceptă cereri comprimate Brotli, fetch() care citește Brotli de pe un server nesigur sau zlib folosit direct. Un server HTTP simplu nu decomprimă Brotli singur. Actualizează oricum la 22.23.4, 24.22.1 sau 26.12.1; Node.js 20 și versiunile mai vechi nu primesc corecție.

### Sunt exploatate PHP2Shell și Node2Shell?

PHP și Node.js nu au raportat exploatare reală, iar niciuna dintre cele trei vulnerabilități nu era în catalogul CISA al vulnerabilităților exploatate pe 23 octombrie 2026\. Rapid7 spune că nu a observat exploatare reală pentru PHP, dar a primit semnalări de încercări de exploatare.

### Există o soluție temporară dacă nu pot actualiza PHP imediat?

PHP indică setări care reduc riscul, de exemplu session.upload\_progress.enabled=0, recomandată și pentru problema suplimentară CVE-2026-115560, cu repornirea tuturor proceselor PHP după schimbare. PHP spune însă că nu există o protecție completă și că actualizarea e singura variantă sigură. Node.js nu oferă o soluție temporară pentru eroarea lui.

### Cine răspunde de securitatea site-ului după lansare?

Cel pe care îl numește contractul. Fără un contract de mentenanță, de multe ori nimeni: agenția a livrat un proiect, hostingul ține serverul pornit, iar versiunea de PHP sau Node.js dintre ele nu e a nimănui. Un contract de mentenanță numește un om și un timp de reacție scris.

[Mai ai întrebări? Scrie-ne](https://murarum.ro/contact)

## Vezi și

- [Dezvoltare software](https://murarum.ro/servicii/dezvoltare-software)
- [Toate studiile de caz](https://murarum.ro/proiecte)

[Un site de referință pentru o casă de avocatură penală](https://murarum.ro/proiecte/site-georgescu-gont): Georgescu & Gonț · Drept penal · 2023

[O platformă de management al lectorilor pentru Eventer.NET](https://murarum.ro/proiecte/aplicatie-eventer): Eventer.NET · Congrese medicale și evenimente · 2026

## Cine ți-ar fi patch-uit site-ul miercuri?

Dacă site-ul tău a fost livrat ca proiect și nu știi cine l-ar fi patch-uit miercuri, vorbim 20 de minute și îți spunem ce versiuni rulează.

[Hai să vorbim](https://murarum.ro/contact)

[office@murarum.ro](mailto:office@murarum.ro)

## Contact

- Email: office@murarum.ro
- Telefon: +40 761 339 149
- Începe o conversație: https://murarum.ro/contact