PHP2Shell: cabeza fría, pero a parchear

Qué pasó

El 21 de octubre de 2026, el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas en el núcleo del lenguaje, conocidas como PHP2Shell: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación de 9.2 en CVSS v4.0 y permiten ejecutar código de forma remota, sin autenticación, con los permisos del usuario que corre el servidor web.

Los detalles se filtraron un día antes de la divulgación prevista, junto con una puntuación de 10.0 que PHP Foundation luego aclaró que era incorrecta. Esa filtración explica parte del ruido: la alarma llegó antes que la explicación.

Dos fallos distintos, no uno

Aunque se habla de «la vulnerabilidad» en singular, son dos fallos con causas diferentes:

CVE-2026-109618, corrupción por falta de memoria (OOM). Si PHP se queda sin memoria justo mientras prepara los datos de una petición, esos datos quedan a medio inicializar y la limpieza posterior los trata como válidos.
CVE-2026-109619, estado global obsoleto. Un worker puede conservar información de una petición después de liberar la memoria que la respaldaba, y la siguiente petición que atiende ese mismo worker la usa. Este fallo se asocia además con filtración de memoria (por ejemplo contraseñas, tokens o claves de otras peticiones).

Un detalle que explica por qué es tan serio: ambos se activan mientras PHP procesa la petición, antes de que se ejecute el código de tu aplicación. Por eso el WordPress, la tienda o el panel que corras encima no cambia la exposición: lo que importa es la versión de PHP.

A quién afecta y a quién no

El riesgo está en los servidores web que ejecutan PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Ahí viven, entre otros, los sitios WordPress, Drupal, Joomla o Magento.

Si no administras ningún servidor, tu PC y tu móvil no necesitan ningún cambio, y no hay nada que borrar ni desinstalar. Lo mismo vale si tienes PHP en tu equipo solo para programar o para la línea de comandos, sin un servidor web expuesto.

Eso sí, «no me afecta a mí» no es lo mismo que «no afecta a nadie». Si un sitio que usas está sin parchear, el atacante apunta a ese servidor, y una de las fallas puede filtrar datos de otras peticiones. Tu dispositivo está bien; lo que podría estar expuesto son tus cuentas en ese sitio.

Si administras servidores: actualiza

La única solución completa es actualizar PHP, y el propio proyecto lo dice en ambos avisos. Estas son las versiones corregidas:

Rama de PHP	Estado	Versión parcheada
8.5	Soporte activo	8.5.12
8.4	Soporte activo	8.4.27
8.3	Solo parches de seguridad	8.3.36
8.2	Solo parches de seguridad	8.2.35
8.1 y anteriores	Fin de vida	Sin parche del proyecto PHP

Si usas 8.1 o anterior, el proyecto PHP no publica corrección. Hay que migrar o pedir backports a tu distribución o proveedor de soporte extendido; AlmaLinux, por ejemplo, ya publicó paquetes parchados para todos sus streams. Verifica además la versión de PHP que realmente atiende tu sitio, que no siempre es la que muestra la consola.

Si no puedes actualizar hoy, hay una mitigación parcial: desactivar la carga de progreso de sesión.

session.upload_progress.enabled = 0

Ponla en php.ini o en la configuración del servidor o del pool (no con ini_set() ni .user.ini, porque debe aplicarse antes de procesar la petición) y reinicia los workers. En PHP 8.5, además, se sugiere fatal_error_backtraces=0.

Qué no hace esa mitigación: bloquea las rutas de sesión confirmadas, pero no otras variantes. Tampoco es remediación cambiar memory_limit. Filtrar en tu WAF o Nginx las peticiones multipart anómalas ayuda a detectar y reducir ataques, pero tampoco sustituye el parche.

Si solo eres usuario: dos hábitos bastan

No tienes que actualizar nada en tus dispositivos por esta alerta. Lo que sí vale la pena, y no solo por PHP2Shell, es protegerte ante el escenario de que un sitio que usas sea comprometido:

Usa contraseñas distintas en cada servicio, para que una filtración no abra otras cuentas.
Activa la verificación en dos pasos donde puedas.

Si administras o conoces a alguien que tiene un sitio propio (una tienda, un blog en WordPress), vale la pena avisarle de que revise su versión de PHP o hable con su proveedor de hosting.

Mi opinión: ni pánico ni minimizar

Cuando leí las noticias me alarmé, como casi todos. Después hice lo que recomiendo siempre: revisar qué decían las fuentes originales, entender a quién afectaba y aplicar en mis servidores las soluciones disponibles. Esa secuencia, leer, entender y actuar, me parece más útil que cualquier reacción de miedo o de indiferencia.

Por eso me quedo con dos ideas.

Primero, la calma tiene que ser informada. Decirle a alguien «no te afecta» es una buena noticia solo cuando se explica por qué: el fallo está en los servidores web, no en tu PC ni en tu móvil. Una calma sin explicación se parece mucho a la indiferencia, y la indiferencia es lo que deja servidores sin parchear durante meses.

Segundo, «cabeza fría» significa actuar con orden, no esperar a ver qué pasa. Aquí la alerta no era exagerada para quien administra servidores: es un fallo crítico, con parches de emergencia y con intentos de explotación ya reportados por algunas firmas de seguridad. Lo que sí sobraba era el catastrofismo de «el fin de Internet». Entre esos dos extremos hay un camino razonable: identificar si te toca, parchear y, si no puedes, mitigar mientras llega el parche, sabiendo que la mitigación es parcial.

Y una lección más general, que aplica a la próxima alerta: antes de compartir o reaccionar, pregunta quién está realmente expuesto, qué dice la fuente original y cuál es la acción concreta. Con esas tres preguntas se filtra casi todo el ruido sin perder lo importante.

Sigamos administrando.

Fuentes

Consultadas el 22 de octubre de 2026:

Tema Relacionado: Infraestructura Linux/VPS