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 encara compatibles. Tanquen dues vulnerabilitats crítiques que s'han fet conegudes com a PHP2Shell. El BSI n'ha emès un avís i exigeix aplicar immediatament els pegats als sistemes afectats. Qui operi un servidor web amb PHP hauria d'actuar avui mateix. Això val també per a tots els qui només operen un WordPress, Nextcloud o Joomla, perquè aquestes aplicacions s'executen sobre PHP.
Aquesta entrada 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'aquesta entrada
- Què ha passat? La cronologia
- Les dues vulnerabilitats de PHP d'un cop d'ull
- Qui està afectat?
- Aquestes versions de PHP són segures
- Així comproveu i actualitzeu el vostre servidor
- PHP 8.1 i anteriors: cap actualització oficial
- Mesures provisionals i la pregunta «Cal desconnectar el servidor?»
- Preguntes freqüents
- Suport de Biricon IT Services
Què ha passat? La cronologia
L'equip de seguretat de PHP va anunciar prèviament la publicació de les correccions perquè els proveïdors d'allotjament i els administradors tinguessin temps de preparar-se. La publicació va tenir lloc el 21 d'octubre de 2026. El BSI va emetre el mateix dia el seu avís (versió 1.1).
- 20 d'octubre de 2026: Avís previ de l'equip de seguretat de PHP que l'endemà apareixerien actualitzacions de seguretat.
- 21 d'octubre de 2026, 14:00 UTC (16:00 h CEST): Es publiquen els pegats per a PHP 8.5, 8.4, 8.3 i 8.2.
- 21 d'octubre de 2026: El BSI adverteix sobre les «vulnerabilitats crítiques que amenacen les aplicacions web a tot el món» i recomana aplicar els pegats immediatament. Segons el BSI, grans proveïdors d'allotjament han desconnectat en part servidors com a mesura preventiva.
Les dues vulnerabilitats de PHP d'un cop d'ull
Es tracta de dos errors separats al nucli de PHP: CVE-2026-109618 i CVE-2026-109619. Segons l'equip de seguretat de PHP, tots dos poden fer que un atacant pugui executar codi al servidor sense iniciar sessió (unauthenticated Remote Code Execution). Les vulnerabilitats es valoren amb 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 (Remote Code Execution), sense inici de sessió |
| Causa 1 | Memòria malmesa quan PHP es queda sense memòria principal durant el processament (Out-of-Memory) |
| Causa 2 | Estat global obsolet que es queda a la memòria entre sol·licituds |
| Especialment en perill | 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ó. Amb vulnerabilitats crítiques en un programari tan estès, l'experiència diu que s'ha d'esperar que els atacants analitzin les correccions i preparin atacs automatitzats. La finestra de temps per aplicar els pegats és, per tant, curta.
Qui està afectat?
Està afectat, en principi, qualsevol servidor on s'executi PHP, independentment de com estigui connectat PHP: PHP-FPM, mod_php a Apache, php-cgi, FrankenPHP o LiteSpeed. El risc és més alt, segons l'equip de seguretat de PHP, amb Apache amb mod_php.
El BSI esmenta expressament aplicacions que es basen en PHP i que, per això, poden estar afectades de retruc:
- Sistemes de gestió de continguts: WordPress, Drupal, TYPO3, Joomla
- Sistemes de botiga: Magento
- Núvol i emmagatzematge de fitxers: Nextcloud
- Interfícies de tallafoc: pfSense, OPNsense
L'aplicació mateixa no ha de tenir cap defecte. La vulnerabilitat és a PHP, per això una actualització de WordPress, Nextcloud & Co. sola no ajuda. Cal actualitzar la versió de PHP al servidor. En tallafocs com pfSense i OPNsense, la versió corregida de PHP arriba mitjançant l'actualització de microprogramari del fabricant corresponent.
Aquestes versions de PHP són segures
Les vulnerabilitats estan corregides en les versions següents. Tot el que quedi per sota es considera vulnerable.
| Branca de PHP | Mínim requerit | Nota |
|---|---|---|
| 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 acaba el 31 de desembre de 2026 |
| PHP 8.1 i anteriors | cap actualització oficial, vegeu a baix | |
Així comproveu i actualitzeu el vostre servidor
1. Determinar la versió de PHP instal·lada
A la línia d'ordres del servidor, php -v mostra la versió del PHP de la línia d'ordres. El servidor web pot utilitzar una altra versió de PHP. 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 phpinfo() (eliminar-la tot seguit immediatament).
2. Aplicar l'actualització mitjançant la gestió de paquets
A Debian, Ubuntu, RHEL i derivades, la versió corregida arriba mitjançant la gestió de paquets habitual, per exemple apt update && apt upgrade o dnf upgrade. Amb fonts externes com el PPA de Sury o el repositori de Remi, els paquets nous solen aparèixer aviat.
apt changelog php8.3-fpm o rpm -q --changelog php | grep CVE-2026-1096).
3. Reiniciar el servei PHP
Una actualització del paquet sola no n'hi ha prou: els processos de PHP en execució conserven el codi antic a la memòria. Reinicieu PHP-FPM (systemctl restart php8.3-fpm) o Apache (systemctl restart apache2) i comproveu després que els processos s'hagin iniciat després de l'actualització.
4. Webs allotjats
En l'allotjament compartit, normalment l'actualitza el proveïdor. Al menú de client se sol poder establir la versió de PHP per a cada web. Trieu-hi una de les versions segures esmentades més amunt, o pregunteu al proveïdor per l'estat dels pegats. Segons el BSI, alguns proveïdors han desconnectat servidors de la xarxa com a mesura preventiva. Si el vostre web no és accessible durant un breu període, aquesta pot ser la causa.
PHP 8.1 i anteriors: cap actualització oficial
Per a PHP 8.1 i anteriors ja no hi ha actualitzacions de seguretat oficials. Els operadors d'aquests sistemes tenen dues possibilitats:
- Canviar a una versió compatible (recomanat). Com més antiga és la versió, més gran és l'esforç d'adaptació per a l'aplicació i les extensions; per això, un canvi s'hauria de provar abans.
- Portar les correccions a versions anteriors (backport). L'equip de seguretat de PHP ha posat les correccions a disposició en branques de desenvolupament a GitHub. Qui compila PHP per si mateix pot incorporar aquests canvis a versions anteriors. És una solució provisional i requereix coneixements especialitzats.
També PHP 8.2 només és compatible fins al 31 de desembre de 2026. Planifiqueu per això ja ara el pas a PHP 8.4 o 8.5 i no l'ajorneu al canvi d'any.
Mesures provisionals i la pregunta «Cal desconnectar el servidor?»
Amb l'anunci, l'equip de seguretat de PHP també ha descrit mesures de protecció provisionals. Aquestes redueixen el risc, però no tanquen del tot les vulnerabilitats. No substitueixen l'actualització i només estan pensades per cobrir el temps fins a l'actualització.
Si un servidor s'hauria de desconnectar de la xarxa fins a l'actualització depèn de la seva importància i de la seva accessibilitat. El BSI exposa que grans proveïdors han fet aquest pas. Com a regla general:
- Servidor accessible públicament, actualització possible ara: aplicar el pegat de seguida, no cal apagar-lo.
- Servidor accessible públicament, actualització no possible a curt termini: restringir l'accés (per exemple, mitjançant el tallafoc només per a adreces conegudes) o desactivar el servei temporalment, especialment amb
mod_php. - Servidor només accessible internament: aplicar el pegat aviat, la urgència és menor.
Preguntes freqüents
He d’actualitzar WordPress, Joomla o Nextcloud?
No per culpa d’aquesta vulnerabilitat. Es troba a PHP, no a l’aplicació. Actualitzeu la versió de PHP del servidor. Una actualització de l’aplicació continua sent recomanable, independentment d’això.
Com puc saber si algú ja ha explotat la vulnerabilitat?
És difícil donar una resposta segura. Són indicis sospitosos els fitxers PHP desconeguts al directori web, els processos inusuals executats sota l’usuari del servidor web, els comptes d’usuari o les tasques cron noves i el trànsit de dades sortint inusual. Davant d’una sospita concreta, caldria sotmetre el sistema a una anàlisi forense i, en cas de dubte, tornar-lo a instal·lar.
N’hi ha prou amb un Web Application Firewall?
Un tallafoc pot interceptar patrons d’atac coneguts, però no substitueix l’actualització. Trobareu més informació sobre la combinació de diverses capes de protecció al nostre article Protegir Odoo 19: tallafoc, 2FA & Web RBL. Els principis són vàlids per a qualsevol aplicació web.
Odoo està afectat?
No. Odoo està escrit en Python i no s’executa sobre PHP. Només estarien afectades les aplicacions PHP que s’executin al mateix servidor.
On puc trobar la informació oficial?
L’anunci de l’equip de seguretat de PHP el trobareu als arxius de notícies de php.net (entrada del 20 d’octubre de 2026), les versions a php.net/downloads. L’avís del BSI porta el número 2026-297981-1032 i es pot consultar a bsi.bund.de on ha estat publicada.
Suport de Biricon IT Services
Si no esteu segurs de quina versió de PHP s’executa al vostre servidor o necessiteu ajuda per aplicar els pedaços, us ajudarem amb gust: amb l’inventari de tots els sistemes PHP, amb la instal·lació de les actualitzacions, amb el pas a una versió de PHP compatible i amb la comprovació de possibles compromisos. Com a proveïdor de serveis informàtics, gestionem servidors, tallafocs i aplicacions web per a petites i mitjanes empreses.
Poseu-vos en contacte amb nosaltres
Actualitzat el 21 d’octubre de 2026. La situació pot canviar en poc temps; són determinants les publicacions de l’equip de seguretat de PHP i del BSI.