Fallo crítico de PHP: actualizar y luego pensar en estático

El 21 de octubre de 2026, el equipo de PHP publicó una actualización de seguridad que corrige dos fallos críticos. En las redes sociales se leyó que «80% of the internet» estaba amenazado y que los atacantes lo habrían entendido todo «in 15 minutes». La realidad es algo menos espectacular, pero sigue siendo seria. Esto es lo que es cierto, lo que hay que hacer hoy y la pregunta que esta alerta plantea a todos los que tienen un sitio WordPress o PrestaShop.

Qué se ha corregido

Los dos fallos llevan los números CVE-2026-109618 y CVE-2026-109619. El equipo de PHP los califica con 9,2 sobre 10 en su anuncio en php.net. En ambos casos, un visitante que no ha iniciado sesión puede hacer que el servidor ejecute su propio código. El primero procede de una mala gestión de la memoria cuando esta escasea. El segundo procede de datos de una solicitud que permanecen en memoria y que reutiliza la solicitud siguiente.

Todas las instalaciones que sirven páginas web están afectadas, sea cual sea el modo: PHP-FPM, Apache con mod_php, LiteSpeed, FrankenPHP. Según php.net, el caso más expuesto es mod_php, en el que se demostró un ataque incluso antes de que se ejecute el código del sitio.

La cifra de «80% of the internet» está redondeada al alza. PHP hace funcionar la gran mayoría de los sitios cuya tecnología se conoce, lo que incluye casi todos los WordPress, PrestaShop, Drupal y Joomla. La amenaza es, por tanto, amplia, pero no universal.

Qué hacer hoy

Actualice PHP. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si su proveedor de alojamiento gestiona PHP por usted, compruebe que lo ha hecho o pídaselo por escrito.

Si su sitio funciona todavía con PHP 8.1 o una versión anterior, el proyecto PHP ya no publica versiones para esas ramas. Su equipo solo ha difundido parches en bruto que su proveedor de alojamiento debe aplicar él mismo. Es la señal de que una actualización de versión ya no puede esperar.

Mientras llega la actualización, php.net propone ajustes que reducen el riesgo, como desactivar el seguimiento del progreso de la subida de archivos. El propio equipo de PHP lo dice: estos ajustes no hacen seguro un servidor, solo la actualización lo consigue.

Por qué la IA acorta el plazo

Una actualización de seguridad muestra exactamente qué líneas han cambiado. Los atacantes comparan la versión antigua y la nueva para encontrar el fallo y después escriben un ataque. Este trabajo llevaba días. Con los asistentes de código actuales, puede llevar unas horas. Los «15 minutes» del tuit son una predicción, no un hecho constatado, pero la tendencia es real: la ventana entre la publicación de un parche y los primeros ataques se estrecha.

Para una empresa, esto cambia las reglas del juego. Actualizar «durante la semana» ya no basta para un fallo de este nivel. Hay que actualizar en el día y, por tanto, tener a alguien que vigile, pruebe y despliegue, también el fin de semana.

La verdadera ventaja de un sitio estático

Un sitio estático se construye una vez, de antemano. Lo que recibe el visitante son archivos ya preparados: HTML, imágenes, algo de JavaScript. No se ejecuta PHP en el momento de la visita y no se consulta ninguna base de datos. Un fallo como este, sencillamente, no tiene nada que atacar.

Es la ventaja más subestimada de lo estático. Se habla sobre todo de la velocidad, pero también reduce la dependencia de una tecnología concreta. Su sitio ya no depende de la versión de PHP, de la de WordPress ni de las treinta extensiones que deben estar todas al día a la vez. Hay menos piezas, y por tanto menos urgencias como la de hoy.

Lo que lo estático no resuelve

Seamos honestos: lo estático no elimina todo el trabajo de seguridad.

• Los formularios siguen necesitando un pequeño servicio que reciba los envíos. Debe protegerse, pero es minúsculo comparado con un WordPress entero.
• El back-office sigue existiendo si utiliza una herramienta de edición como un CMS headless. Vive aparte, en un proveedor que lo mantiene, y no en el servidor de su sitio público.
• Las API de pago, de reserva o de catálogo siguen siendo software que hay que actualizar.
• Una tienda en línea completa, con carrito y cuentas de cliente, no se vuelve estática de golpe. Las páginas de producto y el contenido pueden serlo; el pago pasa por un servicio especializado.

La diferencia es que la superficie expuesta pasa a ser pequeña y bien delimitada. En lugar de vigilar todo un servidor, vigila dos o tres piezas concretas.

El momento de plantearse la pregunta

Si esta alerta le ha hecho comprobar con urgencia su versión de PHP, hágase una pregunta sencilla: ¿necesita realmente su sitio ejecutar código en cada visita? Para un sitio corporativo, un blog o un catálogo, la respuesta es casi siempre no.

Empiece por actualizar hoy. Después, si quiere salir de este ciclo de alertas, nuestra migración a un sitio estático conserva todas sus direcciones y su posicionamiento, y pone el sitio en línea en un alojamiento que no ejecuta PHP. Para entender qué ocurre cuando la actualización llega demasiado tarde, lea también qué hacer cuando un sitio WordPress ha sido pirateado.