Fallo crítico en PHP: cómo saber si tu web está afectada y actualizarla sin romperla

El 20 de octubre, el equipo de seguridad de PHP avisó de que al día siguiente publicaría una versión de seguridad para dos fallos críticos, los dos con una puntuación CVSS v4.0 de 9,2. El 21 de octubre salieron PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que los corrigen. Según el aviso oficial de PHP, ambos pueden permitir la ejecución remota de código sin autenticación.

CVE-2026-109618, «ejecución remota por corrupción en falta de memoria». Cuando PHP se queda sin memoria durante una petición, corta lo que estaba haciendo. Si eso ocurre mientras ciertos datos internos de la petición están a medio preparar, al cerrar la petición PHP puede tratarlos como si fueran válidos. El aviso técnico explica que un atacante puede provocar esa falta de memoria con peticiones de formulario manipuladas (las de tipo «multipart», las mismas que se usan para subir archivos), sin salirse de los límites normales de PHP, y que la ejecución de código está confirmada en Apache con mod_php y los límites por defecto.

CVE-2026-109619, «ejecución remota por estado global obsoleto». Algunos datos internos de una petición pueden sobrevivir después de que se libere la memoria que los respalda. Si la petición siguiente cae en el mismo proceso, puede usar esos datos antes de que se reinicien. Es lo que se conoce como «uso después de liberar» (use-after-free). El aviso técnico confirma dos caminos para provocarlo: las trazas de errores fatales en PHP 8.5 y el progreso de subida de archivos de las sesiones cuando se interrumpe por falta de memoria.

En la práctica, quien explote cualquiera de las dos vulnerabilidades puede ejecutar código con los permisos del usuario con el que corre la web. Eso suele bastar para leer la base de datos, modificar páginas, instalar puertas traseras o usar el servidor para enviar spam. No es un ataque trivial —la complejidad está calificada como alta—, pero un fallo así, con el parche ya público, es de los que se intentan explotar en masa en cuanto alguien publica cómo hacerlo.

Es lo primero que hay que mirar, y se puede hacer en un par de minutos por cualquiera de estas vías:

• En WordPress: Herramientas → Salud del sitio → Información → apartado «Servidor». Aparece la «Versión de PHP».
• En el panel del hosting: en cPanel suele estar en «Seleccionar versión de PHP» o «MultiPHP Manager»; en Plesk, en la configuración de PHP de cada dominio. Ahí ves la versión y, a veces, puedes cambiarla.
• Preguntando al proveedor: pide por escrito qué versión exacta de PHP sirve tu web y si ya incluye el parche de CVE-2026-109618 y CVE-2026-109619.
• En un servidor propio: con una página temporal que llame a phpinfo() (bórrala en cuanto la mires) o revisando el paquete instalado con el gestor de paquetes del sistema.

Cuidado con php -v. Ese comando enseña la versión de PHP de la línea de comandos, que no siempre es la que sirve la web: en un mismo servidor puede haber varias versiones instaladas a la vez. Lo que cuenta es la versión del PHP que atiende las peticiones de tu dominio.

Y otra trampa: en servidores con Debian, Ubuntu o Red Hat, la distribución suele aplicar el parche sin cambiar el número de versión de PHP. Una «8.2.x» de distribución puede estar corregida aunque el número sea menor que 8.2.35. En ese caso hay que mirar el boletín de seguridad de la distribución y la versión exacta del paquete, no solo el número de PHP.

Hosting compartido (el habitual en webs de empresas pequeñas): el proveedor gestiona PHP. Lo normal es que actualice o aplique el parche por su cuenta, pero muchas webs están fijadas en una versión antigua desde el panel porque «así funcionaba». Si tu web está en 7.4 u 8.0 por esa razón, el proveedor no puede subirla sin arriesgarse a romperla, y puede que no lo haga.

VPS o servidor dedicado: aquí actualizas tú (o quien te lleve el servidor). Hay que instalar el paquete corregido de la distribución, o la versión nueva si compilas PHP, y reiniciar los procesos de PHP (PHP-FPM, Apache o el que uses) para que la versión nueva entre en uso. Instalar sin reiniciar deja la versión vieja corriendo.

Hosting gestionado de WordPress o tienda: suelen encargarse ellos. Aun así, conviene pedir confirmación por escrito de la versión y la fecha del parche.

Un aviso concreto de PHP: si tu servidor instala PHP desde el repositorio de voluntarios rpms.remirepo.net, el día del aviso todavía no tenía las versiones nuevas. PHP recomienda pasar a los paquetes de la distribución o compilar desde el código fuente para poder actualizar al momento.

Subir de versión dentro de la misma rama es sencillo. Cambiar de rama es donde se rompen las webs: un plugin que usa funciones que ya no existen, un tema antiguo o un módulo de pago que no aguanta la versión nueva. Este es el orden que seguimos:

1. Copia de seguridad completa de archivos y base de datos, guardada fuera del servidor y comprobada.
2. Inventario: versión de WordPress, PrestaShop o lo que uses, tema, plugins o módulos y sus versiones.
3. Compatibilidad: comprobar que cada pieza soporta la versión de PHP de destino. Lo que no la soporte, se actualiza o se sustituye antes.
4. Prueba en una copia de la web (staging) con la versión nueva, si el hosting lo permite.
5. Cambio de versión en un momento de poco tráfico, y reinicio de los procesos de PHP si el servidor es tuyo.
6. Revisión funcional: páginas principales, formularios de contacto, carrito y pagos, área de clientes, envío de correos y tareas programadas.
7. Registro de errores: revisar el log de PHP las horas siguientes; los avisos de funciones obsoletas avisan de lo que se romperá en el siguiente salto.
8. Plan de vuelta atrás: saber cómo volver a la versión anterior en minutos si algo crítico falla, y tener un plan para no quedarse en ella.

Actualizar PHP cierra la puerta, pero no echa a quien ya hubiera entrado. Si tu web ha estado en una versión vulnerable, conviene mirar si hay señales de que alguien la ha manipulado. Estas son señales generales de una web comprometida, por este fallo o por cualquier otro; ninguna prueba por sí sola que te hayan atacado, pero todas merecen una revisión:

• Archivos .php nuevos o modificados que nadie ha subido, sobre todo en carpetas de imágenes o de subidas (en WordPress, wp-content/uploads).
• Usuarios administradores que no reconoces, o cambios de contraseña que no has pedido.
• Redirecciones a otras webs, sobre todo desde el móvil o cuando se llega desde Google.
• Avisos de Google Search Console sobre «sitio hackeado» o contenido que no es tuyo indexado con tu dominio.
• El proveedor te avisa de un pico de envío de correos, de consumo de CPU o de procesos extraños.
• Tareas programadas (cron) que no reconoces.

Si ves algo de esto, no borres nada a lo loco: los registros del servidor sirven para saber por dónde entraron y qué tocaron. El orden razonable es aislar la web o ponerla en mantenimiento, guardar una copia de cómo está (con sus registros), restaurar una copia de seguridad limpia de antes del problema, actualizar PHP y el resto del software y, después, cambiar todas las contraseñas: las del panel del hosting, la base de datos, el FTP o SFTP y los usuarios de la web. Cambiarlas antes de limpiar no sirve, porque quien esté dentro puede volver a leerlas.

Si en tu web hay datos personales de clientes y ha habido acceso indebido, puede que tengas que notificarlo a la Agencia Española de Protección de Datos en un plazo de 72 horas desde que lo sepas. Consulta con quien te lleve la protección de datos.

CVE

Identificador público de una vulnerabilidad concreta. Sirve para que todo el mundo hable del mismo fallo: CVE-2026-109618 es uno, CVE-2026-109619 es otro.

CVSS

Escala de 0 a 10 que mide la gravedad de una vulnerabilidad. De 9 a 10 se considera crítica. Estos dos fallos tienen 9,2 en la versión 4.0 de la escala.

Ejecución remota de código (RCE)

Que alguien, desde fuera y sin estar delante del servidor, consiga que tu servidor ejecute las órdenes que quiera.

mod_php, PHP-FPM, LiteSpeed

Las distintas formas en que el servidor web arranca PHP para atender a cada visita. De eso depende en parte el riesgo de este fallo.

Parche retroportado (backport)

Arreglo que una distribución de Linux o un proveedor aplica a una versión antigua sin cambiarle el número. Por eso el número de versión no siempre dice si estás protegido.

Rama de PHP

Cada serie de versiones con el mismo número principal: 8.2, 8.3, 8.4, 8.5. Dentro de una rama se actualiza sin grandes cambios; cambiar de rama exige probar.

Staging

Copia de la web en un entorno aparte donde probar cambios sin que los vean los clientes.