Actualizar WordPress no actualiza PHP. ¿Quién lo corrige?

La semana pasada, sitios de gobierno, ayuntamientos y empresas en toda Europa pasaron a modo de mantenimiento. El motivo fueron dos fallas críticas en PHP, el lenguaje que hace funcionar WordPress y buena parte de la web, corregidas el 21 de octubre de 2026. El propio proyecto PHP las llamó "vulnerabilidades críticas de ejecución remota de código" y pidió a todos los usuarios actualizar de inmediato. El detalle que tomó por sorpresa a la mayoría de las empresas es simple: actualizar WordPress no actualiza PHP. Lo tiene que hacer otra persona, y en muchas organizaciones nadie sabe bien quién.

Puede que tu producto ni siquiera use PHP. Tu sitio corporativo, tu blog, tus landing pages o la agencia que los hizo muy probablemente sí. Ahí es donde esta historia te alcanza.

Qué pasó

Los hechos de las fuentes primarias, sin el ruido:

• La corrección. PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre. Las dos fallas tienen una nota de 9,2 sobre 10 y, según PHP, "pueden permitir ejecución remota de código sin autenticación", es decir, un atacante podría tomar el servidor sin iniciar sesión.
• Quién está expuesto. PHP dice que el riesgo abarca "todas las instalaciones de PHP que atienden solicitudes web", en las formas habituales de ejecutarlo.
• Las versiones antiguas no tienen corrección oficial. En palabras de PHP: "PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP". Algunas distribuciones de Linux y proveedores de soporte extendido publican sus propios parches.
• Qué dijeron las autoridades. El CERT-EU, el equipo de seguridad de las instituciones de la Unión Europea, recomienda actualizar "lo antes posible" y, cuando no se pueda, "aislar los recursos expuestos a internet de las redes públicas hasta que la corrección se aplique y se verifique". Dicho simple: desconectar el sitio.
• Ataques. watchTowr informó de intentos de explotación a partir del 21 de octubre, y el CTO de Cloudflare informó de "los primeros ataques". El 26 de octubre, BleepingComputer informó de la primera explotación exitosa confirmada, registrada en honeypots (servidores señuelo) con PHP 8.4.26, con hallazgos confirmados por el investigador Marcus Hutchins, de Expel. Hasta ese informe, ninguna organización real había sido confirmada públicamente como comprometida.
• Una tercera falla, todavía sin corrección. El 23 de octubre PHP divulgó la CVE-2026-115560, que el propio proyecto llama un "vector improbable de ejecución remota de código" y que requiere una configuración poco común. Se corregirá en la próxima versión regular, aún sin fecha. Hasta entonces, PHP recomienda un cambio de configuración y, sobre las dos fallas principales, repite que "actualizar es la única opción segura".
• No son solo sitios web. PHP también funciona dentro de productos que nadie asocia con PHP. Help Net Security informa que Palo Alto Networks confirmó que sus firewalls PAN-OS y Panorama están afectados, con correcciones hasta el 30 de octubre, y que Cisco incluye Expressway, Duo Access Gateway y un producto de red inalámbrica, uno de ellos con corrección prevista recién para febrero de 2027. Fortinet seguía investigando cuatro productos.

Malwarebytes resumió la consecuencia para el negocio en una frase: "Actualizar WordPress o sus plugins no es lo mismo que actualizar PHP. Puede que el proveedor de hosting o los administradores del servidor tengan que aplicar la corrección".

El mecanismo: tres capas, tres dueños

Un sitio corporativo típico tiene tres capas, y muchas veces cada una tiene un dueño distinto.

1. La aplicación. WordPress, el tema y los plugins. Los actualiza el equipo de marketing o una agencia, muchas veces desde un panel con un botón de "actualizar".
2. El runtime. PHP, el programa que ejecuta WordPress en el servidor. No aparece en el panel de WordPress y no se actualiza cuando se actualiza WordPress.
3. El servidor. La máquina y su sistema operativo, casi siempre a cargo de una empresa de hosting, a veces de un contratista de TI y, de vez en cuando, de nadie en particular.

Estas fallas están en la capa 2. Quienes suelen pulsar "actualizar" están en la capa 1, así que para ellos el sitio parece al día mientras está expuesto. La corrección tiene que venir de la capa 3, y que llegue o no depende de un contrato que nadie lee desde hace tiempo.

Algunos detalles lo vuelven más difícil de lo que parece:

• El número de versión puede engañar. Los hostings que aplican parches retroactivos pueden dejar la versión visible igual. Un sitio puede mostrar "PHP 8.4.26" y estar protegido, o mostrar lo mismo y no estarlo. Hay que preguntar.
• La versión corregida puede estar cerca de su fin. El propio anuncio de PHP recuerda que PHP 8.2 "llega al fin de su vida útil el 31 de diciembre de 2026". Un sitio corregido a 8.2.35 ahora volverá a correr una versión sin soporte en unas diez semanas.
• Las reglas de firewall son un parche temporal. Los proveedores de seguridad publicaron reglas para bloquear patrones de ataque conocidos, y el CTO de Cloudflare advirtió que esas protecciones "son solo un parche temporal".

Por qué es una decisión de negocio, no técnica

Desconectar un sitio es una decisión que sienten marketing, ventas y la dirección, no solo ingeniería. Un día sin sitio cuesta leads y da mala imagen. Un servidor comprometido puede costar mucho más: datos de clientes, una portada desfigurada, malware servido a los visitantes o una puerta de entrada a otros sistemas.

La mayoría de las empresas tomó esa decisión bajo presión la semana pasada, muchas veces sin saber quién podía aplicar la corrección. Es el mismo patrón que vimos cuando cayó una zona de Google Cloud y se llevó bancos enteros: el riesgo no estaba en la parte que alguien vigilaba. Estaba en una dependencia que se delegó y luego se olvidó.

Qué hacer ahora

• Pregunta a tu hosting por escrito si la versión corregida de PHP es la que realmente sirve cada uno de tus sitios. Instalada, no programada. Malwarebytes da el mismo consejo: confirmar que las correcciones estén "instaladas, no solo programadas".
• Haz una lista de todos tus sitios en PHP, incluidos los olvidados: páginas de campañas viejas, el sitio de empleo, el centro de ayuda, el blog que montó una agencia hace años. Cada uno necesita un dueño con nombre para el runtime, no solo para el contenido.
• Sal de PHP 8.1 y anteriores. Ya no reciben correcciones del proyecto PHP. Si no puedes migrar esta semana, paga a un proveedor que publique parches retroactivos, o desconecta el sitio.
• Planifica ya la salida de PHP 8.2. Su fin de vida es el 31 de diciembre de 2026, así que un sitio que solo llegó a 8.2 necesita otra actualización antes de fin de año.
• Decide de antemano quién puede desconectar un sitio y cómo se publica una página de mantenimiento. El peor momento para resolverlo es la mañana en que llega la alerta.
• Pregunta también a tus proveedores de red y seguridad. Los firewalls, gateways de VPN y equipos pueden traer PHP integrado. Pregunta a cada proveedor si sus productos están afectados y cuándo sale la corrección, y sigue de cerca los que aún están "en investigación".
• Sigue la próxima versión de PHP. La tercera falla solo se corregirá en la próxima versión regular. Aplica el cambio de configuración que recomienda PHP hasta entonces y asegúrate de que alguien esté atento a esa versión.
• Pon el runtime en el contrato. Si una agencia o un hosting administra tus sitios, el contrato debe decir quién aplica las actualizaciones de seguridad de PHP y del servidor, y en cuánto tiempo.

Mapear quién es dueño de cada capa, antes de que algo se rompa, es una parte grande de cómo llevamos productos a producción. Es un trabajo sin brillo, y es el que decide si una semana como la pasada te cuesta una tarde o un incidente de seguridad.

Puntos clave

• PHP corrigió dos fallas críticas el 21 de octubre de 2026, en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Sitios en toda Europa se desconectaron mientras se corregían.
• PHP 8.1 y anteriores no tienen corrección oficial, y PHP 8.2 pierde el soporte el 31 de diciembre de 2026.
• Actualizar WordPress o sus plugins no actualiza PHP. Quien aplica la corrección es el hosting o el administrador del servidor.
• La explotación exitosa se confirmó en servidores señuelo el 26 de octubre. Ninguna organización real había sido confirmada públicamente como comprometida.
• Una tercera falla, de menor riesgo, todavía no tiene corrección, y PHP también funciona dentro de firewalls y otros equipos de proveedores como Palo Alto Networks y Cisco.
• Pregunta a tu hosting por escrito, haz el inventario de tus sitios en PHP, nombra un dueño para el runtime y decide de antemano quién puede desconectar un sitio.

Preguntas frecuentes

¿Qué es PHP2Shell? El nombre que recibieron dos vulnerabilidades críticas en PHP, corregidas el 21 de octubre de 2026, que podían permitir a un atacante ejecutar código en un servidor web sin iniciar sesión. PHP les dio una nota de 9,2 sobre 10.

Mi sitio usa WordPress. ¿Estoy afectado? Puede ser. WordPress funciona sobre PHP, así que la corrección depende de la versión de PHP de tu hosting, no de WordPress. Actualizar WordPress o sus plugins no aplica esta corrección. Pide a tu hosting que confirme que el PHP corregido está instalado.

¿Debo desconectar mi sitio? Si tu hosting confirma que la corrección o las protecciones temporales están aplicadas, normalmente no. Si tienes servidor propio y todavía no pudiste corregirlo ni protegerlo, el CERT-EU recomienda aislarlo de internet hasta que la corrección se aplique y se verifique.

¿Si mi sitio estuvo caído la semana pasada, lo hackearon? No necesariamente. Muchos sitios pasaron a mantenimiento por precaución mientras se aplicaban los parches. Como recuerda Malwarebytes, estar caído un tiempo no significa por sí solo que el sitio haya sido comprometido.

No tengo sitios en PHP. ¿Puedo ignorar esto? Todavía no. PHP funciona dentro de algunos firewalls, gateways y otros equipos. Palo Alto Networks y Cisco ya confirmaron productos afectados. Pregunta a tus proveedores si estás expuesto y cuándo sale la corrección.

¿Y si estoy en PHP 8.1 o anterior? El proyecto PHP ya no corrige esas versiones. Migra a una versión con soporte o usa un proveedor que publique parches retroactivos. Si ninguna de las dos es posible pronto, mantener el sitio desconectado es la opción más segura.