Vulnerabilidades críticas en PHP: qué hacer

El 21 de octubre de 2026 a las 16:00 (hora peninsular), PHP publica una actualización urgente. Corrige dos vulnerabilidades críticas, las dos con CVSS 9,2. Si tu web usa PHP —WordPress, WooCommerce, PrestaShop o cualquier otra— trátala como expuesta hasta que el servidor esté en una versión corregida.

Esto no se arregla actualizando solo el CMS, un plugin o un módulo. El fallo está en PHP, el lenguaje con el que corre la web. El parche se instala en el servidor.

Cuando PHP publique las versiones corregidas, actualizaremos este artículo. Hasta entonces, el criterio es prepararte para actualizar el mismo día y, si administras el servidor, aplicar ya la mitigación de más abajo.

Fuente oficial: aviso del equipo de seguridad de PHP, previsto para las 14:00 UTC. Los identificadores CVE-2026-109618 y CVE-2026-109619, y la descripción como ejecución remota de código, los han publicado investigadores (Sansec y GoDaddy). PHP todavía no ha publicado el detalle técnico ni la lista de versiones afectadas.

Qué se sabe hasta ahora

El equipo de PHP anuncia dos fallos críticos, ambos con CVSS v4.0 9,2. En esa escala, 9,2 es un fallo grave: se puede intentar desde internet y el daño posible es alto. El detalle, las versiones afectadas y las versiones ya corregidas salen junto con el parche.

Investigadores que han revisado información anterior al aviso describen los dos fallos como ejecución remota de código. En la práctica, alguien podría llegar a tomar el control del servidor sin usuario ni contraseña. También indican que parte de esa información circuló el 20 de octubre. Por eso se esperan intentos de ataque en cuanto el detalle sea público. PHP se reserva adelantar la publicación si el detalle se difunde o si ya hay explotación.

Como la lista oficial de versiones aún no existe, el criterio práctico es este: cualquier web con PHP está en riesgo hasta que actualices el servidor. Entra WordPress, WooCommerce, PrestaShop y el resto de aplicaciones que dependen de PHP.

Qué puedes esperar del parche

Solo recibirán parche oficial las ramas de PHP que aún tienen soporte: PHP 8.2 en adelante. Las versiones antiguas quedan fuera de ese ciclo. No van a aparecer, más tarde, un paquete oficial para ellas.

Versión de PHP	Qué puedes esperar
8.2, 8.3, 8.4 y posteriores con soporte	Parche oficial en cuanto salga el paquete de tu sistema
8.1, 8.0 y 7.x	Sin parche oficial. Hay que migrar a una rama con soporte

Si tu web sigue en 7.x, 8.0 u 8.1, esperar no cierra el fallo. Toca cambiar de versión con copia, prueba y una revisión de tema, módulos o plugins que dependan de PHP antiguo. En una tienda, esa revisión forma parte de la seguridad en PrestaShop, no de un ajuste suelto el mismo día de una campaña.

Qué hemos hecho

En todos los servidores que operamos, propios y de clientes, ya hemos aplicado una mitigación preventiva: desactivar el progreso de subida de ficheros de PHP. Además lo hemos bloqueado para que ningún dominio pueda volver a activarlo por su cuenta.

El efecto visible es pequeño. Puede dejar de verse la barra de progreso al subir un archivo. Las subidas siguen funcionando. Es una medida no oficial: PHP no la ha confirmado como solución y no sustituye al parche. La aplicamos porque el impacto posible es grave y, en el día a día, el cambio se nota poco.

En cuanto salgan las versiones corregidas, actualizaremos PHP en esos servidores. Si tu proyecto está en mantenimiento web con nosotros, no tienes que editar esta configuración.

Si administras tu propio servidor

Puedes aplicar la misma mitigación mientras llega el paquete. No se cambia desde el código de WordPress o PrestaShop, ni con ini_set dentro de la aplicación: PHP lee esta opción al arrancar.

Crea el fichero php.d/99-no-upload-progress.ini dentro de la configuración de la versión de PHP-FPM que usa la web (en muchas distribuciones, un directorio conf.d o php.d de esa versión) con esta línea:

session.upload_progress.enabled = Off

En el pool de PHP-FPM, para que ningún dominio lo reactive:

php_admin_flag[session.upload_progress.enabled] = off

Reinicia PHP-FPM. Comprueba que la web carga y que un formulario con adjunto sigue enviando. Después, actualiza PHP en cuanto el paquete corregido esté disponible. Si no llegas a esos ficheros, pídeselo cuanto antes a quien administra el hosting: hace falta el cambio en el servidor y, enseguida, la versión parcheada.

Qué hacer según tu caso

• Tu web está en un servidor que operamos. La mitigación ya está puesta. Actualizaremos PHP cuando exista el parche. Si echas en falta la barra de progreso al subir un archivo, es el efecto esperado.
• Administras el servidor. Aplica las dos líneas, reinicia PHP-FPM y actualiza en cuanto puedas. Si estás en PHP 8.1 o anterior, planifica la migración: no habrá parche oficial para esa rama.
• El hosting no es tuyo y no lo llevamos nosotros. Escríbele cuanto antes a tu proveedor. Pídele que desactive el progreso de subida ya y que actualice PHP en cuanto publique el paquete. Si la versión es antigua, pídele también el plan de migración.

Cuando el parche esté instalado, haz un pase corto por lo que te genera negocio: entras al administrador, envías un formulario con archivo y, si vendes online, completas un pedido de prueba. Confirma en el panel del hosting que la versión de PHP es una de las corregidas, no solo que WordPress o PrestaShop dicen estar al día.

Si quieres que revisemos la versión de PHP, la copia y el paso a una rama con soporte, cuéntanos tu proyecto.

Preguntas frecuentes

¿Afecta a WordPress, WooCommerce o PrestaShop?

Sí, si el servidor usa PHP. El fallo no está en un plugin o un módulo concreto: está en PHP. Hasta que el servidor tenga una versión corregida, conviene tratar la web como expuesta. Actualizar solo el CMS no basta.

¿PHP 7, 8.0 u 8.1 van a tener parche oficial?

No. El parche oficial llega a las ramas con soporte, PHP 8.2 en adelante. Si tu web sigue en 7.x, 8.0 u 8.1, hay que migrar. No hay un paquete que puedas esperar para esas ramas.

¿Basta con desactivar el progreso de subida?

No. Es una mitigación preventiva y no oficial, para reducir exposición mientras llega el parche. Puede ocultar la barra de progreso al subir archivos. Las subidas normales siguen. En cuanto exista la versión corregida, hay que actualizar PHP.

¿Qué pasa si mi web está en un servidor de Wecomm?

En los servidores que operamos, propios y de clientes, el progreso de subida ya está desactivado y bloqueado para que un dominio no lo reactive. Actualizaremos PHP cuando salgan las versiones corregidas. Si el proyecto no está en esos servidores, cuéntanos tu proyecto y lo vemos.

Comparte este artículo

LinkedInXWhatsAppCopiar enlace