La vulnerabilidad de TranslatePress que voy a explicar en este artículo me parece especialmente preocupante por una razón: bajo determinadas circunstancias, un problema relacionado con el almacenamiento de cadenas de traducción puede terminar exponiendo información utilizada para restablecer la contraseña de un administrador de WordPress.
Y cuando una vulnerabilidad puede desembocar en el acceso a una cuenta administrativa, ya no estamos hablando simplemente de modificar una traducción o provocar un comportamiento extraño en una página.
Estamos hablando de la posibilidad de comprometer completamente una instalación de WordPress.
Además, TranslatePress no es precisamente un plugin desconocido. Cuenta con más de 400.000 instalaciones activas, muchas de ellas en proyectos multidioma, tiendas online, webs corporativas o sitios con presencia internacional.
Lo que más me llamó la atención cuando revisé este problema es precisamente su origen.
El problema nace de algo que, a simple vista, parece bastante inocente: el tratamiento y almacenamiento de las cadenas que TranslatePress necesita para realizar las traducciones.
Bajo unas condiciones concretas, el contenido utilizado por WordPress para recuperar una contraseña podía pasar por ese sistema de traducción y acabar almacenado. El inconveniente es que una URL de recuperación de contraseña no es una cadena cualquiera: contiene información sensible que puede permitir establecer una nueva contraseña.
Si posteriormente esa información puede recuperarse sin necesidad de autenticarse, el impacto cambia por completo.
En este artículo voy a explicar cómo funciona la vulnerabilidad de TranslatePress, qué instalaciones pueden estar afectadas, qué consecuencias tendría una explotación y qué conviene revisar incluso después de actualizar el plugin.
También es importante no confundir este problema con otros avisos de seguridad relacionados con TranslatePress. El plugin ha aparecido asociado a distintas vulnerabilidades e incidentes a lo largo del tiempo, y no todos comparten el mismo origen, versiones afectadas o método de explotación.
¿En qué consiste la vulnerabilidad de TranslatePress?
Para entender la gravedad del problema primero hay que comprender una característica básica de TranslatePress.
El plugin necesita procesar y almacenar cadenas para poder ofrecer las traducciones de una web. Eso incluye textos que aparecen en páginas, elementos generados dinámicamente y, dependiendo del funcionamiento de WordPress y de la configuración del sitio, otro contenido que puede pasar por el sistema de traducción.
El problema aparece cuando dentro de esas cadenas termina información que nunca debería quedar expuesta a un usuario no autenticado.
El problema está en las cadenas utilizadas para las traducciones
En este caso, el punto crítico está relacionado con el guardado automático de cadenas.
TranslatePress puede almacenar textos detectados para que posteriormente puedan traducirse y reutilizarse. Es una funcionalidad completamente lógica dentro de un plugin de traducción y, precisamente por eso, el fallo resulta tan interesante desde el punto de vista de la seguridad.
No estamos ante una función cuyo propósito sea administrar usuarios, gestionar contraseñas o modificar permisos.
Sin embargo, una funcionalidad aparentemente independiente puede terminar interactuando con contenido sensible generado por WordPress.
En mi caso, esta es una de las cosas que considero más interesantes de analizar cuando aparece una vulnerabilidad en un plugin: un fallo no tiene por qué encontrarse directamente en una función de seguridad para terminar teniendo consecuencias de seguridad.
Una cadena de traducción puede parecer inofensiva.
Una URL para recuperar una contraseña no lo es.
Y si ambas terminan pasando por el mismo mecanismo, tenemos un problema.
Cómo puede terminar almacenado un enlace de recuperación de contraseña
Cuando se solicita un restablecimiento de contraseña en WordPress, el sistema genera un mensaje que contiene un enlace específico para completar el proceso.
Ese enlace incluye la información necesaria para que WordPress pueda identificar y validar la recuperación.
Bajo las condiciones que hacen posible esta vulnerabilidad, ese contenido podía pasar por el sistema de traducción de TranslatePress.
Como consecuencia, la URL completa de recuperación de contraseña podía terminar almacenada dentro de las tablas utilizadas por el plugin.
Aquí es donde el escenario deja de ser simplemente una filtración interna.
Si esas cadenas almacenadas fueran accesibles exclusivamente para usuarios autorizados, el riesgo sería muy diferente. El problema es que determinadas cadenas podían recuperarse mediante una acción AJAX accesible sin necesidad de autenticación.
Eso crea una cadena de acontecimientos potencialmente muy seria:
un atacante provoca un restablecimiento de contraseña, la URL pasa por el sistema de traducción, queda almacenada y posteriormente puede ser localizada.
En la práctica, eso puede terminar en el control completo de WordPress.
Cómo funciona el ataque paso a paso
A veces una vulnerabilidad parece mucho más complicada cuando se describe únicamente utilizando términos como AJAX, tokens, endpoints, tablas o cadenas almacenadas.
Por eso prefiero verla como una secuencia.
No es necesario que el atacante “adivine” la contraseña del administrador. El problema consiste precisamente en poder aprovechar el propio mecanismo legítimo de recuperación de WordPress.
1. El atacante provoca un restablecimiento de contraseña
El primer paso consiste en iniciar el proceso normal para recuperar la contraseña de una cuenta administrativa.
WordPress genera entonces el contenido necesario para realizar ese cambio y prepara el mensaje que debería llegar exclusivamente al propietario de la cuenta.
En condiciones normales, conocer el nombre de usuario o provocar una solicitud de recuperación no debería ser suficiente para hacerse con la cuenta.
El elemento realmente sensible es el enlace de recuperación.
2. TranslatePress procesa y almacena la cadena
Aquí entra en juego TranslatePress.
Cuando se cumplen las condiciones necesarias, el contenido relacionado con ese correo puede atravesar el mecanismo de traducción.
La URL de recuperación, incluida la información necesaria para completar el cambio de contraseña, puede terminar almacenada como parte de las cadenas procesadas por el plugin.
Este detalle es precisamente lo que convierte una función de traducción en un posible vector de compromiso de cuentas.
No significa que TranslatePress pueda “leer todas las contraseñas” ni que la contraseña actual quede almacenada.
El problema es diferente: puede quedar expuesto el mecanismo que permite establecer una contraseña nueva.
3. La información puede recuperarse mediante AJAX
El siguiente paso es el que convierte el almacenamiento en una vulnerabilidad explotable.
Determinadas cadenas podían consultarse utilizando una acción AJAX accesible sin autenticarse previamente.
Un atacante que supiera qué buscar podía intentar localizar la información correspondiente al restablecimiento de contraseña que acababa de provocar.
En otras palabras, el enlace pensado para llegar únicamente al correo del administrador podía terminar disponible por una segunda vía.
Y esa segunda vía no ofrecía las garantías de acceso que deberían proteger un dato de este tipo.
4. El atacante utiliza el enlace y cambia la contraseña
Una vez obtenido un enlace válido de recuperación, el atacante puede utilizar el flujo normal de WordPress para establecer una contraseña nueva.
Si consigue completar ese proceso sobre una cuenta con privilegios administrativos, el problema deja de estar limitado a TranslatePress.
El atacante pasa a disponer de las capacidades que WordPress entrega a un administrador.
Puede acceder al panel, modificar configuraciones, crear usuarios, instalar componentes o intentar conseguir una persistencia más duradera.
Por eso creo que hablar únicamente de una “filtración de cadenas” se queda muy corto.
La consecuencia verdaderamente relevante es una posible toma de control de una cuenta administrativa.
¿Qué instalaciones de TranslatePress están realmente afectadas?
Aquí conviene evitar tanto el alarmismo como la falsa tranquilidad.
La presencia de TranslatePress en una web no implica automáticamente que esa instalación pudiera explotarse mediante este fallo.
Deben darse unas condiciones determinadas.
Eso reduce la superficie vulnerable respecto al número total de instalaciones, pero no convierte el problema en irrelevante.
El guardado automático de cadenas
Una de las condiciones está relacionada con el sistema utilizado por TranslatePress para guardar automáticamente las cadenas.
Según las condiciones asociadas a este fallo, esa funcionalidad debe encontrarse activa para que la información termine almacenándose de la manera necesaria para la explotación.
Es además una configuración especialmente importante porque el guardado automático se utiliza de forma habitual.
Por eso, simplemente pensar “yo nunca he cambiado esa opción” no significa necesariamente que la instalación esté fuera de riesgo.
La importancia del idioma configurado en la cuenta del administrador
Existe una segunda condición especialmente específica.
El idioma configurado en el perfil del administrador objetivo debe coincidir con uno de los idiomas secundarios que se encuentran publicados en la web.
Esto significa que no todos los administradores de una misma instalación tienen necesariamente las mismas condiciones de exposición.
Por ejemplo, una web puede tener varios idiomas publicados mientras cada usuario administrativo utiliza una configuración de idioma diferente en su perfil.
Para saber si una instalación encaja en el escenario vulnerable no basta con comprobar que TranslatePress está instalado.
Hay que revisar:
- la versión del plugin;
- la configuración relacionada con las cadenas;
- los idiomas publicados;
- el idioma configurado en los perfiles administrativos.
Por qué una explotación condicionada sigue siendo preocupante
Este punto me parece importante porque en seguridad se produce muchas veces una reacción bastante predecible.
Cuando alguien lee que una vulnerabilidad necesita “unas condiciones concretas”, inmediatamente piensa que el riesgo es pequeño.
No necesariamente.
Estas condiciones no hacen que el problema sea menor por definición.
Lo que hacen es reducir el número de instalaciones explotables.
Pero cuando el punto de partida son cientos de miles de webs, incluso un porcentaje relativamente pequeño puede traducirse en una superficie de ataque considerable.
Además, la pregunta correcta no es:
“¿Todas las webs con TranslatePress son vulnerables?”
La pregunta correcta es:
“¿Mi web cumple las condiciones necesarias para que este fallo pueda afectarme?”
Y si la respuesta no está clara, lo razonable es actualizar y revisar la instalación.
¿Qué puede hacer un atacante si consigue acceso de administrador?
Cuando una vulnerabilidad permite cambiar la contraseña de un administrador, el impacto no termina en el momento de iniciar sesión.
En realidad, ahí empieza la parte más peligrosa.
Un administrador de WordPress dispone de permisos suficientes para realizar cambios profundos sobre el sitio.
Eso significa que una cuenta comprometida puede convertirse en la puerta de entrada para ataques que sobrevivan incluso después de que la vulnerabilidad original haya sido corregida.
Crear nuevos usuarios y mantener el acceso
Una de las primeras cosas que puede hacer un atacante es crear nuevas cuentas.
Esto resulta especialmente peligroso porque el propietario de la web puede solucionar el problema inicial, recuperar su contraseña y pensar que todo ha terminado.
Mientras tanto, puede existir otra cuenta administrativa creada durante el compromiso.
Por eso recomiendo revisar siempre la lista completa de usuarios después de un incidente de estas características.
Hay que comprobar especialmente:
- administradores que no reconozcamos;
- nuevas cuentas creadas recientemente;
- usuarios cuyos privilegios hayan cambiado;
- direcciones de correo modificadas;
- cuentas que deberían estar desactivadas.
Cambiar únicamente nuestra propia contraseña no garantiza que el atacante haya perdido el acceso.
Instalar plugins, modificar archivos o introducir puertas traseras
El acceso administrativo también puede utilizarse para instalar componentes.
Un atacante podría añadir un plugin malicioso, modificar funcionalidades existentes o aprovechar otras capacidades disponibles desde WordPress para establecer mecanismos alternativos de acceso.
Aquí es donde entran las conocidas puertas traseras o backdoors.
La idea es sencilla: si el atacante sospecha que la vulnerabilidad de TranslatePress terminará siendo corregida, puede intentar crear una segunda forma de entrar.
También podría modificar contenidos, redireccionar visitantes, insertar spam, alterar enlaces o preparar ataques dirigidos contra los usuarios del sitio.
En una tienda online o en una web corporativa, las consecuencias pueden ir bastante más allá del propio WordPress.
Por qué actualizar puede no ser suficiente si WordPress ya fue comprometido
Este es uno de los puntos que más conviene dejar claros.
Actualizar TranslatePress corrige la vulnerabilidad, pero no necesariamente revierte todo lo que haya ocurrido antes de la actualización.
Imaginemos que un atacante consiguió entrar ayer.
Hoy actualizamos el plugin.
El vector de entrada original puede quedar cerrado, pero un usuario administrativo creado por el atacante sigue existiendo. Lo mismo ocurriría con una puerta trasera o una modificación realizada previamente.
Por eso hay que distinguir dos escenarios.
Si simplemente tenemos una versión vulnerable y no existen indicios de explotación, actualizar rápidamente es la prioridad.
Si existen señales de compromiso, la respuesta debe ser mucho más completa y tratar el sitio como un WordPress potencialmente comprometido.
Cómo solucionar la vulnerabilidad de TranslatePress
La medida más importante es también la más evidente: actualizar TranslatePress.
Según la información correspondiente a este fallo, las instalaciones afectadas deberían utilizar como mínimo TranslatePress 3.3.2.
Mi recomendación, sin embargo, no sería instalar deliberadamente una versión antigua simplemente porque sea la primera que incorpora la corrección.
Siempre que no exista una incompatibilidad conocida, prefiero actualizar a la última versión estable disponible, después de realizar las comprobaciones habituales.
Actualiza TranslatePress a una versión corregida
Antes de modificar una web profesional conviene contar con una copia de seguridad reciente.
En instalaciones especialmente críticas, también puede ser recomendable comprobar primero la actualización en un entorno de staging.
A partir de ahí:
- Accede al panel de WordPress.
- Dirígete a la sección de plugins.
- Comprueba la versión instalada de TranslatePress.
- Actualiza el plugin.
- Verifica que la actualización se haya completado correctamente.
- Comprueba que las traducciones y funcionalidades principales de la web continúan funcionando.
Actualizar los plugins no debería depender únicamente de que aparezcan nuevas funciones.
Creo que esta vulnerabilidad es un ejemplo especialmente claro.
Una nueva versión puede parecer poco interesante porque no incorpora ninguna característica que necesitemos. Sin embargo, esa misma actualización puede estar solucionando un fallo capaz de comprometer una cuenta administrativa.
Por eso las actualizaciones de seguridad forman parte del mantenimiento y no deberían considerarse una tarea opcional.
Comprueba la versión instalada después de actualizar
Otro error bastante habitual es pulsar el botón de actualización y dar por supuesto que el proceso ha terminado correctamente.
Yo prefiero comprobarlo.
Después de actualizar:
- vuelve a la ficha del plugin;
- confirma la versión instalada;
- revisa que no aparezcan errores;
- comprueba que TranslatePress continúa funcionando;
- limpia las cachés si fuera necesario;
- revisa el sitio desde fuera del panel.
Si utilizas sistemas de despliegue, gestión centralizada o actualizaciones automáticas, también conviene verificar que la versión realmente instalada en producción coincide con la esperada.
Qué revisar si tu web pudo haber estado expuesta
Si la web ha utilizado una versión afectada y además cumplía las condiciones necesarias para la explotación, yo no terminaría el trabajo simplemente actualizando TranslatePress.
Haría algunas comprobaciones adicionales.
No porque exista necesariamente un ataque, sino porque son revisiones relativamente sencillas que pueden detectar señales evidentes de compromiso.
Revisa las cuentas de administrador
Empieza por Usuarios.
Comprueba todas las cuentas con privilegios elevados.
Pregúntate:
- ¿Reconozco a todos los administradores?
- ¿Hay alguna cuenta creada recientemente?
- ¿Algún usuario tiene ahora más permisos de los que debería?
- ¿Ha cambiado alguna dirección de correo?
- ¿Existen usuarios antiguos que ya no deberían tener acceso?
Si encuentras una cuenta que no puedes justificar, no deberías limitarte a eliminarla sin más.
Es una señal de que alguien podría haber conseguido acceso y, por tanto, merece una investigación más amplia.
También recomiendo renovar las credenciales administrativas si existen motivos razonables para pensar que hubo un compromiso.
Busca plugins, usuarios y cambios que no reconozcas
Revisa igualmente los plugins instalados.
Un componente desconocido, un plugin que nadie del equipo recuerda haber instalado o cambios inesperados en la configuración pueden ser indicadores importantes.
Conviene revisar también contenidos y configuraciones sensibles:
- páginas modificadas;
- nuevos administradores;
- plugins desconocidos;
- redirecciones;
- código añadido;
- cambios en opciones críticas;
- comportamientos extraños del sitio.
Dependiendo de la importancia de la web y de las evidencias encontradas, puede ser necesario analizar registros y archivos con mucho más detalle.
La cuestión fundamental es no confundir “vulnerabilidad corregida” con “sitio limpio”.
Son dos cosas diferentes.
Activa autenticación en dos pasos
También aprovecharía este incidente para activar autenticación en dos pasos o 2FA en las cuentas administrativas.
Una contraseña fuerte continúa siendo necesaria, pero el segundo factor añade otra barrera.
Precisamente cuando analizamos vulnerabilidades relacionadas con procesos de recuperación de cuentas, resulta evidente la importancia de no depender exclusivamente de una contraseña.
El 2FA no sustituye a las actualizaciones ni convierte una instalación vulnerable en segura.
Es una capa adicional.
Y en seguridad WordPress prefiero trabajar mediante capas: actualizaciones, permisos adecuados, autenticación fuerte, copias de seguridad, supervisión y revisión periódica.
Qué nos enseña esta vulnerabilidad sobre la seguridad de WordPress
Para mí, la conclusión de este caso va bastante más allá de TranslatePress.
En ocasiones se habla de los plugins como si instalar extensiones convirtiera automáticamente a WordPress en inseguro.
No estoy de acuerdo con esa simplificación.
Los plugins son precisamente una de las razones por las que WordPress resulta tan flexible.
El problema aparece cuando instalamos componentes y después olvidamos que forman parte de la superficie que debemos mantener.
Los plugins aumentan la superficie que debemos mantener
WordPress no es inseguro por utilizar plugins, pero cada plugin amplía la superficie que debemos mantener y supervisar.
Cada componente incorpora código, funcionalidades, permisos, integraciones y puntos de interacción con el resto de la instalación.
Eso no significa que debamos instalar cero plugins.
Significa que debemos saber qué tenemos instalado y mantenerlo.
Una web con veinte plugins perfectamente mantenidos puede tener un perfil de riesgo muy diferente al de una web con cinco extensiones abandonadas desde hace años.
Yo revisaría periódicamente:
- plugins realmente necesarios;
- actualizaciones disponibles;
- componentes que ya no se utilizan;
- plugins sin mantenimiento;
- cuentas administrativas;
- copias de seguridad;
- medidas de autenticación.
Reducir superficie innecesaria suele ser una de las medidas de seguridad más sencillas.
Actualizar no consiste únicamente en conseguir nuevas funciones
Muchas personas siguen viendo una actualización como algo relacionado principalmente con mejoras visuales o nuevas características.
En seguridad, esa mentalidad resulta peligrosa.
Podemos tener una contraseña excelente.
Podemos cambiar la dirección de acceso.
Podemos proteger el login frente a intentos automatizados.
Podemos aplicar multitud de medidas de hardening.
Pero una vulnerabilidad crítica dentro de un componente instalado puede proporcionar un camino completamente distinto para atacar la web.
Eso es precisamente lo interesante de este caso.
La seguridad no depende de una única medida.
Depende de mantener todas las capas razonablemente actualizadas y controladas.
Dudas de la comunidad
¿Qué vulnerabilidad tiene TranslatePress?
El fallo que tratamos en este artículo está relacionado con el procesamiento y almacenamiento de cadenas utilizadas por TranslatePress.
Bajo determinadas condiciones, un enlace generado por WordPress para recuperar una contraseña podía pasar por el sistema de traducción y terminar almacenado. Si posteriormente esa información era recuperada sin autenticación, un atacante podía llegar a utilizarla para cambiar la contraseña de una cuenta administrativa.
No debe confundirse con otros fallos o incidentes de TranslatePress que tengan mecanismos diferentes.
¿Qué versiones de TranslatePress están afectadas?
Para esta vulnerabilidad concreta, la referencia mínima de corrección que estamos manejando es TranslatePress 3.3.2.
Aun así, mi recomendación es comprobar cuál es la última versión estable disponible y utilizarla siempre que sea compatible con la instalación.
Además, no conviene aplicar las versiones afectadas de una vulnerabilidad distinta a este problema. TranslatePress ha tenido distintos avisos de seguridad y cada uno puede afectar a ramas diferentes.
¿Cualquier web con TranslatePress puede ser atacada?
No.
La explotación requiere unas condiciones concretas.
Entre ellas se encuentra el guardado automático de cadenas y una determinada relación entre el idioma configurado para el administrador objetivo y los idiomas secundarios publicados en la web.
Por eso la mera presencia de TranslatePress no demuestra que una web fuera explotable.
Pero si utilizas una versión afectada, la opción prudente sigue siendo actualizar.
¿Puede esta vulnerabilidad dar acceso de administrador?
La consecuencia más grave es precisamente esa.
Si el atacante consigue recuperar un enlace válido de restablecimiento correspondiente a una cuenta administrativa, puede llegar a establecer una contraseña nueva.
A partir de ese momento dispondría de los privilegios asociados a esa cuenta.
Por eso considero que el impacto potencial es mucho mayor que el de una simple exposición de información.
¿Actualizar TranslatePress soluciona completamente el problema?
Depende.
Si la vulnerabilidad nunca fue explotada, cerrar el fallo mediante la actualización es la acción fundamental.
Si un atacante ya consiguió acceder al sitio antes de actualizar, instalar la versión corregida no elimina automáticamente usuarios creados, puertas traseras, plugins maliciosos o modificaciones realizadas durante el acceso.
Cuando existen indicios de compromiso hay que revisar la instalación completa.
¿Es seguro seguir utilizando TranslatePress?
La existencia de una vulnerabilidad no significa automáticamente que un plugin deba dejar de utilizarse para siempre.
Los problemas de seguridad pueden aparecer en prácticamente cualquier software suficientemente complejo.
Lo importante es cómo se corrigen, la rapidez con la que se publican actualizaciones y, sobre todo, que los administradores mantengan sus instalaciones al día.
Si utilizo TranslatePress, mi prioridad sería tener instalada una versión corregida y mantener el plugin actualizado.
Actualizar TranslatePress y revisar WordPress
La vulnerabilidad de TranslatePress que hemos analizado demuestra hasta qué punto una función aparentemente alejada de la seguridad puede terminar afectando a uno de los procesos más sensibles de WordPress: la recuperación de una contraseña administrativa.
Lo preocupante no es únicamente que determinada información pueda almacenarse.
Es la secuencia completa.
Un atacante puede provocar un restablecimiento, aprovechar el procesamiento de las cadenas, intentar recuperar la información almacenada y utilizar el enlace resultante para establecer una nueva contraseña.
Si la cuenta afectada es administrativa, las consecuencias pueden incluir desde la creación de nuevos usuarios hasta la instalación de componentes maliciosos o mecanismos de persistencia.
Eso no significa que todas las instalaciones con TranslatePress hayan sido explotables.
Las condiciones importan.
Pero tampoco utilizaría esas condiciones como excusa para retrasar una actualización.
Cuando utilizamos WordPress profesionalmente, mantener los plugins actualizados debería formar parte del mantenimiento ordinario de la web, no ser una reacción excepcional cuando aparece una alerta crítica.
En este caso, actualizar TranslatePress es el primer paso.
Y si la web pudo haber estado expuesta, yo añadiría como mínimo una revisión de usuarios administrativos, plugins instalados, cambios inesperados y mecanismos de autenticación.
Porque cerrar la puerta por la que pudo entrar un atacante es imprescindible.
Pero, si ya entró, también debemos comprobar qué hizo después.
Opinión Personal
Este tipo de vulnerabilidades me parecen especialmente preocupantes porque demuestran que un problema de seguridad puede aparecer en una función que, en principio, no parece tener ninguna relación directa con contraseñas o accesos administrativos.
En el caso de TranslatePress, lo que más me llama la atención es precisamente eso: una funcionalidad relacionada con el tratamiento y almacenamiento de cadenas de traducción puede terminar exponiendo información suficientemente sensible como para facilitar el acceso a una cuenta de administrador de WordPress.
Y ahí está, para mí, la verdadera gravedad del problema.
No hablamos únicamente de que un atacante pueda modificar un texto o provocar un error puntual. Si consigue acceso administrativo, puede crear nuevos usuarios, instalar plugins, cambiar configuraciones, modificar contenidos o intentar mantener el acceso incluso después de que la vulnerabilidad haya sido corregida.
También creo que este caso sirve para recordar algo que muchas veces se pasa por alto: actualizar los plugins no consiste solamente en conseguir nuevas funciones.
Una actualización que aparentemente no aporta nada interesante puede estar solucionando un fallo crítico. Por eso considero que mantener WordPress, sus plugins y sus temas actualizados debería formar parte del mantenimiento habitual de cualquier web profesional.
Además, aunque una vulnerabilidad necesite unas condiciones concretas para poder explotarse, no creo que eso deba generar una falsa sensación de seguridad. Cuando un plugin tiene cientos de miles de instalaciones activas, incluso un porcentaje reducido de webs vulnerables puede representar una superficie de ataque importante.
Mi recomendación es sencilla: mantener TranslatePress actualizado, revisar periódicamente las cuentas administrativas y utilizar medidas adicionales como la autenticación en dos pasos siempre que sea posible.
Y ahora me gustaría conocer tu opinión: ¿utilizas TranslatePress en alguna de tus webs? ¿Crees que prestamos suficiente atención a las actualizaciones de seguridad de los plugins? Déjame tu experiencia y tus dudas en los comentarios.
