¿Tu sitio está hecho en WordPress? Actualizarlo no te protege de esto

Si el sitio de tu empresa está hecho en WordPress, corre sobre PHP. Y el 21 de octubre se corrigieron dos fallas críticas en PHP que permiten tomar el control de un servidor sin necesidad de contraseña. Lo incómodo es que actualizar WordPress no las corrige.

Esto no es una recomendación general de buenas prácticas. Es una tarea concreta, con fecha, y se resuelve con un correo de un renglón. Al final está escrito, listo para copiar.

Primero: casi seguro tu sitio usa PHP

PHP es el lenguaje en el que está escrito el programa que arma tu página cada vez que alguien la abre. No es algo que tú instalaste ni que elegiste: vive en el servidor, debajo de todo lo demás.

WordPress está construido en PHP. Es el sistema más usado del mundo para hacer sitios web, así que si tu página la hizo una agencia, un conocido o tú con una plantilla, hay muchas probabilidades de que sea WordPress. Joomla y Drupal también corren sobre PHP. Y buena parte de los sitios hechos a la medida, aunque no todos: algunos usan otros lenguajes.

Si no sabes con qué está hecho tu sitio, ésa es la primera pregunta de la lista de abajo.

Qué pasó exactamente

El 21 de octubre el proyecto PHP publicó versiones nuevas que corrigen dos vulnerabilidades críticas. Tres datos de esas fallas importan:

Lo que no se sabe públicamente es cuántas organizaciones fueron afectadas ni quiénes son. Estar en ese catálogo significa que hay explotación observada, no que exista una lista de víctimas.

Por qué actualizar WordPress no sirve para esto

Imagina que tu sitio es un local en renta. WordPress, la plantilla y los plugins son los muebles, la decoración y la caja registradora: todo eso es tuyo y tú decides cuándo cambiarlo.

PHP es la instalación eléctrica del edificio.

La falla de octubre está en la instalación eléctrica. Puedes cambiar todos los muebles, pintar y poner una caja registradora nueva, y el problema sigue exactamente igual, porque nunca estuvo en tus cosas.

Cloudflare lo dice sin rodeos en su aviso: como las fallas están en el entorno de ejecución de PHP, actualizar el código del sitio o sus complementos no las corrige. Y los investigadores que las encontraron van más lejos: la explotación no depende de una falla en el código de la aplicación, así que hasta un sitio mínimo, sobre una versión afectada, puede ser vulnerable.

Esto tiene una consecuencia práctica que conviene entender bien: quien tiene que actuar casi nunca eres tú. Es quien te da el hospedaje o quien administra el servidor. Tu trabajo es preguntarlo y no soltar la pregunta hasta tener respuesta.

El correo que tienes que mandar

Cópialo tal cual y mándaselo a quien administra tu sitio, sea una agencia, un proveedor de hospedaje o la persona de sistemas.

Asunto: Versión de PHP de nuestro sitio

Buen día. Necesito confirmar tres cosas sobre el servidor donde corre nuestro sitio:

1. ¿Qué versión de PHP está corriendo hoy?

2. ¿Se actualizó después del 21 de octubre de 2026?

3. Si no, ¿cuándo se va a actualizar?

Lo pregunto por las vulnerabilidades críticas de PHP publicadas ese día, que están listadas como de explotación activa. Quedo al pendiente de la respuesta por escrito.

Pedirlo por escrito importa por dos razones: deja constancia de cuándo preguntaste, y evita que la respuesta se quede en un «sí, ya está todo bien» de pasillo.

Cómo leer la respuesta

Si te dicen PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o algo más nuevo: está corregido. Es la respuesta que buscas.

Si te dan una versión 8.2, 8.3, 8.4 u 8.5 más vieja que ésas: falta actualizar, y es la tarea de esta semana.

Si te dicen PHP 8.1, 8.0, 7.4 o cualquier cosa que empiece con 7: el problema es más grande que un parche. Esas versiones ya no reciben actualizaciones del proyecto PHP. No es que falte aplicar una corrección: es que ya no las van a hacer. Ahí la conversación deja de ser sobre esta falla y pasa a ser sobre cuándo se mueve el sitio a una versión con soporte.

Si te dicen PHP 8.2 y ya está actualizado: bien por ahora, pero anótalo en tu calendario. PHP 8.2 deja de recibir soporte el 31 de diciembre de 2026.

Si nadie sabe contestarte: ésa también es una respuesta, y es la más importante de todas. Significa que nadie está viendo el motor sobre el que corre tu negocio. El problema deja de ser esta vulnerabilidad y pasa a ser quién responde por tu sitio.

Lo que no te toca a ti

Para que no te vendan de más: tú no tienes que entender la vulnerabilidad, ni instalar nada, ni contratar una auditoría por esto. No necesitas saber qué significa "ejecución remota de código".

Lo único que te toca es preguntar, entender la respuesta con la guía de arriba, y darle seguimiento si la respuesta no es la buena.

Si quieres el contexto completo de lo que pasó en octubre y por qué muchas cifras que circularon no eran lo que parecían, lo contamos aquí: «Octubre negro»: fuimos a los informes originales y casi ningún número coincide.

Y si al preguntar descubres que hacía mucho que nadie tocaba tu sitio, vale la pena leer por qué eso es la puerta más común: Actualizar tu sitio es la tarea más aburrida de la lista.

Una cosa más, mientras tienes al proveedor del otro lado

Ya que vas a escribirle, aprovecha y pregunta una segunda cosa que no cuesta nada y que casi nadie revisa: si el dominio de tu empresa tiene DMARC en reject.

Es lo que decide si alguien puede mandar correos haciéndose pasar por tu negocio. Lo medimos en dos países y el resultado fue parecido: en México, el 88.5% de los hoteles independientes está expuesto; en El Salvador, el 90.7% de las empresas turísticas. Son tres renglones de texto en el DNS y no cuestan dinero.

Dos preguntas en el mismo correo, y las dos se contestan en un rato.