PHP2Shell: alerta crítica exige actualizar PHP de inmediato

PHP2Shell es el nombre asignado a dos vulnerabilidades críticas del núcleo de PHP que pueden permitir ejecución remota de código sin autenticación. Las correcciones fueron publicadas el 21 de octubre de 2026 y deben tratarse como una actualización de emergencia en cualquier servidor que procese solicitudes web con PHP.

La alerta no se limita a WordPress ni depende de un plugin vulnerable. El defecto está en el intérprete que ejecuta aplicaciones como WordPress, WooCommerce, Drupal, Joomla, Laravel y sistemas desarrollados a medida. Un sitio con el CMS, los temas y las extensiones actualizados todavía puede quedar expuesto si utiliza una versión vulnerable de PHP.

Qué vulnerabilidades forman PHP2Shell

El proyecto PHP publicó dos avisos con una puntuación de 9.2 sobre 10 en CVSS v4.0. Ambos describen errores de seguridad de memoria capaces de afectar procesos que atienden solicitudes web:

• CVE-2026-109618: un error por agotamiento de memoria puede interrumpir PHP mientras ciertos datos internos apenas se inicializan. La limpieza posterior puede tratar ese estado inválido como legítimo.
• CVE-2026-109619: información interna de una solicitud puede sobrevivir después de que su memoria fue liberada. Una solicitud posterior atendida por el mismo proceso podría usar ese estado obsoleto.

Los mantenedores de PHP documentaron ejecución remota confirmada a través de HTTP contra Apache con mod_php para la primera vulnerabilidad. El impacto se obtiene con los permisos del proceso web, no necesariamente como usuario root, pero esos permisos suelen bastar para leer configuraciones, modificar archivos de la aplicación o acceder a credenciales.

Versiones corregidas oficialmente

Según el aviso oficial del proyecto PHP, las siguientes versiones contienen la corrección publicada el 21 de octubre de 2026:

Las distribuciones Linux y proveedores de soporte prolongado pudieron incorporar la corrección mediante paquetes propios. Un backport adapta el arreglo a una rama anterior sin cambiarla al número de versión nuevo. El equipo de PHP documentó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pero no los convirtió en ramas con mantenimiento ordinario. Tu distribución o proveedor debe confirmar que integró ese código en su paquete exacto. No asumas que existe un backport por conservar una versión antigua.

Qué servidores están expuestos

PHP identifica como potencialmente afectadas todas las instalaciones que atienden solicitudes web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo se considera especialmente alto en mod_php porque existe una demostración en la que el ataque ocurre antes de que comience el código de la aplicación.

Esto significa que una validación implementada dentro de WordPress, Laravel o un desarrollo propio no necesariamente intercepta la solicitud peligrosa. PHP-FPM y otras interfaces también requieren actualización: sus condiciones de explotación pueden ser distintas, pero no deben tratarse como inmunes.

La exposición incluye servidores físicos, máquinas virtuales, hosting compartido, cuentas reseller, imágenes Docker y servicios administrados que empaqueten PHP. Actualizar el sistema anfitrión no cambia automáticamente la versión almacenada dentro de un contenedor.

¿Existe explotación activa?

Al 22 de octubre de 2026, el NCSC de Nueva Zelanda declaró estar al tanto de reportes de explotación activa. Esa formulación no confirma públicamente el número de víctimas, las campañas responsables ni la explotación de cada configuración posible.

La diferencia importa: hay evidencia oficial suficiente para elevar la urgencia, pero no para afirmar que todos los servidores PHP fueron comprometidos. El proyecto PHP y el NCSC recomiendan actualizar de inmediato, inventariar los servicios expuestos e investigar posibles accesos no autorizados. La publicación del parche reduce el riesgo futuro, pero no limpia un sistema que ya hubiese sido comprometido.

Qué podría conseguir un atacante

Una explotación exitosa puede permitir ejecutar instrucciones con los permisos del trabajador PHP. Dependiendo del aislamiento y de la configuración del servidor, el atacante podría leer archivos de configuración, obtener credenciales de bases de datos, extraer secretos presentes en memoria, alterar archivos del sitio o instalar una puerta trasera.

El acceso inicial no equivale automáticamente a control total del sistema operativo. Sin embargo, una cuenta de servicio mal aislada, permisos excesivos, credenciales reutilizadas o acceso lateral a bases de datos y almacenamiento pueden ampliar el impacto. Por eso, actualizar PHP resuelve la vulnerabilidad, pero no elimina un compromiso que ya haya ocurrido.

Acciones prioritarias para hoy

1. Inventaría todos los dominios, aplicaciones, APIs, contenedores y servicios que utilicen PHP.
2. Comprueba la versión del intérprete web de cada sitio; la salida de php -v solo confirma PHP en la consola y puede ser diferente.
3. Instala una versión corregida o el paquete con backport documentado por tu proveedor.
4. Reinicia PHP-FPM, Apache, LiteSpeed o sustituye los contenedores para eliminar procesos antiguos.
5. Verifica desde el entorno web que la versión nueva está realmente activa.
6. Revisa registros, respuestas 500 anómalas, terminaciones de procesos y cambios inesperados en archivos.
7. Si hay indicios de intrusión, conserva evidencia y rota credenciales desde un sistema confiable.

En cPanel, revisa la versión por dominio en MultiPHP Manager o en el selector equivalente. En servidores propios identifica el pool PHP-FPM, el módulo de Apache o el servicio LiteSpeed que atiende cada sitio. En contenedores, comprueba la versión dentro de la imagen desplegada. Después del reinicio, confirma desde el mismo entorno web que ya está activa la compilación corregida; php -v en la consola puede mostrar otra instalación.

Las mitigaciones temporales publicadas por PHP pueden reducir rutas concretas de ataque, pero el propio proyecto advierte que solo la actualización es una solución completa. Si un servicio crítico expuesto a Internet no puede corregirse, restringir su acceso o retirarlo temporalmente puede ser más prudente que mantenerlo disponible sin protección suficiente.

No basta con actualizar WordPress

Actualizar WordPress, WooCommerce, temas y plugins sigue siendo necesario, pero no corrige PHP2Shell. En un hosting administrado debes pedir al proveedor la versión efectiva de PHP y, si usa un número anterior, la referencia exacta del backport aplicado. En un servidor propio, la responsabilidad incluye paquetes, servicios activos, pools FPM, imágenes y procesos residentes.

La prioridad es clara: identifica dónde se ejecuta PHP, aplica la corrección y verifica el resultado. Después investiga si existió acceso no autorizado. En las siguientes notas de esta serie explicaremos el impacto específico sobre sitios web, una guía detallada de respuesta y el funcionamiento técnico de las vulnerabilidades.