El 21 de octubre de 2026 el proyecto PHP publicó parches para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como php2shell. Un atacante sin usuario ni contraseña puede, con peticiones HTTP manipuladas, leer memoria del servidor y ejecutar código con los permisos del proceso web. Si tu web es un WordPress, un PrestaShop, un Drupal, un Joomla, un Magento o una aplicación Laravel, corre sobre PHP y te afecta.
Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si tu servidor tiene una anterior, actualizar es la tarea de hoy.
Qué ha pasado, sin jerga
Son dos fallos en cómo PHP gestiona la memoria al atender una petición web.
- CVE-2026-109618 (memoria agotada a mitad de petición). Si PHP se queda sin memoria mientras prepara los datos de una petición, la limpieza posterior trata datos inválidos como si fueran válidos. Un atacante lo provoca con peticiones multipart (las de los formularios con ficheros) preparadas para agotar memoria aunque su tamaño parezca dentro de los límites. Aviso: GHSA-w8hw-w9fx-j79w.
- CVE-2026-109619 (estado que sobrevive entre peticiones). Un error fatal, como quedarse sin memoria o superar el tiempo máximo, interrumpe la limpieza. Parte del estado interno queda liberado pero accesible, y la siguiente petición que atiende el mismo proceso lo usa. Huntress lo describe como use-after-free en el heap sin autenticación, con fuga de memoria y ejecución remota de código. Aviso: GHSA-6wmf-4rv5-p3rp.
Ambas tienen una puntuación CVSS v4.0 de 9.2 sobre 10 (crítica). El post filtrado antes de la publicación hablaba de 10.0; la cifra oficial es 9.2.
La fuga de memoria tiene una consecuencia práctica: lo que el proceso PHP tenga cargado (contraseñas de base de datos, tokens, API keys, certificados) puede acabar en manos de quien explote el fallo. Wiz ha demostrado ejecución remota sin autenticación contra WordPress, Drupal y Joomla, además de esa vía de fuga.
A quién afecta
Según php.net, a todas las instalaciones de PHP que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php: Rapid7 explica que ahí el fallo es explotable antes de que llegue a ejecutarse el código de la aplicación, así que ningún plugin de seguridad de WordPress lo frena.
Por versiones:
| Rama de PHP | Versión corregida | Estado |
|---|---|---|
| 8.5 | 8.5.12 | Con soporte |
| 8.4 | 8.4.27 | Con soporte |
| 8.3 | 8.3.36 | Con soporte |
| 8.2 | 8.2.35 | Fin de vida el 31-dic-2026 |
| 8.1, 8.0, 7.4 | Sin versión oficial | Solo backports en código fuente |
PHP usa el 69,7% de las webs cuyo lenguaje de servidor se conoce, según W3Techs citado por Infosecurity Magazine. Si tu web se hizo con una plantilla de WordPress (por ejemplo, con el Kit Digital) y nadie la ha tocado desde la entrega, lo más probable es que siga en una versión de PHP sin parchear.
Cómo saber qué versión de PHP tienes
Hay tres formas, de más fácil a más fiable:
- Panel del hosting. En cPanel, Plesk o el panel propio de tu proveedor suele haber una sección “Versión de PHP” o “PHP Selector”. En WordPress también aparece en Herramientas → Salud del sitio → Información → Servidor.
php -vpor SSH. Ojo: muestra la versión de la línea de comandos, que puede no coincidir con la que atiende la web. En un servidor con varias versiones instaladas es habitual que difieran.phpinfo(). Un ficheroinfo.phpcon<?php phpinfo();en la raíz de la web muestra la versión y el SAPI que de verdad sirve las peticiones (la línea “Server API” dice si es FPM, Apache 2.0 Handler, que es mod_php, CGI o LiteSpeed). Bórralo en cuanto lo hayas mirado: ese fichero enseña a cualquiera la configuración del servidor.
Si usas los paquetes de tu distribución Linux (Debian, Ubuntu, RHEL y derivadas), el número de versión puede no coincidir con los de la tabla aunque el parche esté aplicado: las distribuciones LTS recibieron los parches antes y los integran en su propia numeración. Consulta el aviso de seguridad de tu distribución para el paquete de PHP.
Hosting compartido o VPS. En un hosting compartido el proveedor controla el binario de PHP y el php.ini global: tú eliges rama en el panel, pero el parche lo aplica él. Pregúntale por escrito si ya ha actualizado a las versiones corregidas. En un VPS o servidor dedicado lo haces tú, o quien te lleve el mantenimiento.
Qué hacer ahora
1. Actualizar
Pasa a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o instala el paquete parcheado de tu distribución. Después reinicia todos los procesos de PHP (el servicio php-fpm, Apache si usas mod_php, LiteSpeed). Mientras sigan vivos los procesos antiguos, sigue corriendo el código vulnerable.
Si estás en 8.2, el parche te cubre ahora, pero esa rama deja de recibir correcciones el 31 de diciembre de 2026. Conviene planificar ya el salto a 8.3 o superior.
2. Si estás en PHP 8.1 o anterior
El proyecto PHP ya no publica versiones para 8.1, 8.0 ni 7.4. Ha publicado backports mínimos en código fuente, en ramas de su GitHub, para quien compile PHP. Si eso no va contigo, tienes dos opciones: un proveedor o distribución que siga dando soporte a esa versión, o migrar la aplicación a 8.3 o superior. La migración puede romper plugins o código antiguo, así que se prueba en una copia antes de tocar producción.
3. Mitigaciones temporales mientras actualizas
Son las que publica el proyecto PHP. Reducen la exposición, no sustituyen a la actualización:
session.upload_progress.enabled = 0enphp.inio en la configuración del pool de PHP-FPM, y reiniciar todos los workers. No sirve ponerlo conini_set()ni en un.user.ini.- En PHP 8.5, además:
fatal_error_backtraces = 0. - Contra el agotamiento de memoria: limitar en el servidor web o en el proxy el tamaño de la petición y el número de campos, partes y cabeceras. Si la web no recibe subidas de ficheros,
post_max_size = 8M; si las recibe,32M.
En hosting compartido seguramente no tienes acceso a php.ini ni al pool: en ese caso la mitigación también es cosa del proveedor.
Si no puedes actualizar o sospechas que te han atacado
El NCSC británico recomienda que, si no puedes actualizar, busques indicios de compromiso y puertas traseras, y que, si tampoco puedes aplicar las mitigaciones, te plantees desconectar el sistema. Una web caída un día cuesta menos que una web que reparte malware o filtra los datos de tus clientes.
Qué mirar en una web PHP:
- Ficheros
.phpnuevos o modificados en carpetas donde no deberían estar, comowp-content/uploadso directorios de caché. - Usuarios administradores que nadie ha creado.
- Tareas programadas (cron) o procesos que no reconoces.
- Errores fatales por falta de memoria o por tiempo agotado en los logs de PHP a partir del 20 de octubre, sobre todo en peticiones POST multipart.
Si encuentras algo, o si tu servidor estuvo expuesto sin parchear, rota los secretos que el proceso PHP tenía en memoria: contraseña de la base de datos, claves de APIs (pasarela de pago, correo, CRM), tokens y, si el certificado TLS lo sirve el mismo proceso, también su clave. Por la fuga de memoria, actualizar no deshace lo que ya se haya filtrado. Si la web ya muestra señales de que alguien entró, en web hackeada contamos qué hacer en la primera hora.
Cronología
- 20 de octubre: un post en Hacker News publica los identificadores de las CVE antes de que acabe el embargo.
- 21 de octubre, 14:00 UTC: el proyecto PHP adelanta la publicación de los parches.
- 21 de octubre: el NCSC (Reino Unido) y CERT-EU emiten alertas. Rapid7 avisa de que espera explotación y de que varios equipos la están reproduciendo.
- 21 de octubre, 16:30 hora del este de EE. UU.: Huntress informa de que no ha observado explotación entre sus clientes.
Que no se haya visto explotación el 21 de octubre no da margen: los identificadores son públicos y hay equipos reproduciendo el fallo.
Los demás avisos de esa semana (Node.js, NGINX, GitLab, Railway, LiteLLM y los certificados de GoDaddy y eMudhra) están en el resumen de vulnerabilidades de octubre de 2026.
Si prefieres que lo hagamos nosotros
En Soamee mantenemos aplicaciones PHP y servidores de clientes, y podemos encargarnos de esta actualización. El proceso es el que describe este artículo, aplicado a tu caso:
- Inventario: qué webs y servidores tienes, qué versión de PHP y qué SAPI usa cada uno, y quién controla cada servidor (tú o el hosting).
- Mitigación inmediata donde la actualización no pueda hacerse el mismo día.
- Actualización a la versión corregida, o plan de migración si estás en 8.1 o anterior, probada antes en una copia.
- Verificación de que la web atiende peticiones con la versión nueva y de que no quedan procesos antiguos vivos.
- Revisión de indicios de compromiso y rotación de secretos si hace falta.
Ninguna actualización garantiza que un servidor no se haya visto comprometido antes de parchearlo; por eso el punto 5 va en la lista. Si quieres que lo revisemos, escríbenos o pide una consultoría gratuita. Si buscas a alguien que lleve el mantenimiento de forma continua, mira nuestro servicio de cloud y DevOps o de desarrollo web.