PHP2Shell: dos fallos críticos en PHP y cómo proteger WordPress hoy

Última actualización: 21 de octubre de 2026. PHP ha publicado cuatro versiones de seguridad —8.5.12, 8.4.27, 8.3.36 y 8.2.35— para corregir dos vulnerabilidades críticas de ejecución remota de código (RCE), identificadas como CVE-2026-109618 y CVE-2026-109619. La gravedad oficial es CVSS 9,2 sobre 10. El aviso del proyecto recomienda actualizar de inmediato: no hay una mitigación alternativa que sustituya al parche.

El incidente importa especialmente a quienes administran WordPress, tiendas online, portales públicos o aplicaciones que reciben peticiones web mediante PHP. La Fundación PHP confirmó que el problema de corrupción de memoria se había investigado desde 2024, pero que la falta de un vector de explotación concreto y la dificultad técnica retrasaron la solución. Esa admisión abre una discusión importante sobre los recursos dedicados a mantener software del que depende buena parte de Internet.

La situación de BitZeta: el diagnóstico de nuestro WordPress indica que el servidor ya ejecuta PHP 8.5.12, una de las versiones corregidas. Eso reduce la exposición a estas dos vulnerabilidades concretas, pero no equivale a una auditoría de seguridad completa ni demuestra que todos los componentes estén actualizados. También conviene actualizar WordPress y revisar plugins, copias de seguridad y registros.

Qué ha pasado con PHP2Shell

Los dos fallos afectan a partes internas del motor de PHP, no a un plugin concreto. El primero, CVE-2026-109618, está relacionado con corrupción de memoria durante una situación de falta de memoria (out-of-memory u OOM). En determinadas circunstancias, un error puede dejar datos internos parcialmente inicializados y hacer que el proceso los trate después como válidos. El equipo de investigación confirmó ejecución remota de código en Apache con mod_php, incluso antes de que se ejecute el código de la aplicación.

El segundo, CVE-2026-109619, tiene que ver con estado interno obsoleto: después de un error fatal, un worker puede conservar una referencia a memoria que ya no debería utilizar. Una petición posterior procesada por ese mismo worker puede reutilizarla. Los investigadores confirmaron un caso de uso después de liberar memoria y también demostraron ejecución remota de código en una aplicación real sobre mod_php.

La etiqueta «PHP2Shell» se ha usado en la cobertura pública para describir la emergencia, pero lo importante para administradores es el identificador CVE y la versión instalada. No debe confundirse una prueba de concepto con evidencia de que cada sitio vulnerable haya sido comprometido: la exposición depende del entorno y no existe, por ahora, una cifra verificada que permita afirmar que todas las instalaciones hayan sufrido intrusiones.

Qué versiones hay que instalar

• PHP 8.5: actualizar a 8.5.12.
• PHP 8.4: actualizar a 8.4.27.
• PHP 8.3: actualizar a 8.3.36.
• PHP 8.2: actualizar a 8.2.35.

Las ramas antiguas y fuera de soporte requieren atención especial: no hay que asumir que basta con cambiar una versión en el panel de hosting. Comprueba la política de seguridad del proveedor, la disponibilidad de backports y la compatibilidad de la aplicación. PHP 8.2 tiene previsto finalizar su soporte el 31 de diciembre de 2026, por lo que también es buen momento para preparar una migración a una rama mantenida.

La fuente principal es el archivo oficial de avisos y versiones de PHP. La Fundación PHP explica cómo se descubrieron y corrigieron los fallos, y enlaza los avisos técnicos de CVE. Para empresas que distribuyen imágenes o paquetes, es importante confirmar que el parche se ha incorporado realmente al paquete instalado, no solo que el proveedor lo ha anunciado.

¿Está WordPress afectado?

WordPress se ejecuta sobre PHP, por lo que un servidor con una versión vulnerable puede poner en riesgo al sitio aunque el núcleo de WordPress esté actualizado. La vulnerabilidad está en el intérprete y puede activarse antes de que WordPress o un plugin tengan ocasión de validar la petición. Por eso no basta con instalar un plugin de seguridad ni con cambiar contraseñas: la prioridad es corregir el runtime en el servidor.

Si usas un hosting compartido, normalmente el proveedor controla el paquete de PHP. Abre un ticket y pregunta qué versión exacta está sirviendo las peticiones web, cuándo se aplicó el parche y si todos los nodos, contenedores y procesos PHP-FPM se han reiniciado. En servidores propios, comprueba el SAPI real (por ejemplo, PHP-FPM o mod_php), actualiza desde los repositorios confiables y reinicia los servicios correspondientes. Una versión CLI actualizada no garantiza que el servidor web esté utilizando la misma.

¿Qué daños podría causar una explotación?

Una ejecución remota de código puede permitir que un atacante ejecute instrucciones con los permisos del proceso comprometido. Según los permisos, la segmentación y la configuración, el impacto podría incluir robo de datos accesibles, modificación de páginas, instalación de puertas traseras, extracción de credenciales disponibles en archivos de configuración o interrupción del servicio. No significa que todos esos daños se hayan producido en cada organización afectada: son consecuencias posibles de una RCE y deben investigarse con evidencias.

La respuesta responsable combina parcheo y comprobación. Guarda una copia de seguridad fuera del servidor, registra la hora de actualización, revisa accesos administrativos, cambios recientes en archivos, procesos inusuales y solicitudes sospechosas en los logs. Si encuentras indicios de intrusión, conserva evidencias antes de reinstalar o limpiar el sistema, rota secretos desde un equipo confiable y valora la ayuda de un especialista. Actualizar cierra la vulnerabilidad conocida, pero no elimina automáticamente una puerta trasera que se hubiera instalado antes.

Por qué se retrasó el arreglo y qué se puede aprender

En su comunicado del 21 de octubre, la Fundación PHP reconoce que el equipo ya había detectado indicios del problema OOM durante una auditoría de seguridad de 2024. La solución planteaba compromisos difíciles: romper compatibilidad, introducir riesgos de denegación de servicio o exigir cambios coordinados en extensiones. La organización admite que el proceso de decisión y la falta de recursos especializados provocaron un retraso estructural.

El caso demuestra que encontrar un defecto no equivale a disponer inmediatamente de una corrección segura. Mantener un lenguaje central para millones de aplicaciones requiere financiación, responsables con tiempo para revisar cambios y un procedimiento para escalar decisiones bloqueadas. También muestra el doble filo de las herramientas de análisis asistido por IA: ayudan a descubrir y validar fallos, pero la divulgación de detalles técnicos puede acelerar el trabajo de atacantes. La respuesta adecuada no es dejar de auditar, sino mejorar la coordinación de divulgación, la validación y la distribución de parches.

Lista rápida para administradores y propietarios de webs

1. Confirma la versión usada por el servidor web, no solo la versión de la consola.
2. Instala la versión corregida correspondiente o exige al proveedor una confirmación verificable.
3. Reinicia los procesos PHP afectados y verifica de nuevo la versión.
4. Actualiza WordPress, temas y plugins por separado; el parche de PHP no sustituye esas actualizaciones.
5. Comprueba copias de seguridad, permisos, cuentas de administrador y registros recientes.
6. Si no puedes actualizar de inmediato y el sistema está expuesto, solicita instrucciones específicas a tu proveedor o equipo de seguridad. No apliques ajustes improvisados de memoria: una configuración extrema puede causar problemas de disponibilidad y no sustituye el parche.

En BitZeta seguiremos actualizando esta información cuando haya nuevos avisos técnicos, análisis de explotación o datos confirmados sobre incidentes. Para el contexto más amplio, consulta también nuestra cobertura del incidente relacionado con certificados intermedios de eMudhra.

Fuentes y seguimiento

• PHP.net: versiones y avisos de seguridad de octubre de 2026.
• The PHP Foundation: cronología, correcciones y cambios del proceso de seguridad.
• GitHub Advisory: CVE-2026-109618.
• GitHub Advisory: CVE-2026-109619.

Nota editorial: las versiones y recomendaciones se han contrastado con las publicaciones oficiales disponibles el 21 de octubre de 2026. Las cifras de sitios afectados o incidentes confirmados se actualizarán únicamente cuando existan datos verificables.