Fallo crítico de PHP de octubre de 2026: ¿mi web está afectada?

1. ¿Tu web usa PHP?

• Sí, casi seguro: WordPress instalado en un hosting, WooCommerce, PrestaShop, Joomla, Drupal, Magento, OpenCart, o una web a medida en Laravel o Symfony.
• No es cosa tuya: Shopify, Wix, Squarespace y WordPress.com. Los servidores son de la plataforma, y es ella quien los actualiza.
• Normalmente no: webs hechas con Lovable, Bolt o v0 y publicadas en Vercel o Netlify.

Cuenta también lo que está al lado de la tienda: un blog en WordPress en un subdominio (por ejemplo blog.miempresa.es) o una web antigua que nadie apagó. Si no sabes cómo está hecha tu web, pregúntaselo a quien la hizo.

2. ¿Qué versión de PHP tienes?

Míralo en el panel. Estos son los sitios más habituales:

• WordPress: Herramientas › Salud del sitio › Información › Servidor (Tools › Site Health › Info › Server), en la línea de la versión de PHP.
• cPanel: Software › MultiPHP Manager, junto al dominio. En algunos hostings se llama «Select PHP Version».
• Plesk: en el dominio, la sección PHP (PHP Settings).
• Hostinger (hPanel): Sitios web › Administrar › Configuración de PHP, en la barra lateral (Websites › Dashboard › PHP Configuration).

Estás protegido si tu versión es igual o más reciente que la corregida de la misma rama:

• PHP 8.5: 8.5.12 o más reciente
• PHP 8.4: 8.4.27 o más reciente
• PHP 8.3: 8.3.36 o más reciente
• PHP 8.2: 8.2.35 o más reciente

Un número más bajo no siempre significa que falte la corrección. Las distribuciones Linux (Debian, Ubuntu, Red Hat y otras) recibieron las correcciones antes del día 21, y muchas las aplican sin cambiar el número de versión. Por eso la pregunta correcta a tu hosting no es «¿qué versión tenéis?», sino «¿vuestro PHP ya tiene las correcciones del 21 de octubre?».

PHP 8.1 o anterior: el proyecto PHP ya no lo actualiza. Algunos proveedores publican correcciones propias para versiones antiguas; si el tuyo no lo hace, la salida es pasar a una versión con soporte. Y la 8.2 deja de recibir correcciones el 31 de diciembre de 2026: si estás en ella, actualiza ahora y planifica el paso a la 8.3 o más reciente.

3. Actualizar: quién hace qué

• Hosting compartido (la mayoría de las webs WordPress de pequeños negocios): el PHP es del hosting. Tú eliges la versión en el panel, pero quien instala las correcciones son ellos.
• Servidor propio o VPS: actualiza PHP con el gestor de paquetes de tu distribución, o a una de las versiones de arriba, y comprueba que PHP y el servidor web se han reiniciado. Hasta entonces puede seguir funcionando la versión antigua.
• Alguien gestiona la web por ti (una agencia, un freelance): envíales esta página y pídeles la confirmación por escrito.

Para el hosting, basta con un mensaje así: «Hola. Mi web, miempresa.es, usa PHP. El 21 de octubre el proyecto PHP corrigió dos fallos críticos (CVE-2026-109618 y CVE-2026-109619) en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. ¿Podéis confirmar si el PHP de mi hosting ya tiene estas correcciones, o cuándo las vais a instalar?»

Cuidado al cambiar de versión. Dentro de la misma rama (por ejemplo de 8.3.30 a 8.3.36) el riesgo de romper algo es mínimo. Saltar de rama (de 7.4 u 8.1 a 8.3) puede dejar plugins y temas antiguos sin funcionar: haz una copia de seguridad antes y revisa la web justo después.

4. Si no puedes actualizar ya

El proyecto PHP publicó medidas temporales, pero dice que reducen la exposición y no hacen seguro el servidor. Son para quien gestiona el servidor: en un hosting compartido, quien las aplica es el hosting.

Un plugin de seguridad no basta: en el caso más grave (Apache con mod_php), el ataque demostrado ocurre antes de que empiece a ejecutarse cualquier código de la web, así que el plugin ni siquiera llega a verlo. Ocultar la versión de PHP tampoco protege: el ataque no necesita saberla.

5. Después de actualizar: ¿entró alguien antes?

La actualización cierra la puerta, pero no dice si alguien entró antes de que se cerrara. Si tu web siguió con una versión antigua después del 21 de octubre, haz esto:

1. En WordPress, en Usuarios (Users), busca administradores que no conozcas.
2. Pide a tu hosting un análisis de malware de tu cuenta, y pasa también el de un plugin de seguridad.
3. Cambia las contraseñas de todos los accesos: el panel del hosting, el FTP o SFTP, la base de datos y los administradores de la web. En WordPress, cambia también las claves secretas de wp-config.php: así se cierran las sesiones de quien siga dentro.
4. Cambia las claves guardadas en la web: las del pago (Stripe, PayPal), la contraseña del correo que usa la web para enviar y las claves de servicios de inteligencia artificial que usan los plugins. Quien controla el servidor puede leerlas, y una clave de IA robada se gasta en tu cuenta.

Si encuentras señales de ataque y la web tiene datos de clientes, el RGPD obliga a notificarlo a la AEPD en 72 horas, salvo que sea improbable que haya riesgo para las personas. Pide ayuda a tu hosting o a un profesional antes de limpiar: una limpieza mal hecha deja puertas abiertas.

Lo que Excubitor ve, y lo que no

La comprobación gratuita solo lee lo que es público y no te dice la versión de PHP: esa la ves en el panel, o se la preguntas a tu hosting. Lo que te dice es lo que se ve desde fuera: si el certificado es válido, si alguien puede enviar correos haciéndose pasar por tu dominio, y qué falta en las cabeceras de seguridad de la web, con la prueba de cada punto.

Un consejo de la propia documentación de WordPress: una web tomada se usa a menudo para enviar spam, y si el correo del negocio sale del mismo servidor, las listas negras atrapan a los dos. Tener el correo en un proveedor propio (Google Workspace, Microsoft 365) los separa.

Para no tener que volver a comprobarlo

PHP no lo vigilamos, pero el resto del dominio sí: Excubitor puede comprobar tu dominio cada semana (el certificado, los registros de correo, las cabeceras) y escribirte solo cuando algo cambia. Gratis para 1 dominio: haz la comprobación y pulsa «Avísame».

SPF, DKIM y DMARC paso a paso (los valores sirven para cualquier dominio)