PHP y sus vulnerabilidades críticas: qué ocurrió y por qué las empresas deben revisar sus sistemas

PHP forma parte de la infraestructura de numerosos sitios y aplicaciones web. Aunque muchas personas nunca ven su nombre al utilizar una plataforma, este lenguaje puede estar detrás de funciones como iniciar sesión, consultar información, enviar formularios o procesar documentos.

Durante octubre de 2026 se divulgaron dos vulnerabilidades críticas en su motor de ejecución: CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Ambas recibieron una puntuación de gravedad de 9,2 sobre 10 en CVSS v4.0 y pueden permitir la ejecución remota de código sin autenticación. [1]

Para comprender el alcance de esta alerta, conviene entender qué hace PHP, dónde se encuentra y por qué una falla en su funcionamiento puede afectar a distintas aplicaciones.

¿Qué es PHP y para qué se utiliza?

PHP es un lenguaje de programación de código abierto, especialmente orientado al desarrollo web. Su nombre corresponde a PHP: Hypertext Preprocessor. Permite construir aplicaciones que procesan información y generan respuestas dinámicas para los usuarios. [2]

En una aplicación web tradicional, el navegador envía una solicitud al servidor. Allí, PHP ejecuta las instrucciones necesarias: puede validar datos, consultar una base de datos, aplicar reglas de negocio y preparar una respuesta.

Por ejemplo, al consultar el estado de una solicitud en un portal, la aplicación puede utilizar PHP para identificar al usuario, buscar sus registros y mostrarle únicamente la información que le corresponde.

Entre sus posibles usos se encuentran:

• Portales de clientes y sistemas internos.
• Plataformas de comercio electrónico.
• Gestores de contenido.
• Formularios y procesos de registro.
• Servicios de integración y API.
• Sistemas de administración y gestión documental.

PHP es el lenguaje; las aplicaciones construidas con él tienen su propio código, componentes y configuración. A su vez, necesitan un entorno de ejecución instalado en un servidor o contenedor.

Esa distinción es fundamental: la seguridad de una aplicación también depende del software que la ejecuta.

¿Qué se encontró en octubre de 2026?

Las dos vulnerabilidades principales afectan al manejo de memoria del motor de PHP. Ambas pueden producir condiciones que permitan a un atacante ejecutar código en un sistema vulnerable.

La expresión “sin autenticación” significa que el atacante no necesita iniciar sesión para alcanzar las vías de ataque descritas. Esto aumenta la importancia de revisar servicios accesibles desde Internet.

CERT-EU señala que el riesgo abarca instalaciones que atienden solicitudes web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. También recoge que, en una explotación demostrada con mod_php, el ataque puede activarse antes de que se ejecute el código de la aplicación. [1]

CVE-2026-109618: corrupción de memoria cuando una operación se interrumpe

PHP dispone de mecanismos para controlar la memoria que consume una solicitud. Si se supera el límite configurado, puede interrumpir el procesamiento.

El problema aparece cuando esa interrupción ocurre mientras PHP todavía está preparando estructuras internas. Durante la limpieza posterior, el motor puede tratar datos incompletos o inválidos como si estuvieran correctamente inicializados.

Este comportamiento puede provocar corrupción de memoria y abrir una vía para ejecutar código malicioso. La vulnerabilidad está identificada en el aviso técnico como RCE via OOM corruption, es decir, ejecución remota de código asociada al manejo de una condición de falta de memoria. [3]

En términos sencillos, el riesgo surge cuando una operación se detiene a mitad de camino y el sistema intenta limpiar sus datos de una forma incorrecta.

CVE-2026-109619: referencias a memoria que ya fue liberada

La segunda vulnerabilidad se relaciona con información interna que puede permanecer después de que la memoria asociada haya sido liberada.

Cuando el mismo proceso atiende otra solicitud, puede utilizar ese estado antiguo antes de restablecerlo correctamente. El resultado es un acceso a información que ya no debería considerarse válida.

El aviso técnico la describe como RCE via stale global state: ejecución remota de código mediante estado global obsoleto. [4]

Una forma de entenderlo es imaginar que un sistema conserva una referencia a un espacio de trabajo que ya fue vaciado y reasignado. Si vuelve a utilizarla sin comprobar su validez, puede terminar procesando información distinta de la esperada.

¿Qué consecuencias puede tener una explotación?

La ejecución remota de código puede permitir acciones con los permisos del proceso afectado. Entre las posibles consecuencias están el acceso indebido a información, la modificación de archivos y la interrupción de servicios.

El alcance real depende de la configuración: los permisos del servicio, los datos accesibles y el aislamiento respecto de otros sistemas influyen en el daño potencial. No implica automáticamente que un atacante obtenga privilegios de administrador sobre toda la infraestructura. [5]

Para una empresa, el análisis debe conectar el problema técnico con su operación. Una interrupción puede afectar la atención de clientes; una modificación de datos puede comprometer procesos internos; y un acceso indebido puede exponer documentos o credenciales.

Tener una versión vulnerable no demuestra, por sí solo, que haya ocurrido una intrusión. La exposición y la existencia de un compromiso son cuestiones que deben evaluarse por separado.

¿Qué versiones corrigen las dos vulnerabilidades principales?

El proyecto PHP publicó las correcciones el 21 de octubre de 2026:

Rama de PHP	Versión que incorpora las correcciones
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Las versiones anteriores dentro de estas ramas requieren revisión y actualización. PHP 8.1 y las ramas más antiguas ya no reciben mantenimiento regular del proyecto. Algunos proveedores ofrecen parches adaptados a versiones anteriores, por lo que debe verificarse la cobertura concreta del paquete instalado. [6]

Una tercera vulnerabilidad requiere una revisión adicional

El 23 de octubre, PHP informó sobre CVE-2026-115560, relacionada con el seguimiento del progreso de carga de archivos y una combinación poco habitual de configuración y código.

Para que se presente, la aplicación debe cambiar durante la ejecución el mecanismo de serialización de sesiones bajo condiciones específicas. PHP recomienda desactivar temporalmente session.upload_progress.enabled hasta la siguiente versión correctiva; el aviso aclara que las aplicaciones que nunca cambian ese mecanismo durante la ejecución pueden mantener la función habilitada.

Esta alerta debe evaluarse por separado: instalar las versiones que corrigen los dos problemas principales no permite dar por resuelta automáticamente esta tercera condición. [6]

Cómo abordar la actualización en una organización

La respuesta requiere identificar dónde se utiliza PHP y quién administra cada instalación. Ese inventario debería incluir aplicaciones propias, servicios contratados y componentes incorporados en productos de terceros.

A partir de allí, conviene organizar el trabajo en cinco acciones:

1. Confirmar la exposición. Registrar la versión, el proveedor del paquete, los parches aplicados y la accesibilidad del servicio.
2. Preparar el cambio. Contar con respaldos y definir pruebas de las funciones relevantes para el negocio.
3. Aplicar la corrección. Actualizar los paquetes o reconstruir y desplegar las imágenes de contenedor correspondientes.
4. Activar y comprobar la nueva versión. Reiniciar los servicios necesarios y verificar el entorno que atiende las solicitudes.
5. Revisar el funcionamiento y los registros. Comprobar accesos, formularios, cargas de archivos e integraciones, e investigar señales anómalas.

Google Cloud advierte que actualizar los archivos en disco puede dejar procesos antiguos ejecutándose en memoria. Por eso, el reinicio o redespliegue es parte de la corrección. [5]

Si existen indicios de intrusión, aplicar el parche debe acompañarse de una investigación: corregir la vulnerabilidad no elimina necesariamente los efectos de un acceso previo.

Si tu sitio funciona sobre WordPress, revisa también cómo afectan estas vulnerabilidades a WordPress y qué pedir al hosting.

La seguridad también se mantiene después del desarrollo

Estas alertas muestran la necesidad de contar con responsables, inventarios y procedimientos de actualización durante toda la vida de una aplicación.

Para los equipos de negocio, una pregunta útil es: “¿Quién puede confirmar qué versión está ejecutando nuestro sistema y qué evidencia tenemos de que fue corregida?”. Esa respuesta permite convertir una alerta general en acciones verificables.

PHP sigue siendo una tecnología utilizada para desarrollar aplicaciones web. Las vulnerabilidades encontradas exigen revisar las instalaciones afectadas, aplicar las correcciones y comprobar su funcionamiento. La continuidad del servicio depende tanto del desarrollo inicial como del mantenimiento de los componentes que lo sostienen.

¿No sabes qué versión de PHP ejecutan tus sistemas?

En Syscode desarrollamos y mantenemos aplicaciones web y la infraestructura cloud que las sostiene. Podemos ayudarte a inventariar tus instalaciones de PHP, aplicar las correcciones y dejar evidencia de que quedaron activas.

Agenda un diagnóstico y revisemos tu exposición.

Fuentes consultadas

1. CERT-EU — Critical Vulnerabilities in PHP
2. PHP — What is PHP and what can it do?
3. PHP — RCE via OOM corruption, CVE-2026-109618
4. PHP — RCE via stale global state, CVE-2026-109619
5. Google Cloud — Responding to core PHP vulnerabilities
6. PHP — Avisos y actualizaciones de octubre de 2026

Artículo actualizado al 26 de octubre de 2026. La imagen de portada es una ilustración generada con IA; la interfaz representada no es una captura real.