PHP: dos fallos críticos permiten ejecutar código sin contraseña

3 de noviembre de 2026 · Rafael Medina González

INCIBE-CERT ha calificado como crítico (importancia 5) su aviso INCIBE-2026-762 sobre PHP, publicado el 21 de octubre de 2026 y actualizado el 26 de octubre. Dos de los fallos permiten ejecutar código en el servidor sin credenciales, y CISA incluyó ambos en su catálogo de vulnerabilidades explotadas el 26 de octubre. Hay versiones corregidas disponibles.

¿Qué ha pasado?

PHP es el lenguaje con el que funcionan WordPress, PrestaShop, Joomla y muchas webs a medida de pymes. El aviso de INCIBE-CERT recoge tres vulnerabilidades:

CVE-2026-109618: ejecución remota de código por corrupción de memoria cuando el proceso se queda sin memoria. Un vector destacado son las peticiones POST de tipo multipart (las que se usan para subir archivos).
CVE-2026-109619: ejecución remota de código por un estado global obsoleto que puede acabar en un uso de memoria después de liberarla.
CVE-2026-115560: ejecución remota de código, pero solo con una combinación poco habitual de configuración y código. INCIBE indica que su severidad está pendiente de valoración.

Para las dos primeras, PHP da una puntuación CVSS v4.0 de 9,2 y no hacen falta credenciales. Según INCIBE-CERT, se han comunicado ataques contra servidores PHP antes de publicarse las actualizaciones, aunque no se identifica qué vulnerabilidad se usó en cada caso. La columna de explotación de la tabla del aviso indica «No» para los tres identificadores; en cambio, el catálogo de CISA incluye CVE-2026-109618 y CVE-2026-109619 como explotadas.

¿Qué es una ejecución remota de código?

Es un fallo que permite a un atacante hacer que el servidor ejecute órdenes suyas. En el caso de una web, equivale a tomar el control del proceso que la sirve: leer archivos de configuración con contraseñas de la base de datos, modificar la web o usarla como trampolín hacia otros sistemas.

¿Qué instalaciones están en riesgo?

Las que procesan peticiones web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. El riesgo es mayor con Apache mod_php: PHP validó la ejecución remota sin autenticación contra esa configuración para CVE-2026-109618. Para PHP-FPM no hay exploit completo demostrado de ese fallo, pero sí hay rutas confirmadas en mod_php y PHP-FPM para CVE-2026-109619.

flowchart TD
    A["Petición web manipulada"] --> B["Servidor web con PHP"]
    B --> C{"¿PHP corregido?"}
    C -->|Sí| D["Petición tratada con normalidad"]
    C -->|No| E["Posible ejecución de código del atacante"]
    E --> F["Acceso a archivos y base de datos de la web"]

¿Qué versiones están corregidas?

Según INCIBE-CERT:

Rama	Afectada	Corregida
8.2	anterior a 8.2.35	8.2.35
8.3	anterior a 8.3.36	8.3.36
8.4	anterior a 8.4.27	8.4.27
8.5	anterior a 8.5.12	8.5.12

Las ramas 7.4, 8.0 y 8.1 ya no reciben actualizaciones regulares; PHP ha publicado parches retroportados y los distribuidores o proveedores de soporte extendido pueden tener los suyos.

¿Qué debe hacer una pyme?

Averigua qué PHP usa tu web. Pregunta a quien la aloja o la mantiene, o mira el apartado de «Salud del sitio» de WordPress o el panel de tu hosting.
Pide la actualización a una versión corregida de tu rama (o un parche del distribuidor). Si tu proveedor no ofrece corrección, exígesela o plantea migrar a una rama mantenida.
Reinicia los procesos tras actualizar: sin reinicio, el servicio puede seguir ejecutando el código antiguo.
Si no se puede actualizar ya, INCIBE-CERT propone medidas temporales que no sustituyen al parche: limitar el tamaño de las peticiones (post_max_size, upload_max_filesize), bloquear peticiones multipart si la aplicación no las necesita y desactivar session.upload_progress.enabled. Para CVE-2026-109618 el aviso detalla también un ajuste de memory_limit que conviene aplicar con criterio técnico y vigilando el consumo de memoria.
Aísla de Internet cualquier sistema expuesto que no pueda actualizarse hasta que lo esté.
Actualiza también el gestor de contenidos y sus plugins, y revisa que no haya cuentas de administración ni archivos desconocidos.

¿Cómo saber si te ha afectado?

El aviso no publica indicadores de compromiso concretos, así que conviene buscar señales generales:

Archivos nuevos o modificados en la carpeta de la web que nadie reconozca.
Usuarios administradores que no creaste.
Picos anormales de consumo de memoria o CPU del servidor, o muchos errores 500 en los registros.
Avisos de tu proveedor de hosting o del buscador sobre contenido sospechoso.

Si tienes dudas, conserva los registros del servidor antes de tocar nada y consulta con un profesional.

Para terminar

Una web desactualizada es de las puertas de entrada más habituales a una empresa pequeña. Si quieres saber en qué estado está la tuya, puedes pedir una auditoría gratuita.