PHP2Shell: qué es la vulnerabilidad crítica de PHP y qué hacer hoy en su empresa

PHP2Shell es el nombre con que se conocen dos vulnerabilidades críticas del propio lenguaje PHP, y su empresa puede estar expuesta aunque nadie haya tocado su código. Esta guía explica qué son, qué versiones están corregidas, qué se sabe hoy de su explotación y qué hacer esta semana, con las fuentes oficiales al lado de cada dato.

¿Qué es PHP2Shell y por qué importa aunque su código sea seguro?

Es un conjunto de dos fallos en el intérprete de PHP que un atacante remoto puede aprovechar, sin credenciales, para ejecutar código en el servidor. Importa porque el fallo no está en su aplicación sino en la capa sobre la que corre.

• CVE-2026-109618: un error de memoria. Cuando una asignación falla, por ejemplo al agotarse memory_limit durante la petición, PHP deja datos inválidos que su rutina de limpieza procesa como si fueran válidos.
• CVE-2026-109619: un uso de memoria ya liberada. Un proceso de PHP reutiliza estado obsoleto de una petición anterior.

CISA resume el alcance así: permiten ejecución remota de código sin autenticación y afectan a todas las instalaciones de PHP que atienden peticiones web. Según Datadog Security Labs, cubre Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. En Apache con mod_php y ajustes por defecto, la ejecución remota quedó demostrada sin autenticación.

Para una empresa mediana, eso significa que WordPress, WooCommerce, Moodle, una intranet o un ERP escrito en PHP comparten el mismo riesgo. Da igual que el plugin esté al día o que la aplicación esté bien programada: lo que hay que mirar es la versión del intérprete que la ejecuta.

¿Qué versiones de PHP están corregidas y cuáles no?

Están corregidas las ramas 8.5, 8.4, 8.3 y 8.2 a partir de las versiones que muestra la tabla, publicadas el 21 de octubre de 2026. Quedan sin versión oficial PHP 8.1 y las anteriores.

Fuente: The PHP Foundation para las versiones corregidas y Datadog Security Labs para el alcance. PHP 8.1 y las ramas anteriores están fuera del soporte regular del proyecto, y según Qualys la mayoría nunca recibirá un parche de proveedor. Datadog Security Labs añade que el proyecto publicó backports de código fuente para 7.4, 8.0 y 8.1, que no son versiones oficiales.

¿Está siendo explotada PHP2Shell?

Hay intentos reportados y escaneo masivo, pero ninguna fuente consultada confirma compromisos exitosos. Las fuentes no coinciden del todo en el matiz, y conviene verlas por fecha.

La lectura prudente es que el riesgo es real y creciente, no que su servidor esté comprometido. Esta página se actualizará si cambia el estado de explotación.

¿Qué hacer hoy? Checklist en cinco pasos

Hoy toca averiguar dónde corre PHP, qué versión usa de verdad y quién es responsable de actualizarla. Estos cinco pasos siguen el orden recomendado por CISA y Datadog Security Labs.

1. Inventarie dónde corre PHP. Sitio web, tienda en línea, plataforma de cursos, intranet, ERP y cualquier software de terceros que lo incluya. Anote para cada uno quién lo aloja y quién lo mantiene.
2. Confirme la versión del servidor web, no solo la de la consola. La versión que muestra el comando php -v es la de la línea de comandos y puede diferir de la que atiende al público. Verifíquela en el panel de su hosting o con quien administra el servidor. Para el procedimiento, vea la guía sobre cómo saber qué versión de PHP usa su sitio y actualizarla.
3. Actualice o exija al proveedor una versión parcheada. Si usa una rama 8.2 a 8.5, suba a la versión corregida. Si el proveedor aplica backports, pídale confirmación por escrito de que incluyen CVE-2026-109618 y CVE-2026-109619.
4. Si no puede hoy, aplique mitigaciones temporales. Se detallan en la siguiente sección. No sustituyen el parche.
5. Revise los registros en busca de las señales que describe Datadog. Están en la tabla de abajo.

Fuente: Datadog Security Labs. Si encuentra alguna, no la borre ni reinicie el servidor antes de conservar una copia de los registros.

¿Qué pasa si no puedo actualizar hoy?

Puede reducir el riesgo con mitigaciones temporales, pero Datadog Security Labs es claro: el parche es la única corrección completa. Si lo que no puede parchear debe seguir en línea, conviene filtrar y aislar.

• Frente a CVE-2026-109618: fijar memory_limit=-1 a nivel de administrador, siempre junto con límites de tamaño de petición en el servidor frontal y límites de memoria del contenedor. No es una solución de largo plazo.
• Frente a CVE-2026-109619: desactivar session.upload_progress.enabled (valor 0) y, en PHP 8.5, fatal_error_backtraces=0. Deben estar en la configuración que se carga antes de procesar la petición, y luego hay que reiniciar todos los procesos de PHP.
• Filtro delante de la aplicación: un cortafuegos de aplicaciones web (WAF) o un proxy inverso puede bloquear peticiones antes de que lleguen al analizador de PHP. CISA lo considera una protección provisional parcial.
• Restringir el acceso público: si una aplicación interna no necesita estar abierta a internet, ciérrela o aíslela de la red.

Las mitigaciones pueden afectar el funcionamiento: quitar el límite de memoria sin topes externos abre otro riesgo. Por eso conviene aplicarlas con alguien que conozca su servidor. Si busca una visión más amplia, el artículo sobre estrategias de ciberseguridad para proteger su negocio ordena las demás capas de defensa.

¿Cuándo conviene pedir ayuda?

Conviene cuando no tiene una persona interna que sepa responder las preguntas del checklist en pocas horas, o cuando lo que corre sobre PHP es crítico para vender u operar. Los casos habituales son estos:

• Una tienda en línea (WooCommerce, PrestaShop o similar): cada hora de caída cuesta ventas, y una actualización mal hecha puede romper plugins de pago o de envío.
• Una plataforma de cursos como Moodle: tiene muchas extensiones y cada una puede depender de una versión concreta de PHP.
• Un ERP o una intranet a medida en PHP: el proveedor original quizá ya no la mantiene y nadie sabe qué versión usa.
• Un hosting compartido o un servidor sin responsable claro: hay que averiguar quién aplica los parches y cuándo.

Mtechnology atiende esta capa con soporte TI, con el mantenimiento web de sitios y tiendas, y con la operación de servidores en hosting y cloud. El primer paso es siempre el mismo: un diagnóstico de 30 minutos, sin costo, que termina con un inventario de versiones y una lista de prioridades. Ningún servicio garantiza que un sistema quede libre de vulnerabilidades, pero sí reduce la ventana de exposición.

La decisión de hoy es saber qué versión corre y quién la actualiza

PHP2Shell no exige reescribir su software, sino saber qué versión de PHP sostiene su operación y quién tiene la responsabilidad de actualizarla. Con ese inventario hecho, el resto es ejecutar: parchear, mitigar mientras tanto o sacar de línea lo que no se pueda proteger.