PHP2Shell: las vulnerabilidades críticas de PHP y cómo proteger tu web

Qué ha ocurrido con PHP

PHP es un lenguaje que se ejecuta principalmente en el servidor. Cuando una persona visita una página dinámica, el servidor puede utilizar PHP para procesar datos, consultar una base de datos, gestionar una sesión y generar el contenido que recibirá el navegador.

Las vulnerabilidades PHP2Shell afectan al propio entorno que ejecuta ese código. Esto resulta especialmente relevante porque un servidor puede alojar varias aplicaciones que dependen de una misma instalación de PHP. Si el componente compartido es vulnerable, el riesgo no se limita necesariamente a una sola funcionalidad de una web.

Los avisos publicados el 21 de octubre de 2026 describieron dos fallos críticos, con una puntuación CVSS v4.0 de 9,2 sobre 10 según los análisis difundidos. Esa valoración indica un nivel de gravedad muy elevado y justifica que los administradores revisen sus instalaciones con prioridad.

Plataformas como WordPress, Drupal y Joomla pueden ejecutarse sobre PHP, al igual que numerosas tiendas en línea y aplicaciones desarrolladas a medida. Sin embargo, utilizar uno de estos sistemas no implica automáticamente que una web sea vulnerable. La exposición depende de la versión real de PHP, la configuración del servidor, el tipo de integración y las condiciones necesarias para activar el fallo.

Por qué la ejecución remota de código es tan peligrosa

La ejecución remota de código, conocida como RCE por sus siglas en inglés, se produce cuando un atacante puede conseguir que un sistema ejecute instrucciones a través de una interacción remota. En una vulnerabilidad de este tipo, el problema no consiste únicamente en que una página muestre información incorrecta o deje de funcionar.

Si el fallo puede explotarse en un servidor, las acciones disponibles para el atacante dependerán de los permisos del proceso afectado y de las barreras de seguridad que existan alrededor. Entre las consecuencias potenciales se encuentran el acceso a archivos accesibles por el servicio web, la modificación de recursos, el intento de obtener credenciales o la instalación de mecanismos de persistencia.

Estas consecuencias describen riesgos posibles, no una confirmación de que todos los sistemas vulnerables hayan sido atacados. Es importante diferenciar entre la existencia de una vulnerabilidad y la evidencia de explotación real. Aun así, ante un fallo crítico, la prioridad debe ser reducir la exposición y comprobar si existen indicios de actividad anómala.

Los dos fallos de PHP2Shell explicados sin tecnicismos

CVE-2026-109618: un error relacionado con la memoria

El primer fallo está relacionado con la gestión de una situación en la que PHP se queda sin memoria disponible. Cuando un programa llega a ese estado, debe interrumpir determinadas operaciones y liberar los recursos que ya no puede utilizar. Si parte de ese proceso de recuperación no gestiona correctamente el estado interno, pueden producirse errores de memoria.

En software complejo, una corrupción de memoria no siempre se limita a provocar un cierre inesperado. Bajo determinadas condiciones puede alterar cómo se interpretan los datos o cómo se ejecutan las instrucciones. Ese tipo de comportamiento es lo que convierte algunos errores internos en vulnerabilidades de seguridad.

CVE-2026-109619: uso de memoria después de liberarla

La segunda vulnerabilidad se relaciona con un problema conocido como use after free. Se produce cuando un programa intenta utilizar una referencia a una zona de memoria después de que esa memoria haya sido liberada.

En sistemas que procesan muchas peticiones, algunos procesos pueden reutilizarse para atender diferentes solicitudes. Si el estado interno de una petición no se limpia de forma correcta, una operación posterior podría encontrarse con datos que ya no deberían utilizarse. En determinadas condiciones, este comportamiento puede abrir una vía de explotación.

Aunque ambos fallos afectan a la gestión interna de PHP, no son exactamente el mismo problema. Por ello, es necesario instalar las actualizaciones que corrigen las vulnerabilidades y comprobar que los procesos que ejecutan PHP están utilizando realmente la versión actualizada.

Qué versiones de PHP deben revisarse

Los avisos de seguridad identificaron versiones corregidas para varias ramas de PHP que reciben mantenimiento. Antes de actualizar, los administradores deben comprobar las notas oficiales del proyecto y las recomendaciones del proveedor del sistema operativo o del alojamiento.

Las versiones antiguas que ya no reciben mantenimiento del proyecto principal requieren una revisión especial. Algunos proveedores pueden mantener paquetes con correcciones adaptadas, por lo que no debe asumirse que todos los sistemas se actualizan de la misma manera.

También es importante recordar que la versión que aparece en un panel de control no siempre describe todas las instalaciones que existen en una infraestructura. Una empresa puede tener distintos contenedores, máquinas virtuales, entornos de pruebas y aplicaciones heredadas. El inventario debe cubrir todos esos lugares para evitar que una instalación olvidada siga expuesta.

La evolución del incidente: una vulnerabilidad adicional

El 23 de octubre de 2026 se difundió información sobre otra vulnerabilidad relacionada con PHP, identificada como CVE-2026-115560. Este problema adicional presenta condiciones de explotación más específicas y debe revisarse de acuerdo con su propio aviso de seguridad.

Entre las medidas temporales comunicadas para ese caso se encuentra desactivar la función de progreso de subida de archivos en sesiones mediante la directiva session.upload_progress.enabled=0. Antes de aplicar un cambio de configuración, conviene comprobar la recomendación oficial, determinar si la aplicación depende de esa función y probar el ajuste en un entorno controlado.

Una mitigación temporal no equivale a una corrección definitiva. Los responsables de sistemas deben continuar siguiendo los avisos del proyecto PHP y de sus proveedores, ya que las recomendaciones pueden evolucionar cuando se conocen nuevos detalles técnicos.

Qué deben hacer los propietarios de páginas web

Ante una vulnerabilidad crítica, el primer paso es identificar qué sistemas pueden estar afectados. La respuesta debe ser ordenada, documentada y proporcional al riesgo.

Si la actualización inmediata no es posible, debe consultarse la mitigación recomendada por el proveedor y reducirse la exposición del sistema cuando resulte viable. En algunos casos puede ser necesario restringir temporalmente el acceso público o aislar el servicio hasta que se pueda aplicar una solución segura.

Si aparecen señales de intrusión, no basta con instalar el parche y dar el incidente por cerrado. Es necesario conservar evidencias, revisar los registros y valorar si deben rotarse credenciales o restaurarse componentes desde copias de seguridad verificadas. Cuando el impacto pueda ser significativo, conviene recurrir a profesionales de respuesta a incidentes.

Qué pueden aprender los equipos de desarrollo

PHP2Shell demuestra que la seguridad no depende exclusivamente del código que escribe un equipo de desarrollo. También influyen el intérprete, las bibliotecas, el servidor web, las imágenes de contenedor y los servicios externos que forman parte de la aplicación.

Una práctica útil consiste en mantener un inventario de dependencias y definir quién evalúa los avisos de seguridad, quién decide la prioridad y quién valida las actualizaciones antes de desplegarlas. Sin responsables claros, incluso una corrección disponible puede tardar demasiado en llegar a producción.

El principio de mínimos privilegios también ayuda a limitar el impacto. Los procesos web deben tener acceso solo a los archivos y recursos necesarios. Las credenciales deben protegerse, las redes deben segmentarse cuando sea posible y las copias de seguridad deben probarse periódicamente.

Por último, las pruebas automatizadas, la supervisión de registros y los procedimientos de despliegue controlado permiten reaccionar con más rapidez. La seguridad no debería tratarse como una tarea ocasional, sino como una parte permanente del ciclo de vida del software.

Por qué actualizar no siempre basta

Instalar una versión corregida reduce el riesgo de explotación de las vulnerabilidades solucionadas, pero no elimina automáticamente las consecuencias de un ataque que pudiera haber ocurrido antes de la actualización. Si alguien hubiera instalado una puerta trasera, extraído credenciales o modificado archivos, esos efectos podrían continuar después del parche.

Por eso, cuando un sistema estuvo expuesto durante un periodo relevante, conviene evaluar si es necesario revisar los registros, comprobar la integridad de los archivos y rotar credenciales. La profundidad de la revisión dependerá de la exposición, de las señales disponibles y de la importancia de los datos o servicios afectados.

También es importante no confundir la ausencia de alertas con una garantía de seguridad. Una investigación debe apoyarse en evidencias técnicas y en una valoración razonada del riesgo, no únicamente en que la página siga funcionando con normalidad.

Conclusión: la seguridad web empieza por el mantenimiento

Las vulnerabilidades PHP2Shell CVE-2026-109618 y CVE-2026-109619 recuerdan que el software que ejecuta una página web necesita tanta atención como la aplicación visible para el usuario. Una vulnerabilidad crítica en el entorno de ejecución puede afectar a sistemas muy diferentes, por lo que identificar las instalaciones expuestas y aplicar las correcciones correspondientes debe ser una prioridad.

La información adicional sobre CVE-2026-115560 refuerza la importancia de seguir los avisos oficiales y revisar las recomendaciones a medida que evoluciona un incidente. No existe una solución universal para todas las configuraciones: cada entorno debe evaluarse teniendo en cuenta sus versiones, su arquitectura y las instrucciones de su proveedor.

En ClickAplicaciones seguimos de cerca las novedades de desarrollo, software y ciberseguridad para explicar cómo afectan a las páginas web y a los negocios digitales. Mantenerse informado es importante, pero convertir esa información en acciones concretas es lo que ayuda a reducir el riesgo.

Nota editorial: antes de aplicar cambios en producción, consulta siempre los avisos oficiales de PHP y la documentación de tu proveedor. Las versiones corregidas y las medidas recomendadas pueden variar según la rama, la distribución y la configuración.