El viernes 17 de julio, miles de sitios WordPress en Chile amanecieron con una versión distinta a la que tenían la noche anterior.
Nadie apretó el botón de actualizar. En muchos casos, el dueño del sitio tenía las actualizaciones automáticas desactivadas justamente para que eso no pasara. Igual se actualizó.
No fue una falla. WordPress lo hizo a propósito, y tenía una buena razón. Lo que llama la atención es otra cosa: la mayoría de las personas a las que les pasó se enteró por casualidad, semanas después, mirando el número de versión.
Qué pasó exactamente el 17 de julio
Ese día WordPress publicó una actualización de seguridad de emergencia y liberó tres versiones al mismo tiempo: 7.0.2, 6.9.5 y 6.8.6.
Lo hizo para tapar una falla que en el mundo de la seguridad bautizaron como wp2shell. Y no la tapó y esperó a que cada quien actualizara cuando pudiera: activó la actualización automática forzada para las instalaciones afectadas.
Eso significa que el sitio se actualizó solo, aunque el dueño hubiera dicho que no quería actualizaciones automáticas.
WordPress ha usado ese mecanismo muy pocas veces en su historia. Cuando lo hace, es porque considera que el riesgo de dejar los sitios sin parchar es mayor que el riesgo de romper algo al actualizar.
Qué es wp2shell, explicado sin tecnicismos
wp2shell no es una falla, son dos, y el problema es que se pueden encadenar.
La primera está en una parte de WordPress que recibe varias peticiones juntas para procesarlas de una vez. Un atacante puede confundir a esa parte para que interprete mal lo que le están pidiendo.
La segunda es una inyección SQL: una forma de colar instrucciones dentro de una consulta a la base de datos, en un parámetro que WordPress usa para filtrar contenido por autor.
Por separado, cada una es un problema. Juntas, permiten que alguien escriba un archivo PHP dentro de tu servidor. Y un archivo PHP puesto por un extraño dentro de tu sitio es, en la práctica, una consola de comandos: desde ahí puede leer tu base de datos, crearse un usuario administrador, meter publicidad o redirigir a tus visitas a otro sitio.
De ahí el nombre. De WordPress a shell.
Por qué esta fue distinta a las vulnerabilidades de siempre
Todos los meses aparecen fallas en plugins y temas de WordPress. Casi siempre pasa una de estas tres cosas: afectan a un plugin específico que quizás ni tienes instalado, necesitan que el atacante ya tenga una cuenta en tu sitio, o requieren que alguien haga clic en algo.
Esta no cumple ninguna de las tres.
- Está en el núcleo de WordPress, no en un plugin. No importa qué tema uses ni qué tengas instalado.
- No necesita usuario ni contraseña. El atacante no tiene que estar registrado ni robarle la clave a nadie.
- No necesita que hagas nada. No hay correo falso, no hay clic, no hay descarga. Solo hace falta que tu sitio esté publicado en internet.
- Funciona en una instalación por defecto, sin configuraciones raras.
A los pocos días de publicado el parche ya circulaban públicamente los detalles técnicos completos y código listo para explotarla. El 21 de julio ambas fallas fueron agregadas al catálogo de vulnerabilidades explotadas activamente de CISA, la agencia de ciberseguridad de Estados Unidos, lo que significa que ya se estaban usando contra sitios reales.
Qué versiones estaban afectadas
Esto es lo que conviene tener claro para revisar tu propio sitio:
- WordPress 7.0.0 y 7.0.1: afectados por la cadena completa. Se corrige en 7.0.2.
- WordPress 6.9.0 a 6.9.4: afectados por la cadena completa. Se corrige en 6.9.5.
- WordPress 6.8.0 a 6.8.5: afectados solo por la inyección SQL, no por la cadena completa. Se corrige en 6.8.6.
- Versiones anteriores a la 6.8: si tu sitio está ahí, el problema es más grande que wp2shell y hay que conversarlo aparte.
Si hoy tu sitio muestra 7.0.2, 6.9.5, 6.8.6 o algo más nuevo, estás parchado.
La parte incómoda: ¿te avisó alguien?
Acá viene lo que motivó este artículo.
Esta fue probablemente la falla de seguridad más seria de WordPress en años. Obligó a la organización a tomar una medida excepcional sobre millones de sitios en el mundo, incluidos muchos chilenos.
Y a la mayoría de los dueños de esos sitios no les llegó ni un correo.
No estamos hablando de que el proveedor tuviera que arreglarlo: en la mayoría de los casos el parche llegó solo, por el mecanismo automático de WordPress. Estamos hablando de algo mucho más básico, que es avisar.
Avisar que iba a pasar. Avisar que pasó. Avisar qué revisar después. Porque una actualización forzada del núcleo, aunque sea necesaria, puede dejar efectos: un plugin antiguo que deja de ser compatible, un tema hecho a medida que se comporta distinto, una función que dejó de responder.
Un sitio que se rompe un viernes en la noche y cuyo dueño no sabe siquiera que hubo una actualización, va a pasar el fin de semana entero buscando el problema en el lugar equivocado.
Ese es el punto. La diferencia entre un proveedor y otro casi nunca está en el disco duro ni en el panel de control. Está en si te enteras de las cosas por tu proveedor o por casualidad.
Las cuatro cosas que conviene revisar hoy
Aunque hayan pasado unos días, esto sigue valiendo la pena.
1. En qué versión estás realmente. Entra a tu escritorio de WordPress. Abajo a la derecha, o en Escritorio → Actualizaciones, aparece la versión. Si no llega a las que mencionamos arriba, actualiza ahora, antes de seguir leyendo.
2. Si el sitio quedó funcionando bien. No basta con que cargue la portada. Revisa lo que de verdad usas: el formulario de contacto (envía uno de prueba y confirma que llegue), el carrito y el proceso de compra si vendes, el inicio de sesión, y el sitio en el celular. Los efectos de una actualización suelen aparecer en la parte que nadie mira todos los días.
3. Si hay señales de que entraron antes del parche. Esto es lo más importante y lo que casi nadie hace. La actualización te protege desde ahora, pero no borra lo que haya pasado antes. Revisa la lista de usuarios en Usuarios → Todos los usuarios y confirma que no haya administradores que no reconozcas. Revisa las entradas y páginas por si aparece contenido que no escribiste. Y busca en Google tu propio dominio con site:tudominio.cl para ver si aparecen páginas extrañas indexadas. Si algo no cuadra, tenemos una guía completa de las señales de un WordPress hackeado.
4. De qué fecha son tus backups. Este detalle se pasa por alto y es clave. Si tu único respaldo es del 20 de julio y resulta que entraron a tu sitio el 18, tu respaldo también trae el problema adentro. Lo ideal es tener respaldos que alcancen a fechas anteriores al 17 de julio. Si no sabes con qué frecuencia se están guardando ni por cuánto tiempo se conservan, ese es un tema para resolver esta semana, no el próximo mes. Acá explicamos cómo hacer y verificar respaldos de tu sitio.
Si el sitio quedó con problemas después de actualizar
Pasa, y no significa que hayas hecho algo mal.
Lo primero es no revertir la actualización del núcleo para volver a una versión anterior. Eso te devuelve al punto de partida con la falla abierta, que es peor que el problema que estás tratando de arreglar.
El camino correcto es al revés: actualizar los plugins y el tema para que se pongan al día con el núcleo nuevo. Si uno de ellos lleva años sin actualizarse por su autor, esa es una señal en sí misma y probablemente toque reemplazarlo.
La lección que deja julio
Las actualizaciones automáticas tienen mala fama, y en parte es justificada: a nadie le gusta que le cambien algo sin avisar.
Pero lo que pasó el 17 de julio muestra el otro lado. Entre un sitio que se actualiza solo y puede tener un detalle que arreglar, y un sitio sin parchar con código de ataque público circulando, la elección no es difícil.
Lo que no debería pasar es lo tercero: que te actualicen el sitio, que nadie te avise, y que te enteres cuando algo falla.
Un hosting no es solo el espacio donde vive tu sitio. Es también quién te avisa cuando algo cambia y quién te contesta cuando algo se rompe. Si esta vez no supiste nada por tu proveedor, vale la pena preguntarse qué otras cosas están pasando sin que te enteres.
¿No sabes en qué versión de WordPress está tu sitio, o quieres que alguien lo revise de verdad? Escríbenos por WhatsApp y lo vemos contigo: versión, usuarios administradores, contenido extraño y estado de tus respaldos. En AltaHosting te avisamos cuando pasan estas cosas, no después. Escríbenos en altahosting.cl.
