PHP2Shell: qué significa la vulnerabilidad crítica de PHP para tu web y qué hacer ahora

• Qué: dos fallos críticos en el propio PHP (CVE-2026-109618 y CVE-2026-109619), ambos con una puntuación CVSS v4.0 de 9,2 según el proyecto PHP. Pueden permitir la ejecución remota de código sin autenticación.
• A quién: según el proyecto PHP, a todas las instalaciones de PHP que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto considera que el riesgo es mayor con mod_php.
• Solución: actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Las medidas provisionales solo reducen determinadas vías de ataque; según el proyecto PHP, únicamente la actualización resuelve el problema por completo.
• Versiones antiguas: PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. El equipo de seguridad de PHP ha publicado retroportes mínimos del código fuente para 7.4, 8.0 y 8.1; algunas distribuciones y proveedores de soporte extendido (LTS) ofrecen sus propios paquetes.
• Qué significa para ti: si tu web funciona con WordPress, Joomla, una tienda online o cualquier otro software en PHP, pregunta hoy mismo a tu proveedor de hosting qué versión de PHP se está usando y si la corrección está instalada. Más abajo te explicamos cómo comprobarlo tú mismo.

PHP es el lenguaje de programación con el que muchísimas webs generan sus páginas en el servidor: gestores de contenidos como WordPress, Joomla y TYPO3, tiendas online como WooCommerce, Shopware o Magento, foros, software de reservas o de áreas de socios. Cuando alguien abre una de esas páginas, un proceso de PHP atiende la petición en el servidor.

Justo ahí están los dos fallos. El aviso de seguridad del proyecto PHP del 21 de octubre de 2026 los describe así:

• CVE-2026-109618 – «RCE via OOM corruption»: la gestión de la falta de memoria (out of memory) puede interrumpir PHP cuando los datos internos de la petición solo están inicializados en parte. La limpieza de la petición puede entonces tratar esos datos no válidos como si fueran válidos.
• CVE-2026-109619 – «RCE via stale global state»: un estado interno que pertenece a una petición puede sobrevivir aunque la memoria que lo sostiene ya se haya liberado. Una petición posterior atendida por el mismo proceso (worker) puede usar ese estado obsoleto antes de que la inicialización normal lo restablezca.

«RCE» significa remote code execution, ejecución remota de código: quien aprovecha el fallo puede lanzar sus propios comandos en el servidor con los permisos del servidor web. De ahí el nombre PHP2Shell: una petición web normal se convierte en acceso a la línea de comandos del servidor. El proyecto PHP indica que, en el caso de mod_php, se ha demostrado un exploit en el que una petición sin autenticar puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación. Por eso no basta con tener WordPress, los plugins o la tienda totalmente actualizados: el punto débil está un nivel por debajo, en el propio PHP.

En su aviso previo del 20 de octubre de 2026, el proyecto PHP calificó ambos fallos con una puntuación CVSS v4.0 de 9,2. La escala llega hasta 10; a partir de 9 se considera «crítico».

Según el proyecto PHP, todas las instalaciones de PHP que atienden peticiones web están en riesgo. Se mencionan expresamente:

• Apache con mod_php, donde el proyecto PHP ve el mayor riesgo,
• PHP-FPM (la configuración habitual detrás de nginx o Apache),
• php-cgi, FrankenPHP y LiteSpeed.

¿Qué versiones son seguras?

Importante: las distribuciones de Linux suelen incorporar las correcciones de seguridad en sus propios paquetes sin subir el número de versión a 8.x.y. Según el proyecto PHP, las distribuciones y los proveedores LTS recibieron los parches por adelantado. Un número «antiguo» en un servidor con Debian, Ubuntu, Red Hat o AlmaLinux puede estar protegido igualmente; solo tu proveedor de hosting o tu equipo de IT pueden confirmarlo.

Qué significa para un negocio típico

• WordPress, Joomla, TYPO3, Drupal: funcionan con PHP. Tener el CMS al día no te protege en este caso: lo que cuenta es la versión de PHP del servidor.
• WooCommerce, Shopware, Magento/Adobe Commerce, PrestaShop: también son PHP. Una tienda gestiona datos de clientes y pagos, así que hay que actuar especialmente rápido.
• Hosting compartido: normalmente el proveedor aplica las actualizaciones de PHP de forma centralizada. Pero muchos planes te dejan elegir la versión de PHP: si tienes seleccionada una antigua, como 7.4 u 8.1, seguirás en ella hasta que la cambies.
• Servidor propio o VPS: la responsabilidad es tuya (o de tu agencia): actualizar los paquetes y reiniciar todos los procesos de PHP.
• Creadores de webs sin PHP: los servicios que entregan páginas estáticas o usan otra tecnología no se ven afectados por este fallo concreto. Si tienes dudas, pregunta al proveedor.

Cronología

• Agosto/septiembre de 2026: varios equipos descubren los fallos de forma independiente. Según la PHP Foundation, las primeras pistas llegaron de un desarrollador del núcleo de PHP, y después hubo avisos de Calif y OpenAI (11 de agosto) y de Wiz (24 de agosto). Wiz sitúa su descubrimiento el 19 de agosto.
• 20 de octubre: el proyecto PHP anuncia una actualización de seguridad crítica, prevista para el 21 de octubre a las 14:00 UTC, con una puntuación CVSS v4.0 de 9,2 para ambos fallos. Ese mismo día, según la PHP Foundation, los números CVE circulan con una hora equivocada y una puntuación errónea de 10,0; por la noche se publica por error un vídeo con una prueba de concepto del ataque.
• 21 de octubre, de madrugada: según la PHP Foundation, un proveedor de imágenes de contenedores publica ya a las 07:41 UTC paquetes corregidos, más de seis horas antes de la fecha coordinada.
• 21 de octubre, 14:00 UTC (16:00 en Madrid): se publican PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 junto con los detalles técnicos.

Autoridades y reacciones

Las agencias nacionales de ciberseguridad de toda Europa han emitido alertas: en España INCIBE-CERT, en Alemania el BSI con un aviso de criticidad 3/naranja («deben adoptarse medidas sin demora»), en Austria CERT.at, en Francia CERT-FR, en el Reino Unido el NCSC y en Italia CSIRT Italia. El BSI y el NCSC recomiendan desconectar temporalmente los sistemas si no es posible ni la actualización ni una medida provisional.

Eso es justo lo que han hecho muchas organizaciones. Según derStandard, en Austria se desconectaron por precaución, entre otros, la Universidad de Viena, la TU Wien, el periódico NÖN y Cáritas; según Deutschlandfunk, en Alemania la ciudad de Maguncia retiró varios servicios en línea y su portal web. En Francia, a petición de la ANSSI, el Ministerio del Interior puso en mantenimiento preventivo, entre otras, las webs de las prefecturas (actu17); en los Países Bajos se vieron afectados, entre otros, MijnOverheid y DigiD, según igizmo.it citando a NOS.

¿Se está aprovechando el fallo? Las fuentes no coinciden

• Sí, hay intentos de ataque: Amazon Web Services informa de intentos en sus propios honeypots desde el 17 de octubre y de otros a partir de la madrugada del 21 de octubre. La empresa de seguridad watchTowr comunicó el 21 de octubre intentos de explotación activa de ambos fallos; Datadog habla de un escaneo amplio y no dirigido. INCIBE-CERT señala que se comunicaron ataques antes de que se publicaran las actualizaciones.
• Aún sin confirmar: la PHP Foundation afirma que el equipo de seguridad de PHP no había detectado exploits funcionales en el momento de la publicación. El BSI no pudo verificar los primeros indicios procedentes de redes sociales. A 22 de octubre, ninguna de las dos CVE figura en el catálogo de vulnerabilidades explotadas de la CISA (KEV), la agencia estadounidense.

Nuestra valoración: hay intentos de ataque documentados; por ahora no se han confirmado públicamente intrusiones con éxito a gran escala. Para ti no cambia nada: los detalles son públicos y, por experiencia, los escaneos masivos llegan rápido. Trata cualquier servidor PHP sin parchear como si ya estuviera siendo atacado.

¿Cuántas webs están afectadas?

No hay una cifra exacta. En su análisis, Wiz habla del «70 % de internet» afectado. Según The Hacker News, el 20 de octubre unos 884.000 servidores accesibles desde internet mostraban PHP 8.1 o anterior en su identificación (banner), es decir, versiones sin actualización oficial. Estos recuentos se basan en los banners de los servidores y no indican si un servidor es realmente vulnerable.

No hace falta tener conocimientos técnicos para saber si tu web usa PHP y qué versión tiene. Estas vías suelen llevar pocos minutos:

1. En el escritorio de WordPress: Herramientas → Salud del sitio → Información, apartado Servidor. Ahí aparece la versión de PHP.
2. En Joomla: Sistema → Información del sistema. Ahí figura la versión de PHP.
3. En el panel de control de tu hosting: los planes de hosting compartido suelen tener un apartado como «Configuración de PHP» o «Versión de PHP», donde puedes verla y cambiarla.
4. Por correo a tu proveedor: pregunta literalmente: «¿Qué versión de PHP usa mi web y están instaladas las correcciones para CVE-2026-109618 y CVE-2026-109619?». Pide la respuesta por escrito.
5. Para el personal técnico: php -v en el servidor muestra la versión de la línea de comandos, que puede ser distinta de la que atiende las peticiones web. Lo fiable es la versión que usa realmente el servidor web (por ejemplo, con una página phpinfo creada un momento y borrada justo después). Algunos servidores muestran la versión en la cabecera HTTP X-Powered-By; que no aparezca no significa que no haya PHP.

Regla práctica: 8.5.12, 8.4.27, 8.3.36, 8.2.35 o superior significa que la actualización oficial está instalada. Un número inferior no implica automáticamente que no sea seguro (consulta más arriba lo de los paquetes de las distribuciones); en ese caso, tu proveedor debe confirmar que la corrección está incluida.

1. Contacta con tu proveedor de hosting o tu agencia y pide confirmación por escrito: versión de PHP, corrección de ambas CVE instalada y todos los procesos de PHP reiniciados.
2. Revisa la versión de PHP en tu panel de control y, si la eliges tú, cambia a una rama mantenida (8.3, 8.4 u 8.5). Comprueba un momento que la plantilla y los plugins siguen funcionando.
3. Haz una copia de seguridad y descárgala: archivos y base de datos, con fecha. Una copia guardada en el mismo servidor no basta.
4. Actualiza el CMS, las plantillas y los plugins. Esto no cierra PHP2Shell, pero sí otras puertas que los atacantes están probando ahora mismo.
5. Revisa las cuentas de administrador: ¿hay usuarios que no reconoces? Elimínalos y notifícalo.
6. Cambia las contraseñas una vez instalada la actualización: accesos de administración, FTP/SFTP, base de datos, cuenta de hosting. Activa la verificación en dos pasos siempre que puedas.
7. Haz revisar los registros (ver más abajo), sobre todo si el servidor estuvo accesible entre la publicación del fallo y la actualización.
8. Prueba los formularios de contacto y la tienda cuando todo esté actualizado, para no perder ninguna consulta.

Si has desconectado tu web por precaución, avísalo en tus canales (Perfil de Empresa de Google, redes sociales) con una nota breve sobre cómo pueden contactarte tus clientes mientras tanto.

El proyecto PHP enumera medidas provisionales para servidores que no se pueden actualizar de inmediato, y subraya que solo reducen la exposición a determinadas vías de ataque y no hacen segura una instalación. Son tarea de quien administra el servidor, no de quien es dueño de la web. En resumen:

• Contra CVE-2026-109618: fijar memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (p. ej., con php_admin_value); mantener post_max_size bajo (8M sin subida de archivos, 32M con ella) y upload_max_filesize por debajo; imponer en el servidor web o el proxy límites de tamaño de petición, número de campos, partes multipart, número de cabeceras y profundidad de anidamiento; usar límites de contenedor o de cgroup como red de seguridad. No usar en ningún caso RLIMIT_AS ni RLIMIT_DATA.
• Contra CVE-2026-109619: fijar session.upload_progress.enabled=0 en php.ini o en la configuración del pool y reiniciar todos los procesos (no mediante ini_set() ni .user.ini); en PHP 8.5, fijar además fatal_error_backtraces=0. Corregir los errores fatales y los tiempos de espera agotados que un atacante pueda provocar: ocultar los mensajes de error no sirve de nada.

Tienes todos los detalles técnicos en el aviso de seguridad de php.net.

Una actualización instalada cierra el agujero, pero no elimina lo que se haya colocado antes. Si tu servidor estuvo accesible entre la publicación del fallo y la actualización, haz que lo revisen en busca de rastros. Señales de alarma generales habituales tras el compromiso de un servidor:

• archivos PHP nuevos o modificados en carpetas de subida o de caché que nadie ha creado,
• cuentas de administrador desconocidas en el CMS o usuarios nuevos en el servidor,
• muchas peticiones interrumpidas o errores de memoria en el registro de PHP o del servidor web, sobre todo peticiones POST muy grandes o con una estructura extraña,
• conexiones salientes o tareas programadas nuevas (cron jobs) que nadie ha configurado,
• redirecciones a sitios desconocidos, páginas de spam bajo tu dominio en Google, avisos del navegador.

Rastros específicos de PHP2Shell publicados por empresas de seguridad (para quien revise tus registros): Amazon Web Services señala la cadena PHP_SESSION_UPLOAD_PROGRESS en envíos de formularios POST y recomienda revisar los registros desde el 17 de octubre. Datadog menciona mensajes como «Allowed memory size … exhausted … Unknown on line 0», procesos hijo de Apache que caen con «Segmentation fault» y procesos del servidor web que abren una shell (sh -c). Wiz aconseja vigilar peticiones multipart inusuales seguidas de errores de límite de memoria o respuestas HTTP 500 repetidas.

Si encuentras alguna de estas señales: desconecta la web, recurre a especialistas, cambia las credenciales solo desde un sistema limpio y, si pueden verse afectados datos personales, revisa tu obligación de notificación según el artículo 33 del RGPD (72 horas desde que tengas conocimiento).

Mucha gente nos pregunta por las webs creadas con mekyn. La respuesta es sencilla: las webs que crea y entrega mekyn se sirven como páginas estáticas ya terminadas. En ellas no se ejecuta PHP. La plataforma que hay detrás (panel, formularios, reservas) funciona con Node.js. Por tanto, PHP2Shell no afecta a estas webs.

Es una decisión de diseño, no cuestión de suerte: una página entregada de forma estática no ejecuta lógica de programa en el servidor web con cada visita. Menos piezas en movimiento significa una superficie de ataque más pequeña y, de paso, tiempos de carga más rápidos. Las actualizaciones de la plataforma se aplican de forma centralizada; tú no tienes que hacer nada.

Si tu web actual funciona con PHP y, después de esta semana, estás harto de actualizaciones de servidor, mantenimiento de plugins y correos de emergencia: mekyn toma el contenido de tu web actual y lo convierte en una presencia moderna, con visibilidad en Google, canales de contacto y reservas. Eso sí, hasta que te cambies, sigue la lista de control de arriba: tu web actual tiene que estar segura hoy.