Respuesta corta: si tu página usa WordPress 6.8, 6.9 o 7.0, confirma hoy que tenga la actualización más reciente ofrecida por el panel oficial. WordPress publicó el 17 de julio una versión de seguridad para corregir dos problemas graves. Cuatro días después, CISA añadió ambas fallas a su catálogo de vulnerabilidades con evidencia de explotación activa. Esto no prueba que tu sitio haya sido atacado. Sí cambia la prioridad: no basta con que la página cargue, venda o reciba formularios. Debes comprobar versión, respaldo, actualización y accesos administrativos con evidencia.
¿Qué pasó y por qué hoy tiene más urgencia?
WordPress 7.0.2 corrigió una inyección SQL facilitada y otro conflicto en la ruta de solicitudes por lotes que podía combinarse con inyección SQL y terminar en ejecución remota de código. El proyecto calificó una falla como crítica y otra como alta, recomendó actualizar de inmediato y activó actualizaciones forzadas para sitios compatibles con el mecanismo automático. CISA registró CVE-2026-63030 el 21 de julio y fijó el 24 de julio como fecha de corrección para las agencias estadounidenses; registró CVE-2026-60137 el mismo día y fijó el 4 de agosto. Esas fechas no son una ley mexicana, pero muestran que la corrección ya no debe seguir en una lista de pendientes.
La versión correcta es la más reciente de tu rama, no una cifra memorizada
El aviso original corrigió WordPress 7.0 en 7.0.2; también publicó 6.9.5 para las dos fallas y 6.8.6 para la primera. Sin embargo, la API oficial de actualizaciones ya ofrecía el 8 de agosto versiones posteriores: 7.0.3, 6.9.6 y 6.8.7. Por eso no pidas instalar exactamente 7.0.2 si el panel ofrece una versión más nueva y compatible. Pide aplicar la última versión de mantenimiento disponible para la rama soportada. WordPress indicó además que las versiones anteriores a 6.8 no estaban afectadas por estas dos fallas específicas; eso no significa que una versión vieja sea segura ni que deba permanecer sin soporte.
| Pregunta | Respuesta útil | Respuesta insuficiente |
|---|---|---|
| ¿Qué versión corre hoy? | Número visible después de actualizar | Está al día |
| ¿Existe respaldo recuperable? | Fecha y resultado de una restauración de prueba | El hosting hace respaldos |
| ¿Quién tiene acceso? | Lista de administradores y propósito | Sólo la agencia |
| ¿Se revisó algo extraño? | Alcance, periodo y hallazgos documentados | No vimos nada raro |
| ¿Qué pasa si falla la actualización? | Ventana, prueba y forma de regresar | Nunca falla |
¿Cómo confirmas que realmente sea WordPress?
Pregunta al proveedor de hosting o a la agencia qué sistema administra el contenido y solicita el número de versión desde el panel autenticado. No uses detectores públicos como única evidencia: pueden equivocarse o revelar información de más. Si la página es un servicio administrado, pide que el proveedor confirme si aplicó la corrección y cuándo. Si tu equipo administra el servidor, un responsable autorizado debe revisar el panel y la documentación del hosting. No compartas contraseñas por WhatsApp ni envíes capturas con llaves, usuarios completos o rutas internas.
Actualiza en cinco pasos sin convertir la urgencia en una caída
- Registra versión de WordPress, tema, complementos, hosting y persona responsable.
- Genera un respaldo completo de archivos y base de datos, y confirma dónde se guarda fuera del servidor principal.
- Prueba la restauración o al menos verifica el procedimiento antes de cambiar producción.
- Aplica la última versión de mantenimiento compatible desde una fuente oficial y actualiza después temas y complementos aprobados.
- Prueba inicio, formularios, compra, pago, correos, buscador, página móvil y panel; guarda la hora y el resultado.
Si la tienda vende todo el día, acuerda una ventana de bajo tráfico y una forma clara de regresar. No desactives controles de seguridad sólo para terminar rápido. El proveedor debe descargar el software desde WordPress.org o mediante el mecanismo oficial del panel. Después de actualizar, vacía cachés de forma controlada y comprueba desde una conexión externa. Una pantalla de inicio correcta no demuestra que el carrito, la pasarela o el formulario sigan funcionando.
Actualizar cierra la falla; revisar accesos responde si alguien llegó antes
Pide revisar cuentas administrativas nuevas, cambios de correo, restablecimientos de contraseña, complementos instalados sin orden, archivos modificados fuera de la ventana normal y redirecciones inesperadas. Compara contra una lista conocida y contra los registros disponibles del hosting. La ausencia de una señal no garantiza limpieza. Tampoco cada archivo reciente es malicioso: las actualizaciones legítimas cambian muchos archivos. Si hay un hallazgo, conserva registros, limita accesos con ayuda técnica y determina el alcance antes de restaurar. Cambiar contraseñas sin corregir el sitio o borrar evidencia puede complicar el diagnóstico.
Cierra la puerta completa: cuentas, sesiones y llaves también importan
Después de confirmar una actualización limpia, elimina administradores que ya no trabajan con la empresa, usa una cuenta distinta por persona y activa doble factor si la solución elegida lo permite. WordPress recomienda contraseñas fuertes, permisos de archivo restrictivos, actualizaciones continuas y llaves secretas únicas; cambiar las llaves invalida sesiones existentes. Esa operación debe hacerla alguien autorizado porque puede cerrar sesiones de usuarios. También revisa accesos del hosting, registrador de dominio, CDN, base de datos y repositorio. Proteger sólo el panel deja otras entradas abiertas.
