PHP2Shell: dos fallos críticos de PHP ya se explotan; qué hacer hoy si tu sitio corre PHP

Si tu sitio, tu tienda en línea o tu blog corren en WordPress, Laravel, Magento o un sistema a la medida, casi seguro corren en PHP. El 21 de octubre el proyecto PHP publicó una actualización de emergencia para dos fallos críticos, conocidos como PHP2Shell, que permiten a alguien sin usuario ni contraseña ejecutar código en el servidor. CISA ya los considera explotados, y en México el gobierno bajó temporalmente algunos portales por la alerta. Aquí va lo confirmado, lo que no sabemos y qué hacer hoy.

Qué dicen las fuentes

• Los fallos. Son el CVE-2026-109618 y el CVE-2026-109619. Según el aviso de PHP, ambos pueden permitir ejecución remota de código sin autenticación. Uno nace cuando PHP se queda sin memoria en un momento preciso; el otro, cuando datos internos de una petición sobreviven a la memoria que los respaldaba. Ambos tienen calificación 9.2 en la escala CVSS.
• A quién afectan. A toda instalación de PHP que atienda peticiones web: Apache con mod_php, PHP-FPM, php-cgi, LiteSpeed y FrankenPHP. PHP considera el riesgo más alto en mod_php, donde la petición puede disparar el ataque antes de que corra el código de tu aplicación.
• La corrección. Las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto; algunas distribuciones y proveedores de soporte extendido ofrecen correcciones propias.
• La explotación. CISA agregó ambos fallos a su catálogo de vulnerabilidades explotadas el 26 de octubre. El laboratorio de inteligencia de amenazas de la Universidad de Delft publica en vivo lo que captan sus sensores: al 30 de octubre, 76,341 peticiones de explotación desde 681 direcciones IP en 73 países, y 177 de esas direcciones enviaron código o programas descargadores. Son peticiones contra trampas de investigación, no sitios comprometidos.
• México. Según Xataka México, el 28 de octubre la presidenta Claudia Sheinbaum confirmó que el gobierno dio de baja de forma temporal algunos sitios oficiales por la alerta de PHP, y que se restablecieron poco después.

«Solo una actualización es una solución completa; las medidas siguientes reducen la exposición a vías de ataque específicas, pero no hacen segura una instalación.» Aviso de seguridad de PHP, 21 de octubre de 2026 (traducción nuestra).

Lo que no está confirmado

CISA no ha revelado qué organizaciones fueron comprometidas ni cuántos sistemas en producción cayeron, según The Register. Algunos reportes tempranos se corrigieron: Sophos ajustó su evaluación inicial y Palo Alto Networks retiró un vínculo con una intrusión en una agencia europea. Hay ejecución real de comandos documentada en servidores de prueba, pero no un número confiable de sitios de pymes afectados, y tampoco sabemos cuántos sitios mexicanos siguen sin corregir.

La perspectiva de Bit Farm para una pyme en México

Lo siguiente es criterio nuestro, no un requisito oficial. Un fallo que permite ejecutar código sin credenciales no distingue entre un portal de gobierno y una tienda de ropa: los ataques automatizados buscan servidores, no marcas. Y la mayoría de las pymes no actualiza PHP por sí misma, porque su sitio vive en un hosting administrado por un tercero. La pregunta útil no es "¿qué es mod_php?", sino "¿quién actualiza mi servidor y cuándo lo hizo?".

Cinco pasos para hoy (criterio Bit Farm)

• Haz un inventario. Anota cada sitio, tienda, portal de clientes o sistema interno que tengas en línea y quién lo aloja. CISA advierte que PHP suele ir dentro de otros programas, así que no siempre es evidente dónde corre.
• Averigua la versión exacta de PHP. En WordPress aparece en Herramientas, Salud del sitio, pestaña Información, sección Servidor. En otros sistemas, pregunta a quien lo administra. Algunos paneles de hosting muestran solo la rama, por ejemplo 8.3, y no el parche, por ejemplo 8.3.36: pide el número completo.
• Compáralo con las versiones corregidas. 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o una versión de tu distribución o proveedor que declare la corrección. Si la tuya es anterior o ya no tiene soporte del proyecto, pasa al paso siguiente con más urgencia.
• Escríbele a tu proveedor de hosting. Tres preguntas: si ya aplicó la corrección de PHP, en qué fecha y si reinició los procesos de PHP después, porque la actualización no surte efecto hasta entonces. Pide la respuesta por escrito. Si no se puede actualizar ya, CISA recomienda sacar de línea los sistemas PHP hasta hacerlo; para un sitio solo informativo, una página provisional por unas horas puede costar menos que un incidente.
• Respalda fuera y revisa señales. Guarda una copia reciente fuera de tu hosting y comprueba que se pueda restaurar; lo planteamos en nuestro post sobre qué hacer si tu proveedor falla. Revisa cambios inesperados en archivos, tareas programadas que no reconoces y consumo anormal.

Dedicarle una tarde a esto cuesta mucho menos que reconstruir un sitio comprometido.

Cómo podemos ayudar

Bit Farm es una consultoría tecnológica mexicana: hacemos sitios, sistemas a la medida y hosting para pymes. Podemos ayudarte a hacer el inventario de lo que tienes en línea, confirmar versiones de PHP, preparar las preguntas para tu proveedor y diseñar respaldos que sobrevivan a un incidente. Este artículo no sustituye una revisión técnica de tu servidor.

Fuentes: PHP.net, aviso de seguridad (21 oct 2026); CISA, alerta actualizada el 26 oct; CISA, catálogo de vulnerabilidades explotadas; watchTowr; Delft Threat Intelligence Lab; The Register; Xataka México.