Seguridad WordPress 7.0.2: lo que tenés que saber

Actualizado el 27/07/2026: WordPress lanzó el parche de seguridad crítico 7.0.2 para corregir una vulnerabilidad de ejecución remota de código (RCE) sin autenticación y una inyección SQL que afectaban a millones de sitios. La actualización se aplicó de forma forzosa en instalaciones vulnerables y ya está disponible para todas las ramas soportadas.

El 17 de julio de 2026, WordPress activó las alarmas con la versión 7.0.2, un parche de seguridad wordpress 7.0.2 que corrige dos vulnerabilidades graves: una inyección SQL sencilla y un fallo crítico de ejecución remota de código (RCE) en la REST API. El equipo forzó la actualización para todos los sitios afectados, y Matt Mullenweg calificó el RCE como uno de los más serios en los 23 años de historia del CMS.

La seguridad wordpress 7.0.2 es una actualización de emergencia publicada por WordPress.org que resuelve una vulnerabilidad crítica de ejecución remota de código (RCE) vía REST API y una inyección SQL de alta gravedad. Afecta a las versiones 6.9, 6.8 y la beta de 7.1, y ya están disponibles los parches 7.0.2, 6.9.5, 6.8.6 y 7.1 beta2 para cada rama.

¿Qué versiones de WordPress están afectadas por esta vulnerabilidad?

Las ramas 6.9 y 6.8 son las principales afectadas. La versión 6.9 está expuesta a ambas vulnerabilidades —la inyección SQL y el RCE—, mientras que la 6.8 solo sufre la inyección SQL. La beta de 7.1 también estaba comprometida por los dos fallos hasta la salida de la beta2.

Si tu instalación está en 6.7 o menos, zafaste de esta. El tema es que si no actualizaste desde hace tiempo, probablemente tengas otros agujeros que ya están documentados y son conocidos por cualquiera que sepa usar un buscador de exploits. Ojo con la falsa sensación de seguridad. En configuración de Sucuri para WordPress profundizamos sobre esto.

¿Qué tipos de vulnerabilidades se corrigieron en WordPress 7.0.2?

Dos. Una es heavy, la otra es crítica y fue la que encendió todas las alarmas. La primera es una inyección SQL sencilla reportada por el equipo compuesto por TF1T, dtro y haongo. Este tipo de fallo permite que un atacante manipule consultas a la base de datos y extraiga información sensible o modifique contenido sin autorización.

La segunda vulnerabilidad, reportada por Adam Kues de Assetnote / Searchlight Cyber, es una confusión en el enrutamiento por lotes de la REST API combinada con inyección SQL que deriva en ejecución remota de código (RCE). En cristiano: alguien sin autenticarse podía ejecutar comandos arbitrarios en tu servidor. Mullenweg lo puso en perspectiva en su blog personal: este tipo de RCE pre-autorización solo se vio «unas pocas veces» en los 23 años de historia de WordPress. Si tu sitio estaba expuesto, un atacante podía tomar control total del servidor — base de datos, archivos, configuración, todo.

¿Cómo actualizar tu sitio WordPress a la versión 7.0.2?

Lo ideal es que el parche ya se haya aplicado solo. Debido a la gravedad, WordPress.org activó actualizaciones forzadas mediante el sistema de auto-update para todos los sitios que corrían versiones afectadas. Si tu sitio tiene auto-updates habilitados (que es la configuración por default), probablemente ya esté en 7.0.2.

Si querés verificarlo manualmente o tu instalación no se actualizó por algún motivo —tipo permisos de archivos, configuraciones personalizadas o un hosting que restringe las automáticas—, hacé esto:

• Hacé un backup completo. Base de datos y archivos. Si usás Donweb, verificá si tu plan incluye backups automáticos diarios; muchos hostings argentinos ya los ofrecen sin costo extra.
• Andá a Escritorio > Actualizaciones y clickeá «Actualizar ahora».
• Si no funciona desde el panel, descargá WordPress 7.0.2 desde wordpress.org y hacé la actualización manual por FTP.
• Revisá que el sitio funcione después del update, especialmente formularios, pasarelas de pago y páginas con lógica custom.

¿Qué medidas de seguridad adicionales tomar después del parche?

Actualizar a la última versión es el piso, no el techo. El parche 7.0.2 cierra estas dos vulnerabilidades puntuales, pero mañana aparece otra — y con los avances en modelos de IA para encontrar exploits, el ritmo no va a bajar. Mullenweg lo dijo explícito: «la seguridad va a ser un tema grande este año a medida que la industria tecnológica digiera los avances increíbles en modelos de IA».

¿Qué más podés hacer además de mantener el core actualizado? Acá van algunas capas que no son optativas si tu sitio maneja datos de clientes, ventas o información sensible: Relacionado: guía práctica de plugins 2FA.

• Un WAF (Web Application Firewall). Reglas a nivel de red que bloquean intentos de explotar vulnerabilidades conocidas antes de que lleguen a WordPress. Muchos hostings ya lo incluyen — fijate si el tuyo lo tiene activado por defecto.
• Autenticación en dos pasos (2FA). No alcanza con una contraseña fuerte. Si tu panel de administración no pide segundo factor, cualquier keylogger o filtración de credenciales te deja regalado.
• Plugins y themes siempre al día. Un plugin abandonado con una vulnerabilidad conocida es la puerta de entrada favorita. Si no se actualiza hace 12 meses, buscá alternativa o mandate a arreglarlo vos si tenés con qué.
• Principio de mínimo privilegio. El usuario de la base de datos no necesita permisos de DROP TABLE para funcionar. El usuario administrador de WordPress no debería llamarse «admin». Cosas básicas que casi nadie revisa.
• Auditorías de seguridad periódicas. Herramientas como WP CLI, NinjaScanner o Sucuri SiteCheck te tiran un panorama rápido de archivos modificados y configuraciones sospechosas. Con el ruido que hay ahora sobre seguridad y WordPress, una revisión cada tres meses no es paranoia, es sentido común.

¿Qué hacer si no puedes actualizar WordPress inmediatamente?

Si por algún motivo no podés actualizar ya —un plugin incompatible, una migración en curso o dependencia de una versión específica—, hay medidas temporales que reducen el riesgo. No reemplazan el parche, pero te dan algo de margen mientras resolvés el problema de fondo.

• Deshabilitá la API REST si no la usás. Muchos sitios no necesitan la API REST pública. Con un plugin como Disable REST API o una regla en .htaccess podés bloquear el vector de ataque principal del RCE.
• Implementá reglas de WAF específicas. Si tu hosting o firewall lo permite, añadí reglas que bloqueen patrones de solicitudes por lotes maliciosos a la REST API.
• Restringí el acceso al panel de administración por IP. Limitá el /wp-admin a direcciones IP conocidas mediante .htaccess. Esto no detiene el RCE, pero reduce la superficie de ataque general.
• Contactá a tu proveedor de hosting. WordPress ya coordinó mitigaciones a nivel de red con hosts y CDNs. Preguntá si tu proveedor aplicó esas reglas y si pueden darte una capa extra de protección temporal. En Donweb, por ejemplo, el soporte técnico ya está al tanto de esta vulnerabilidad y puede orientarte.

¿Cómo afecta esta vulnerabilidad a sitios con versiones anteriores?

Las versiones anteriores a 6.8 no están afectadas por ninguna de las dos vulnerabilidades, según confirma el anuncio oficial en español. Si tu sitio corre WordPress 6.7 o inferior, este parche puntual no te toca.

Ahora bien, eso no significa que estés libre de problemas. Las versiones viejas acumulan vulnerabilidades conocidas que ya fueron parcheadas en releases posteriores. Cuanto más atrás estés, más grande es la lista de fallos públicos que un atacante puede explotar con herramientas automatizadas. Si estás en 6.7 o menos, aprovechá el envión de esta emergencia para planificar una actualización a la rama más reciente. El salto puede ser grande, pero el riesgo de quedarte atrás es peor.

¿Qué es y cómo funciona un ataque de Remote Code Execution (RCE) en WordPress?

Un RCE es exactamente lo que suena: un atacante logra ejecutar código arbitrario en tu servidor sin que le des permiso. Ponele que dejás la puerta del datacenter abierta, pero peor, porque ni te enterás que entraron. En este caso concreto, el fallo combinaba una confusión en cómo la REST API manejaba las solicitudes por lotes con una inyección SQL. El atacante enviaba una request preparada, la API se confundía al rutear los parámetros, la consulta maliciosa llegaba a la base de datos y de ahí ejecutaba comandos en el sistema operativo.

¿Por qué fue tan grave este? Porque no requería autenticación. Cualquiera podía lanzar el ataque, sin tener usuario ni contraseña, sin estar logueado, sin nada. Según Matt Mullenweg, el equipo de seguridad de WordPress trabajó con hosts y CDNs para mitigar el ataque a nivel de red incluso antes de que el parche saliera. La divulgación responsable funcionó: los investigadores reportaron en privado, el equipo actuó, y cuando el parche se publicó, la mayoría de los sitios ya estaban protegidos por las reglas de firewall de sus proveedores de hosting. ¿Alguien lo explotó masivamente antes? No hay evidencia pública de que haya pasado hasta el 17 de julio, pero con un vector de ataque tan limpio, la ventana de exposición era real.

¿Qué significa para empresas y equipos en Latinoamérica?

En la región, donde muchas pymes y negocios digitales manejan sus propios sitios WordPress sin un equipo de sistemas dedicado, este parche tiene un peso extra. La actualización forzosa fue un alivio para quienes no monitorean el panel a diario —la mayoría—, pero también dejó al descubierto cuántas instalaciones dependen de configuraciones automáticas que nadie revisa. Si tu sitio se actualizó solo y no te enteraste hasta hoy, es una señal de que hace falta una postura más activa frente a la seguridad.

El otro punto clave es la dependencia de plugins y themes que pueden no ser compatibles con la nueva versión. En Argentina y la región, es común encontrar sitios con plugins heredados, temas comprados hace años que nunca se actualizaron, o desarrollos a medida que alguien hizo y dejó de mantener. Una actualización forzosa como esta puede romper funcionalidades si hay incompatibilidades. La recomendación para equipos locales es doble: por un lado, revisar que todo funcione bien post-parche; por otro, ponerse al día con la deuda técnica de plugins y themes que dejaron de actualizarse. Si tu negocio depende de WordPress, tener un plan de mantenimiento no es un lujo, es un costo operativo más. Complementá con implementación completa de 2FA.

Señales de que tu WordPress fue infectado con malware

Si tu sitio estuvo expuesto antes del parche —o sufriste algún otro ataque—, hay síntomas que no deberías ignorar. La mayoría de los malware para WordPress no son elegantes; dejan mugre visible si sabés dónde mirar:

• Redirecciones fantasmas. El clásico «virus de redireccionamiento WordPress»: tu sitio manda visitantes a páginas de phishing, casinos o tiendas truchas sin que toques una línea de código.
• Archivos desconocidos en el servidor. Revisá wp-content/uploads/ y las raíces de los plugins. Si encontrás PHP sueltos con nombres random tipo wp-tmp-87423.php, tenés visita.
• Rendimiento que se va al tacho. Un pico de uso de CPU sin explicación suele ser señal de que tu servidor está minando criptomonedas para alguien más (sí, en serio, es más común de lo que parece).
• Inyección de scripts en el código fuente. Mirás el HTML de tu página y ves referencias a dominios .ru, .cn o .tk que vos nunca pusiste.
• Errores 500 intermitentes. El atacante metió código roto o modificó archivos del core y ahora WordPress se tropieza a cada rato.

El punto es que si ves una sola de estas señales, no esperes a ver la segunda. Un sitio comprometido contamina la reputación de tu negocio, te mete en listas negras de Google y, si procesás pagos, te puede meter en un quilombo legal con datos de clientes filtrados.

¿Sigue siendo seguro WordPress para una tienda online o negocio?

Sí. Con matices. La pregunta no es si WordPress es seguro en abstracto — es si tu instalación de WordPress es segura. Y eso depende de qué tan al día tengas todo, qué plugins uses, quién configuró el servidor y si alguien monitorea el sitio cuando vos estás durmiendo. Una tienda con WooCommerce puede ser perfectamente segura si mantenés el core, los plugins y el theme actualizados, usás un WAF, tenés backups automáticos y limitás los accesos al mínimo necesario.

La comparación con Shopify es injusta porque son arquitecturas distintas: Shopify es SaaS, el servidor no lo tocás, el hosting lo manejan ellos, y el perímetro de seguridad es enorme pero inflexible. WordPress es self-hosted: flexibilidad total pero responsabilidad total. Si tenés a alguien que se ocupa —vos o un equipo—, WordPress no es menos seguro. Si instalás WooCommerce, 40 plugins random y no volvés a mirar el panel en seis meses, el problema no es WordPress.

¿WordPress 7.0.2 corrige todas las vulnerabilidades conocidas?

No. Y sería peligroso pensarlo así. Este release corrige dos vulnerabilidades específicas: la inyección SQL sencilla y el RCE vía REST API batch-route. Cualquier otra vulnerabilidad —sea del core, de un plugin, de un theme o de la configuración del servidor— sigue ahí hasta que alguien la parchee. La seguridad es un proceso continuo, no un checklist de versiones. La 7.0.2 es un parche de emergencia bien ejecutado, con respuesta rápida y coordinada. Pero mañana sale la 7.0.3 o la 7.1 y seguramente traiga otros fixes que hoy ni conocemos. Tema relacionado: medidas para protegerte de hackers.

Errores comunes al actualizar WordPress o reaccionar a un ataque

Después de años viendo sitios comprometidos y actualizaciones que salen mal, estos son los errores que veo una y otra vez:

• Actualizar sin backup. «No pasa nada, es un parche chiquito». Cuando falla —por incompatibilidad con un plugin, por timeout, por lo que sea—, te quedás con medio WordPress roto y sin forma de volver atrás. Backup primero, siempre.
• Borrarlo todo y reinstalar sin diagnóstico previo. Si tu sitio fue hackeado, reinstalar WordPress limpia los archivos del core pero no necesariamente elimina la puerta trasera que el atacante dejó en la base de datos o en un plugin. Sin análisis previo, reinstalás y a los tres días estás igual.
• Creer que el SSL es suficiente protección. Un certificado SSL encripta los datos en tránsito. No te protege contra inyecciones SQL, RCE ni contraseñas débiles. Es necesario, pero es una sola capa de varias.
• Dejar el debug log activado en producción. Si tu wp-config.php tiene WP_DEBUG en true, estás exponiendo rutas del servidor, errores de base de datos y un montón de información que un atacante agradece. En producción, debug off o log a archivo fuera del directorio público.

Preguntas Frecuentes

¿Qué fallos de seguridad corrige WordPress 7.0.2?

Corrige dos vulnerabilidades: una inyección SQL sencilla reportada por TF1T, dtro y haongo, y un RCE vía REST API batch-route reportado por Adam Kues de Assetnote. La combinación de ambas permitía a un atacante sin autenticación ejecutar código arbitrario en el servidor.

¿Mi versión de WordPress es vulnerable?

Si usás WordPress 6.9, 6.8 o la beta de 7.1, sí. La 6.9 está expuesta a ambas vulnerabilidades, la 6.8 solo a la inyección SQL. Versiones anteriores a 6.8 no están afectadas por estos fallos puntuales. Revisá tu versión en Escritorio > Actualizaciones.

¿La actualización forzosa puede romper mi sitio?

Es posible, sobre todo si tenés plugins o temas muy viejos que no son compatibles con la rama 7.0. Por eso conviene hacer un backup antes de cualquier update, incluso de los forzosos. Si algo falla, podés restaurar y diagnosticar el conflicto en un entorno de staging.

¿Qué hizo WordPress antes del parche para mitigar el ataque?

El equipo de seguridad coordinó con hosts y CDNs para desplegar reglas de firewall a nivel de red que bloquearan los intentos de explotación del RCE, según detalló Matt Mullenweg en su blog. Esto redujo la ventana de riesgo mientras se preparaba el parche.

¿Qué es la vulnerabilidad RCE en WordPress 7.0.2?

Es un fallo que permitía ejecutar comandos arbitrarios en el servidor sin necesidad de autenticarse. Combinaba una confusión en el enrutamiento por lotes de la REST API con una inyección SQL. Un atacante podía tomar control total del sitio, la base de datos y los archivos del servidor.

¿Cómo protegerse si no puedo actualizar WordPress?

Deshabilitá la API REST si no la usás, aplicá reglas de WAF para bloquear patrones de ataque conocidos, restringí el acceso al panel por IP y contactá a tu hosting para ver si aplicaron las mitigaciones a nivel de red. Son medidas temporales: actualizar sigue siendo la prioridad.

Conclusión

WordPress 7.0.2 pasó a ser la actualización más importante del año. Dos vulnerabilidades graves, una con potencial de RCE pre-autorización inédito en años, y una respuesta que combinó divulgación responsable, coordinación con la industria y parche forzoso. El saldo fue positivo: la mayoría de los sitios vulnerables se actualizaron solos y las mitigaciones a nivel de red contuvieron el riesgo durante la ventana crítica.

Lo que sigue es igual de relevante. Las versiones anteriores a 6.8 no están en peligro por este fallo puntual, pero acumulan otros riesgos que las hacen blanco fácil de ataques automatizados. Si estás en una rama vieja, este episodio es la excusa ideal para ponerte al día. Y si ya estás en 7.0.2, el laburo no termina acá: WAF, 2FA, backups y una auditoría de plugins y themes cada tres meses son el estándar mínimo para un sitio que maneja datos, ventas o reputación de marca. La pregunta no es si va a haber otro ataque —va a haberlo—, sino si tu sitio va a estar del lado de los que se actualizaron a tiempo o del lado de los que esperaron a ver qué pasaba.

¿Qué tan grave es el RCE de WordPress 7.0.2?

Según Matt Mullenweg, es uno de los RCE pre-autorización más serios en los 23 años de historia de WordPress, permitiendo a un atacante ejecutar comandos arbitrarios en el servidor sin estar logueado. El parche 7.0.2 cierra este fallo y su aplicación es obligatoria.

¿Cómo sé si mi versión de WordPress está afectada por el RCE?

Si tu sitio corre WordPress 6.9 o la beta de 7.1, tenés ambas vulnerabilidades (RCE y SQL injection). Si estás en 6.8, solo sufrís la inyección SQL. Las versiones anteriores a 6.8 no están afectadas por ninguna de estas dos vulnerabilidades.

¿WordPress 7.0.2 se actualiza solo?

Sí, debido a la gravedad del fallo, WordPress activó actualizaciones forzadas automáticas para todos los sitios en versiones afectadas. Si tenés los auto-updates habilitados (configuración por defecto), ya deberías estar en 7.0.2. Si no, podés actualizar manualmente desde el panel o por FTP.

Fuentes

• WordPress 7.0.2 Release – WordPress News — Anuncio oficial del lanzamiento con detalle de las vulnerabilidades corregidas (17 de julio de 2026).
• Important Security Update – Matt Mullenweg — Post del cofundador de WordPress sobre la gravedad del RCE y la coordinación con hosts y CDNs (18 de julio de 2026).
• WordPress 7.0.2 – Actualización de seguridad — Versión en español del comunicado oficial con las mismas especificaciones técnicas (17 de julio de 2026).
• BBC News – WordPress security — Cobertura periodística sobre los ataques de malware recurrentes en sitios empresariales con WordPress (julio de 2026).