21 d’octubre de 2026 | PHP | Seguretat informàtica
El 21 d’octubre de 2026, l’equip de seguretat de PHP va publicar actualitzacions per a totes les versions de PHP que encara reben suport. Corregeixen dues vulnerabilitats crítiques que s’han donat a conèixer amb el nom de PHP2Shell. El BSI ha emès una alerta al respecte i exigeix aplicar immediatament els pedaços als sistemes afectats. Si gestioneu un servidor web amb PHP, hauríeu d’actuar avui mateix. Això també s’aplica a qui «només» té un WordPress, un Nextcloud o un Joomla, perquè aquestes aplicacions funcionen amb PHP.
Aquest article resumeix què ha passat, quines versions de PHP estan afectades, quina versió necessiteu ara i com podeu comprovar en pocs minuts si el vostre servidor està protegit.
Contingut d’aquest article
- Què ha passat? Cronologia dels fets
- Resum de les dues vulnerabilitats de PHP
- Qui està afectat?
- Aquestes versions de PHP són segures
- Com comprovar i actualitzar el vostre servidor
- PHP 8.1 i versions anteriors: sense actualització oficial
- Mesures provisionals i la pregunta «Cal desconnectar el servidor?»
- Preguntes freqüents
- Suport de Biricon IT Services
Què ha passat? Cronologia dels fets
L’equip de seguretat de PHP va anunciar amb antelació la publicació de les correccions perquè els proveïdors d’allotjament i els administradors tinguessin temps de preparar-se. La publicació es va fer el 21 d’octubre de 2026. El BSI va emetre la seva alerta (versió 1.1) aquell mateix dia.
- 20 d’octubre de 2026: l’equip de seguretat de PHP avisa que l’endemà es publicaran actualitzacions de seguretat.
- 21 d’octubre de 2026, 14:00 UTC (16:00 h CEST): es publiquen els pedaços per a PHP 8.5, 8.4, 8.3 i 8.2.
- 21 d’octubre de 2026: el BSI alerta de les «vulnerabilitats crítiques que amenacen les aplicacions web d’arreu del món» i recomana aplicar els pedaços immediatament. Segons el BSI, alguns grans proveïdors d’allotjament han desconnectat servidors per precaució.
Resum de les dues vulnerabilitats de PHP
Es tracta de dos errors independents al nucli de PHP: CVE-2026-109618 i CVE-2026-109619. Segons l’equip de seguretat de PHP, tots dos poden permetre que un atacant executi codi al servidor sense autenticar-se (execució remota de codi sense autenticació). Les vulnerabilitats tenen una puntuació de CVSS v4.0: 9,2 (crítica).
| Característica | Significat |
|---|---|
| Identificadors | CVE-2026-109618 i CVE-2026-109619 |
| Valoració | CVSS v4.0: 9,2 — crítica |
| Impacte | Execució de codi al servidor (execució remota de codi), sense autenticació |
| Causa 1 | Corrupció de memòria quan PHP es queda sense memòria RAM durant el processament (Out-of-Memory) |
| Causa 2 | Estat global obsolet que es manté en memòria entre peticions |
| Risc especialment elevat | Apache amb mod_php |
Segons la valoració del BSI, en el moment de la publicació no hi havia atacs confirmats, però sí indicis no confirmats d’intents d’explotació. L’experiència indica que, davant de vulnerabilitats crítiques en un programari tan estès, cal esperar que els atacants analitzin les correccions i preparin atacs automatitzats. Per això, el marge de temps per aplicar els pedaços és curt.
Qui està afectat?
En principi, està afectat qualsevol servidor que executi PHP, independentment de com s’hi integri: PHP-FPM, mod_php a Apache, php-cgi, FrankenPHP o LiteSpeed. Segons l’equip de seguretat de PHP, el risc és més elevat amb Apache amb mod_php.
El BSI esmenta explícitament aplicacions basades en PHP que, per tant, també poden estar afectades:
- Sistemes de gestió de continguts: WordPress, Drupal, TYPO3, Joomla
- Plataformes de comerç electrònic: Magento
- Núvol i emmagatzematge de fitxers: Nextcloud
- Interfícies de tallafocs: pfSense, OPNsense
Perquè això passi, no cal que l’aplicació mateixa tingui cap error. La vulnerabilitat és a PHP; per tant, actualitzar només WordPress, Nextcloud & companyia no és suficient. Cal actualitzar la versió de PHP del servidor. En tallafocs com pfSense i OPNsense, la versió corregida de PHP arriba amb l’actualització de microprogramari corresponent del fabricant.
Aquestes versions de PHP són segures
Les vulnerabilitats s’han corregit en les versions següents. Totes les versions anteriors es consideren vulnerables.
| Branca de PHP | Versió mínima necessària | Observació |
|---|---|---|
| PHP 8.5 | 8.5.12 | branca actual |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | El suport finalitza el 31 de desembre de 2026 |
| PHP 8.1 i versions anteriors | sense actualització oficial; vegeu més avall | |
Com comprovar i actualitzar el vostre servidor
1. Identifiqueu la versió de PHP instal·lada
A la línia d’ordres del servidor, php -v mostra la versió de PHP de la línia d’ordres. El servidor web pot utilitzar una versió de PHP diferent. Per això, comproveu també la versió de PHP-FPM o del mòdul d’Apache, per exemple amb php-fpm8.3 -v o mitjançant una pàgina que mostri la sortida de phpinfo() (elimineu-la immediatament després de fer la comprovació).
2. Instal·leu l’actualització amb el gestor de paquets
A Debian, Ubuntu, RHEL i distribucions afins, la versió corregida arriba a través del gestor de paquets habitual, per exemple amb apt update && apt upgrade o dnf upgrade. En fonts de tercers com el PPA de Sury o el repositori de Remi, els paquets nous acostumen a estar disponibles ben aviat.
apt changelog php8.3-fpm o rpm -q --changelog php | grep CVE-2026-1096).
3. Reinicieu el servei de PHP
No n’hi ha prou d’actualitzar el paquet: els processos de PHP en execució mantenen el codi antic en memòria. Reinicieu PHP-FPM (systemctl restart php8.3-fpm) o Apache (systemctl restart apache2), segons el cas, i comproveu després que els processos s’hagin iniciat després de l’actualització.
4. Llocs web en serveis d’allotjament
En l’allotjament compartit, normalment és el proveïdor qui fa l’actualització. El tauler de client sol permetre configurar la versió de PHP per a cada lloc web. Seleccioneu-hi una de les versions segures indicades més amunt o pregunteu al proveïdor per l’estat dels pedaços. Segons el BSI, alguns proveïdors han desconnectat servidors per precaució. Si el vostre lloc web deixa de ser accessible durant una estona, aquesta en podria ser la causa.
PHP 8.1 i versions anteriors: sense actualització oficial
PHP 8.1 i les versions anteriors ja no reben actualitzacions oficials de seguretat. Els responsables d’aquests sistemes tenen dues opcions:
- Migrar a una versió amb suport (recomanat). Com més antiga sigui la versió, més feina caldrà per adaptar l’aplicació i les extensions; per això convé provar la migració abans de dur-la a terme.
- Adaptar les correccions a versions anteriors. L’equip de seguretat de PHP ha posat les correccions a disposició de tothom en branques de desenvolupament a GitHub. Qui compili PHP pel seu compte pot incorporar aquests canvis a versions anteriors. És una solució provisional que requereix coneixements especialitzats.
PHP 8.2 també deixarà de rebre suport el 31 de desembre de 2026. Per tant, planifiqueu ara la migració a PHP 8.4 o 8.5 i no l’ajorneu fins a final d’any.
Mesures provisionals i la pregunta «Cal desconnectar el servidor?»
Amb l’anunci, l’equip de seguretat de PHP també va descriure mesures provisionals de protecció. Redueixen el risc, però no corregeixen del tot les vulnerabilitats. No substitueixen l’actualització i només estan pensades per cobrir el període fins que es pugui aplicar.
La conveniència de desconnectar un servidor de la xarxa fins que s’actualitzi depèn de la seva importància i de qui hi pugui accedir. El BSI assenyala que grans proveïdors han pres aquesta mesura. Com a criteri general:
- Servidor accessible públicament que es pot actualitzar ara: apliqueu els pedaços immediatament; no cal desconnectar-lo.
- Servidor accessible públicament que no es pot actualitzar a curt termini: restringiu-ne l’accés (per exemple, amb un tallafoc que només permeti adreces conegudes) o desactiveu temporalment el servei, especialment si utilitza
mod_php. - Servidor accessible només internament: apliqueu els pedaços aviat; la urgència és menor.
Preguntes freqüents
He d’actualitzar WordPress, Joomla o Nextcloud?
Per aquesta vulnerabilitat, no. Es troba a PHP, no a l’aplicació. Actualitzeu la versió de PHP del servidor. Independentment d’això, també és recomanable actualitzar l’aplicació.
Com puc saber si algú ja ha explotat la vulnerabilitat?
És difícil afirmar-ho amb certesa. Alguns senyals d’alerta són fitxers PHP desconeguts al directori web, processos inusuals executats amb l’usuari del servidor web, comptes d’usuari o tasques cron nous i trànsit de sortida inusual. Si hi ha una sospita concreta, cal fer una anàlisi forense del sistema i, en cas de dubte, reinstal·lar-lo des de zero.
N’hi ha prou amb un tallafoc d’aplicacions web?
Un tallafoc pot bloquejar patrons d’atac coneguts, però no substitueix l’actualització. Trobareu més informació sobre com es complementen diverses capes de protecció al nostre article Com protegir Odoo 19: tallafoc, 2FA & Web RBL. Els principis són aplicables a qualsevol aplicació web.
Odoo està afectat?
No. Odoo està escrit en Python i no funciona amb PHP. Només estarien afectades les aplicacions PHP que s’executessin al mateix servidor.
On puc trobar la informació oficial?
Trobareu l’anunci de l’equip de seguretat de PHP als arxius de notícies de php.net (entrada del 20 d’octubre de 2026), i les versions a php.net/downloads. L’alerta del BSI té el número 2026-297981-1032 i està publicada a bsi.bund.de .
Suport de Biricon IT Services
Si no teniu clar quina versió de PHP s’executa al vostre servidor o necessiteu ajuda per aplicar els pedaços, us podem ajudar amb l’inventari de tots els sistemes PHP, la instal·lació de les actualitzacions, la migració a una versió de PHP amb suport i la comprovació de possibles intrusions. Com a proveïdor de serveis informàtics, gestionem servidors, tallafocs i aplicacions web per a petites i mitjanes empreses.
Informació actualitzada el 21 d’octubre de 2026. La situació pot canviar ràpidament; les fonts de referència són les publicacions de l’equip de seguretat de PHP i del BSI.