400.000 sitios WordPress afectados: fallo TranslatePress

Actualizado el 25/08/2026: El CVE-2026-18510 ya tiene calificación oficial de severidad (7.2 sobre 10 en la escala CVSS) y advisory público en GitHub. Sumamos el estado completo de lo confirmado, una comparativa de plugins alternativos y una rutina de prevención para lo que viene.

En pocas palabras: Unos 400.000 sitios WordPress quedaron expuestos por un XSS almacenado no autenticado en el plugin TranslatePress (CVE-2026-18510), divulgado por Wordfence en agosto de 2026. El fallo afecta todas las versiones hasta la 3.2.6 inclusive y permite secuestrar la sesión de un administrador mediante un comentario malicioso.

Una vulnerabilidad TranslatePress WordPress de tipo XSS almacenado (CVE-2026-18510) dejó expuestos unos 400.000 sitios, según la estimación que publicó Wordfence en agosto de 2026. El fallo afecta a todas las versiones hasta la 3.2.6 inclusive y, explotado desde los comentarios del sitio, le da al atacante una ruta directa hacia el robo de la sesión de un administrador.

TranslatePress es un plugin de traducción para WordPress con más de 200.000 instalaciones activas con el que podés convertir un sitio a varios idiomas editando los textos directamente desde la interfaz. La vulnerabilidad registrada como CVE-2026-18510 es un cross-site scripting almacenado no autenticado: alguien publica un comentario con código oculto, el plugin decodifica ese contenido al renderizar la traducción y el script se ejecuta en el navegador de cada visitante hasta que se elimina el comentario.

¿Qué es la vulnerabilidad CVE-2026-18510 en TranslatePress?

Es un cross-site scripting almacenado, también llamado XSS persistente, que se explota sin necesidad de tener cuenta en el sitio y a través del contenido de los comentarios. Acá la diferencia con un XSS común es clave: en un XSS reflejado el código viaja en un link y necesita que la víctima haga clic; en uno almacenado el payload queda guardado en tu base de datos y se dispara solo, para cada visitante, hasta que alguien lo borra.

El caso figura como CVE-2026-18510 en la base CVE del MITRE y tiene advisory público en GitHub bajo el identificador GHSA-fhvv-89cj-8528. La calificación de severidad y el resto del estado del caso los desglosamos en la sección siguiente, porque hubo novedades desde la primera publicación de esta nota.

¿Cómo funciona el ataque a través de los comentarios de TranslatePress?

Ponele que tenés un sitio bilingüe con los comentarios abiertos. Alguien deja un comentario que parece totalmente normal, quizás con un emoji y unas palabras amables. Adentro, invisible, trae un payload codificado en URL metido entre los marcadores gettext que TranslatePress usa para señalar cadenas traducibles. Cuando el plugin decodifica esos marcadores para mostrar la traducción, el contenido no queda escapado como corresponde: el script termina colgado de un atributo href o src, y el navegador de quien visita la página lo ejecuta sin preguntarle nada a nadie.

El atacante publica el comentario, TranslatePress procesa los marcadores al renderizar la página, decodifica algo que debía quedarse como texto plano, el payload cae dentro de un atributo de enlace o imagen, y cuando un administrador entra a moderar comentarios el JavaScript corre en su navegador con sus permisos y sus cookies de sesión servidas en bandeja. Ya lo cubrimos antes en reforzar tu sitio con cabeceras HTTP.

¿Y qué gana el atacante con todo este baile? Ejecutar JavaScript arbitrario en el navegador de cualquiera que cargue esa página. Incluido vos, logueado como admin.

Lo irónico es que el mecanismo abusado es el mismo que hace posible la edición de traducciones «en vivo» desde el frontend, el gran argumento de venta del plugin. (Sí, la misma «magia» que te ahorra trabajo le abre la puerta al atacante.) Lo explicamos a fondo en reforzar las cabeceras HTTP de tu sitio.

¿Por qué la vulnerabilidad TranslatePress WordPress alcanzó a 400.000 sitios?

Porque TranslatePress es enorme y la puerta de entrada no exige credenciales. Según el análisis de Wordfence, unos 400.000 sitios siguen corriendo versiones vulnerables, mientras el plugin gratuito acumula más de 200.000 instalaciones activas en WordPress.org. La brecha entre ambos números se explica por licencias premium, redes multisitio y agencias que replican el mismo stack en decenas de clientes.

Escala aparte, hay otro factor que agrava el panorama: un único exploit funciona contra todos los sitios vulnerables por igual. Los escáneres automáticos buscan huellas de versiones viejas las 24 horas, así que cuando el detalle técnico se vuelve público, el salto de la teoría al ataque automatizado se mide en días, no en meses.

Vulnerabilidad TranslatePress WordPress: qué está confirmado y qué sigue sin confirmarse

Al 25/08/2026 el caso tiene contornos claros: el fallo CVE-2026-18510 afecta TranslatePress hasta la 3.2.6, se explota sin credenciales vía comentarios y quedó calificado con 7.2 puntos sobre 10 en la escala CVSS, dentro del rango alto. El parche existe y está disponible desde la versión 3.3. Lo que ninguna fuente confirma todavía: campañas masivas de explotación y el comportamiento de los complementos premium.

Ese 7.2 merece una pausa. La banda alta de CVSS va de 7.0 a 8.9, y la nota no trepa a crítica porque el daño técnico tiene techo: ejecución de scripts en el navegador, sin acceso directo al servidor. Ahora bien, el puntaje mide severidad técnica, no urgencia operativa. Como el exploit no pide usuario ni contraseña y el payload permanece guardado en la base, el riesgo real para un sitio con comentarios abiertos corre por encima de lo que sugiere el dígito.

Esto es lo que consta en las fuentes oficiales del caso:

• Divulgación pública: Wordfence publicó el análisis técnico y el detalle del payload en agosto de 2026, con estimación de alcance incluida.
• Registro del fallo: el CVE-2026-18510 está cargado en la base del MITRE y el advisory GHSA-fhvv-89cj-8528 está publicado en GitHub.
• Versión segura: TranslatePress 3.3 incorpora el parche y está disponible para descargar desde WordPress.org.
• Mecanismo de ataque: contenido de comentarios decodificado sin escapar durante el renderizado de traducciones, con ejecución en el navegador de quien visita la página.

Y esto sigue sin estar confirmado:

• Explotación en escala: no hay telemetría pública de campañas masivas ni atribución a grupos conocidos; los detalles técnicos son públicos, así que el escenario puede moverse rápido.
• Alcance en complementos premium: los add-ons comerciales de TranslatePress no figuran en el advisory; no queda claro si comparten el código afectado.
• Parcheo real del parque: no existen cifras públicas sobre cuántos de los sitios expuestos ya migraron a la 3.3.

¿Qué riesgos concretos tiene un ataque XSS en TranslatePress?

El catálogo de daño es conocido para cualquiera que haya analizado un XSS persistente, pero conviene tenerlo claro porque define la urgencia.

• Robo de sesión: el script lee las cookies del navegador y las envía a un servidor del atacante; si la víctima era admin, su sesión viaja completa.
• Toma de la cuenta: con la sesión activa, el atacante crea un usuario administrador propio, instala un backdoor y conserva el acceso aunque cierres la sesión original.
• Redirecciones maliciosas: los visitantes terminan en páginas de phishing o en sitios diseñados para explotar su navegador (drive-by).
• Captura de credenciales: el script puede dibujar un formulario de login falso encima del legítimo y registrar usuario y contraseña.
• Inyección de contenido: spam y enlaces de SEO tóxico servidos desde tu dominio, con el costo reputacional que eso implica.

Cubrimos ese tema en detalle en endurecer WordPress usando Patchstack.

El combo más temido es el primero seguido del segundo. Un admin revisa comentarios un lunes a la mañana, el payload corre, y para el martes el sitio tiene un usuario administrador que nadie creó. (Spoiler: casi nadie mira la lista de usuarios.) Tema relacionado: blindar tu instalación de WordPress.

¿Qué versiones de TranslatePress son vulnerables y cuál es la segura?

Todo lo anterior a la 3.3 está comprometido por este fallo, y la historia del plugin muestra un patrón que conviene conocer: ya arrastraba otros problemas graves en rangos de versiones anteriores. Armamos la tabla con lo reportado:

Para auditar tu instalación puntual, la ficha del plugin en WPScan lista las CVEs conocidas con sus rangos de versión, y la base de inteligencia de amenazas de Wordfence documenta este caso con el detalle técnico del payload.

¿Cómo actualizar TranslatePress a la versión segura?

• Hacé backup completo primero: archivos y base de datos. Muchos paneles lo hacen en un clic; si tu hosting es argentino, donweb.com ofrece copias de seguridad en sus planes de hosting, y lo importante es verificar cómo funciona el mecanismo del tuyo antes de tocar nada.
• Actualizá desde Escritorio → Plugins: buscá TranslatePress, tocá Actualizar y confirmá que la versión final sea 3.3 o superior.
• Probalo en staging si podés: sobre todo si usás las funciones avanzadas de traducción automática, porque un plugin de idiomas toca cada plantilla del sitio.
• Vaciá las cachés: plugin de caché, CDN y navegador. Una página cacheada puede seguir sirviendo el payload viejo aunque el código ya esté parcheado.
• Revisá los comentarios pendientes: moderá o borrá lo que huela raro antes de dar por cerrado el tema.

¿Cuánto lleva? Menos de diez minutos en un sitio estándar. La excusa del «lo actualizo el fin de semana» no sobrevive ese cálculo.

¿Qué hacer si tu sitio ya fue comprometido por TranslatePress?

• Cambiá todas las contraseñas: administradores de WordPress, base de datos, FTP y cualquier cuenta con acceso al panel.
• Auditá la lista de usuarios: borrá administradores que nadie creó y revisá fechas de registro sospechosas.
• Limpiá los comentarios infectados: el XSS vive en la base de datos; mientras el comentario siga publicado, el script sigue disparándose.
• Escanear con herramientas de seguridad: los escáneres de Wordfence Security o Sucuri detectan archivos modificados y payloads conocidos.
• Auditá los logs de acceso: buscá picos de tráfico anormal, POSTs raros hacia wp-login.php o peticiones desde IPs desconocidas.
• Si la duda persiste, restaurá un backup anterior a la infección: recuperar limpio supera a limpiar a mano un sitio con backdoors.

Si sospechás acceso no autorizado y no tenés equipo técnico propio, contactá a tu proveedor de hosting el mismo día. Los buenos soportes pueden aislar el sitio, revisar logs del servidor y ayudarte con la restauración antes de que el daño se expanda.

¿Qué plugins alternativos de traducción puedo usar en lugar de TranslatePress?

Sí los hay, y varios con años de recorrido: Polylang, WPML, Transposh y Google Language Translator. Eso sí, ninguna opción está blindada: todo plugin popular acumula avisos de seguridad a lo largo de su vida, así que el criterio de elección debería ser funcional, no el pánico del momento.

• Polylang (gratuita): maneja los idiomas mediante taxonomías y versiones separadas de cada contenido. Es estable, liviana y con enorme adopción. La contrapartida: no replica la edición visual de textos en vivo, así que migrar implica relevar y recargar tus traducciones.
• WPML (paga): el caballo de batalla para tiendas multilingües, con integración profunda con WooCommerce. A favor: soporte comercial y cobertura funcional amplia. En contra: licencia anual y más peso en instalaciones chicas.
• Transposh (gratuita): apuesta por la traducción automática con corrección comunitaria. Arrancás rápido y sin configurar nada complejo, aunque perdés control editorial fino sobre cada cadena.
• Google Language Translator (gratuita): un widget que delega en el motor de Google. Cero mantenimiento, pero calidad variable y dependencia de un tercero para cada página servida.

Mi lectura: si actualizaste a la 3.3 y el sitio funciona, cambiar de plugin ahora es pagar un costo alto para resolver un problema que ya no tenés. Guardá estas opciones para cuando la decisión sea estratégica —por ejemplo, una tienda que necesita catálogos por país— y hacela siempre con staging de por medio.

Errores comunes frente a esta vulnerabilidad

Postergar la actualización. «Lo hago el finde» es, probablemente, la frase favorita de los operadores de los 400.000 sitios todavía vulnerables. Cada día sin parche es ventana abierta para escáneres automáticos que prueban exploits conocidos en masa. Complementá con proteger el acceso con passkeys.

Borrar el comentario y respirar tranquilo. Sacaste el payload, perfecto. Pero si seguís en 3.2.6, el próximo comentario lo repone en treinta segundos. Primero parchear, después higienizar. Ya lo cubrimos antes en proteger tus cuentas con passkeys y segundo factor.

Migrar de plugin en caliente. Cambiar a Polylang o WPML implica reconfigurar idiomas y rehacer traducciones completas, y la chance de romper algo en una mudanza apurada es mayor que el beneficio. La 3.3 resuelve hoy; la migración, si algún día la querés, se planifica con calma y con staging.

Confiar ciegamente en el escáner. Un XSS almacenado no deja archivos modificados: vive en filas de la base de datos que muchos escáneres no inspeccionan a fondo. Complementá con revisión manual de comentarios y usuarios.

Cómo proteger tu WordPress de futuras vulnerabilidades en plugins

Después de un susto así, lo que evita el próximo incidente es rutina, no heroísmo. Ninguna práctica de esta lista requiere presupuesto: exigen hábito.

• Actualizá en las primeras 48 horas: cuando un parche cierra un agujero de seguridad, cada día de espera es ventana abierta para escáneres automáticos. Activá las actualizaciones automáticas para tus plugins críticos y reservá las versiones mayores para revisión manual.
• Mantené un escáner activo: Wordfence Security en su versión gratuita combina firewall y detección de archivos modificados, y avisa cuando un plugin instalado figura en su base de vulnerabilidades.
• Consultá la ficha de WPScan antes de instalar: el archivo de cada plugin en WPScan lista CVEs y rangos de versión afectados. Convertilo en paso obligatorio para cualquier plugin nuevo, no solo después de un incidente.
• Borrá lo que no usás: un plugin desactivado pero instalado sigue siendo superficie de ataque si algún archivo queda accesible. Si no cumple función hoy, fuera.
• Programá backups semanales y probá la restauración: una copia que nunca restauraste es una hipótesis, no un plan. Probala una vez por trimestre en un entorno aparte.

Honestidad obligatoria: ninguno de estos pasos habría impedido el fallo de TranslatePress, que era desconocido hasta su divulgación. Pero todos acortan el tiempo entre aviso y parche, que es la métrica que decide si un CVE te encuentra preparado o con las manos vacías.

Preguntas frecuentes

¿La versión gratuita de TranslatePress también es vulnerable?

Sí, el fallo está en el núcleo del plugin distribuido en WordPress.org, así que alcanza a la versión gratuita y a toda instalación que la use como base. Actualizá a 3.3 tengas la licencia que tengas: el parche aplica a la misma rama de código. Sobre eso hablamos en blindar la base de datos MySQL.

¿Se ha explotado activamente esta vulnerabilidad?

Las fuentes consultadas no documentan campañas masivas de explotación al día de la publicación. Tomalo con pinzas igual: los detalles técnicos ya son públicos y los ataques automatizados suelen aparecer en cuestión de días tras una divulgación de este nivel. Relacionado: asegurar la base de datos MySQL.

¿Estoy expuesto si tengo los comentarios cerrados en mi sitio?

El vector documentado entra por los comentarios, así que con esa puerta cerrada el riesgo vía este exploit cae mucho. Igual conviene actualizar: no está descartado que el mismo mecanismo tenga otras entradas, y quedarte en 3.2.6 te deja sin las mejoras que traiga la rama 3.3.

¿Cómo sé qué versión de TranslatePress tengo instalada?

Entrá a Escritorio → Plugins en tu panel de WordPress y mirá la columna Versión junto a TranslatePress. Si figuran 3.2.6 o números menores, tu sitio está dentro del rango vulnerable y corresponde actualizar hoy mismo.

¿Quién descubrió la vulnerabilidad y cuándo salió el parche?

Wordfence identificó y divulgó el fallo en agosto de 2026, y el arreglo llegó con TranslatePress 3.3. El CVE-2026-18510 quedó registrado en las bases públicas de vulnerabilidades junto al advisory GHSA-fhvv-89cj-8528 en GitHub.

¿Los complementos premium de TranslatePress también tienen el fallo?

El advisory público documenta el problema en el núcleo del plugin; los add-ons comerciales no aparecen mencionados. No queda claro si comparten el código afectado, así que la jugada segura es actualizar el plugin base a la 3.3 y llevar cada complemento a su última versión disponible.

¿Conviene cambiar de plugin de traducción o seguir con TranslatePress?

Sigue siendo razonable mantenerlo actualizado: la 3.3 cierra el problema, y migrar a Polylang o WPML obliga a rehacer configuración y traducciones, con riesgo de romper cosas en el camino. Cambio de plugin solo si además necesitás funciones que TranslatePress no cubre.

Conclusión

Cerramos con el mapa completo del caso: TranslatePress tuvo un XSS almacenado explotable sin cuenta, el CVE-2026-18510 quedó calificado con 7.2 sobre 10 en CVSS, el advisory es público en GitHub y la versión 3.3 ya resuelve el problema. Por qué importa: el ataque apunta justo al momento en que un administrador modera comentarios, y un único exploit sirve para los cientos de miles de sitios que aún no parchean. Qué hacer desde hoy: verificá tu versión, saltá a la 3.3, limpiá comentarios dudosos y rotá contraseñas si algo no te cierra. Después, convertí la respuesta en rutina: actualizaciones en las primeras 48 horas, escáner activo y backups probados. Y si algún día cambiás de plugin de traducción, que sea por estrategia y con staging, no por un susto que ya quedó resuelto.

Fuentes

• Wordfence – Análisis de la vulnerabilidad de account takeover en TranslatePress
• CVE MITRE – Registro CVE-2026-18510
• GitHub Advisory – GHSA-fhvv-89cj-8528
• Wordfence Threat Intel – Detalle técnico del XSS en TranslatePress 3.2.6
• WPScan – Ficha de vulnerabilidades del plugin TranslatePress