El ecosistema de WordPress vuelve a estar en el punto de mira de la ciberseguridad mundial. Una nueva vulnerabilidad bautizada como ‘Click2Shell’ ha puesto en alerta a administradores y empresas que gestionan sitios en la plataforma m\u00e1s utilizada de la web. Se trata de una cadena de ejecuci\u00f3n remota de c\u00f3digo que afecta al componente principal (Core) de WordPress y que, de ser explotada con \u00e9xito, permite a un atacante ejecutar c\u00f3digo PHP arbitrario en el servidor de la v\u00edctima. La gravedad del asunto reside no solo en la capacidad de ejecutar comandos, sino en que la puerta de entrada puede ser tan simple como un clic de un administrador en un enlace aparentemente inofensivo.<\/p>\n
El investigador de seguridad Paulos Yibelo, de la plataforma aut\u00f3noma de pruebas de penetraci\u00f3n pwn.ai<\/a>, descubri\u00f3 y report\u00f3 esta falla a WordPress el pasado 22 de agosto. Aunque la vulnerabilidad no tiene un identificador CVE oficial, la compa\u00f1\u00eda ya ha corregido el problema de forma silenciosa con el lanzamiento de la versi\u00f3n WordPress 7.1.1<\/a> la semana pasada. La correcci\u00f3n aborda una brecha que, combinada con un tema especialmente dise\u00f1ado, puede comprometer por completo la seguridad del sitio, incluyendo el acceso a archivos sensibles como el ‘wp-config.php’, que contiene las credenciales de la base de datos.<\/p>\n El hallazgo es particularmente relevante para el mercado hispanohablante, donde WordPress potencia una parte significativa de los sitios web corporativos y gubernamentales. Entender c\u00f3mo funciona esta cadena de ataque, por qu\u00e9 se produce el fallo y cu\u00e1les son las medidas de mitigaci\u00f3n inmediatas es crucial para proteger la integridad de los datos. A continuaci\u00f3n, desglosamos los aspectos t\u00e9cnicos clave de Click2Shell, su impacto real y las recomendaciones esenciales que todo administrador debe aplicar sin demora.<\/p>\n Click2Shell es una vulnerabilidad de tipo cross-site request forgery (CSRF) que permite una cadena de ejecuci\u00f3n remota de c\u00f3digo (RCE) sin necesidad de autenticaci\u00f3n previa del atacante. Sin embargo, esta premisa tiene un matiz crucial: para que el ataque sea exitoso, una sesi\u00f3n de usuario con privilegios de administrador debe interactuar con un enlace malicioso. La mec\u00e1nica se basa en una discrepancia en la interpretaci\u00f3n de una URL de vista previa de temas de WordPress. Seg\u00fan el an\u00e1lisis t\u00e9cnico, \u00abun valor de una URL de vista previa de tema se interpreta una vez por la API de Temas de WordPress.org y una segunda vez, de forma err\u00f3nea, por el JavaScript del navegador del administrador\u00bb.<\/p>\n Esta doble interpretaci\u00f3n es la clave del fallo. El proceso comienza cuando el atacante prepara un enlace que, al ser visitado por el administrador, orquesta la instalaci\u00f3n de un tema malicioso o vulnerable desde el repositorio oficial. El concepto de \u00abtema vulnerable\u00bb es esencial: el atacante no introduce c\u00f3digo arbitrario directamente, sino que se aprovecha de un tema leg\u00edtimo que posee una falla de seguridad conocida capaz de ejecutar PHP. De esta manera, se sortea la verificaci\u00f3n de integridad y se logra que el c\u00f3digo corra en el servidor.<\/p>\n El descubrimiento de Yibelo revela un vector de ataque inusual pero devastador. La vulnerabilidad permite agregar un tema de WordPress a un sitio objetivo sin que el administrador lo instale expl\u00edcitamente. Lo m\u00e1s preocupante es que la ejecuci\u00f3n del c\u00f3digo PHP no requiere que el tema est\u00e9 activado formalmente. El investigador comprob\u00f3 que, incluso estando inactivo, un tema puede ejecutar PHP durante una vista previa de Customizer. Esta funcionalidad de personalizaci\u00f3n, que permite ver cambios en tiempo real, se convierte en el escenario perfecto para disparar el c\u00f3digo malicioso. El administrador solo tiene que visitar la URL con el tema seleccionado para que el servidor procese el PHP vulnerable.<\/p>\n Este matiz t\u00e9cnico es lo que eleva la peligrosidad de Click2Shell. No se necesita acabar la instalaci\u00f3n ni guardar los cambios; la simple carga de la vista previa ya es suficiente para que el servidor ejecute las instrucciones. En el PoC publicado, se demuestra c\u00f3mo un atacante puede usar una cadena de robo de archivos o escritura arbitraria en el servidor, todo con la \u00fanica condici\u00f3n de que una v\u00edctima con permisos de administrador haga clic en un enlace especialmente dise\u00f1ado, a menudo distribuido a trav\u00e9s de campa\u00f1as de phishing o mediante un simple clic en una imagen.<\/p>\n La explotaci\u00f3n de Click2Shell no requiere que el atacante tenga una cuenta en la web vulnerada, ni poseer la instalaci\u00f3n de un nonce, ni privilegios administrativos propios. Esto reduce dr\u00e1sticamente la barrera de entrada para los ciberdelincuentes. No obstante, la condici\u00f3n imprescindible es la interacci\u00f3n del administrador. La firma de seguridad Patchstack, que ha analizado el exploit, destaca que solo un administrador puede desencadenar la cadena de ataque. Los usuarios con roles de Autor o Editor no tienen los permisos necesarios para instalar temas, por lo que el alcance del ataque se limita a las cuentas con m\u00e1ximos privilegios.<\/p>\n Esta dependencia de la acci\u00f3n del administrador convierte al factor humano en el eslab\u00f3n m\u00e1s d\u00e9bil. Los vectores de ataque m\u00e1s probables son el phishing dirigido o la explotaci\u00f3n de una vulnerabilidad de cross-site scripting (XSS) preexistente. En el caso de un XSS, el atacante podr\u00eda inyectar el c\u00f3digo malicioso en el propio sitio o en un dominio de confianza, forzando al navegador del administrador a enviar la solicitud a la URL de Click2Shell sin que este se percate. Por tanto, aunque t\u00e9cnicamente es una vulnerabilidad de \u00abno autenticaci\u00f3n\u00bb, en la pr\u00e1ctica requiere de una acci\u00f3n involuntaria de una cuenta con altos privilegios.<\/p>\n Las consecuencias de una explotaci\u00f3n exitosa van mucho m\u00e1s all\u00e1 de la instalaci\u00f3n de un tema no deseado. Al lograr la ejecuci\u00f3n de c\u00f3digo PHP en el servidor, el atacante obtiene un control sin precedentes sobre la plataforma. Las acciones t\u00edpicas incluyen la modificaci\u00f3n o eliminaci\u00f3n de archivos centrales del sitio, lo que puede provocar una denegaci\u00f3n de servicio (DoS) o la total defacement de la p\u00e1gina. El acceso a archivos sensibles es otro de los riesgos m\u00e1s cr\u00edticos, en particular el robo del archivo wp-config.php<\/strong>, que alberga las claves de autenticaci\u00f3n y las credenciales de la base de datos.<\/p>\n La obtenci\u00f3n de estas credenciales permite al agresor conectarse directamente a la base de datos, crear cuentas de administrador falsas (usuarios rogue) o modificar la estructura del sitio a voluntad. Adem\u00e1s, la ejecuci\u00f3n de scripts maliciosos puede convertir el servidor en una puerta trasera persistente, utiliz\u00e1ndose para lanzar ataques a otros sistemas o para robar informaci\u00f3n confidencial de los visitantes, como datos de tarjetas de cr\u00e9dito o credenciales de acceso. El informe t\u00e9cnico de pwn.ai demuestra que esta es una v\u00eda directa a la exfiltraci\u00f3n de datos masiva y al compromiso total de la infraestructura.<\/p>\n La respuesta es s\u00ed, pero exclusivamente si se ha aplicado la actualizaci\u00f3n correspondiente. La vulnerabilidad fue corregida en la versi\u00f3n 7.1.1 de WordPress. El parche soluciona el problema al escapar el \u00abtema slug\u00bb antes de usarlo dentro del selector de jQuery, restringiendo el selector para que \u00fanicamente coincida con las tarjetas de tema reales en la interfaz. Esta correcci\u00f3n impide que la inyecci\u00f3n de la URL se interprete como una instrucci\u00f3n de JavaScript malicioso. Si su sitio opera con la versi\u00f3n 7.1.0 o anterior, est\u00e1 expuesto a esta falla de seguridad.<\/p>\n Para los administradores que no puedan actualizar de inmediato, existe una alternativa de mitigaci\u00f3n. Patchstack ha se\u00f1alado que los sitios con la constante DISALLOW_FILE_MODS<\/strong> habilitada en el archivo ‘wp-config.php’ no pueden ser forzados a instalar el tema malicioso. Esta directiva es un mecanismo de seguridad que impide la modificaci\u00f3n de archivos a trav\u00e9s del editor de temas del panel de administraci\u00f3n. Sin embargo, esta medida es un paliativo, no una soluci\u00f3n definitiva, ya que podr\u00eda bloquear funcionalidades leg\u00edtimas del sitio.<\/p>\n A continuaci\u00f3n, se detallan las recomendaciones jer\u00e1rquicas para mitigar el riesgo de forma efectiva:<\/p>\n La respuesta t\u00e9cnica indica una regla de oro en seguridad: la prevenci\u00f3n no es suficiente y la capacidad de respuesta es clave. La ausencia de una actualizaci\u00f3n inmediata en este contexto puede traducirse en la p\u00e9rdida total de la confidencialidad, integridad y disponibilidad de la plataforma.<\/p>\n La ausencia de un identificador CVE en la publicaci\u00f3n de la vulnerabilidad es un factor que no debe subestimar la gravedad del problema. La comunidad de seguridad a menudo se gu\u00eda por estos identificadores para priorizar parches, pero su ausencia puede generar una falsa sensaci\u00f3n de seguridad. La falta de un CVE asignado no significa que el fallo no exista o que no sea explotado. De hecho, la existencia de un PoC p\u00fablico publicado el mismo d\u00eda del anuncio del parche acorta dr\u00e1sticamente la ventana de remediaci\u00f3n. En el momento en que Yibelo public\u00f3 los detalles t\u00e9cnicos, los atacantes avanzados pudieron crear exploits funcionales en cuesti\u00f3n de horas, aprovechando esa \u00abzona de confort\u00bb que otorga el desconocimiento generalizado.<\/p>\n La decisi\u00f3n de pwn.ai de publicar el exploit puede interpretarse como una estrategia de divulgaci\u00f3n responsable combinada con presi\u00f3n. Al publicar la prueba de concepto, se fuerza a la comunidad a aplicar el parche de manera urgente, pero tambi\u00e9n se entrega a los ciberdelincuentes el arma para atacar a quienes no hayan actualizado. En este escenario, la velocidad de reacci\u00f3n de los administradores es la \u00fanica distinci\u00f3n entre un susto y un desastre. Los equipos de respuesta a incidentes deben asumir que la brecha ya ha tenido lugar y trabajar bajo la premisa de un compromiso post-explotaci\u00f3n para detectar actividades maliciosas.<\/p>\n El vector de ataque basado en temas vulnerables subraya una realidad inc\u00f3moda: la seguridad de WordPress no depende solo del n\u00facleo, sino del ecosistema. Un administrador puede tener el Core actualizado, pero si utiliza un tema de terceros con una falla de seguridad, la cadena de ataque se mantiene. La lecci\u00f3n aqu\u00ed es que la gesti\u00f3n del riesgo en la plataforma exige una visi\u00f3n integral que incluya la evaluaci\u00f3n constante de todos los componentes, especialmente el c\u00f3digo que no desarrollamos nosotros mismos.<\/p>\n El descubrimiento de Paulos Yibelo ha sido recibido con seriedad por el ecosistema de seguridad. Patchstack, una empresa con amplia experiencia en la investigaci\u00f3n de vulnerabilidades en WordPress, ha confirmado el an\u00e1lisis t\u00e9cnico y ha sido la voz autorizada para interpretar el impacto real. Se\u00f1alan que la explotaci\u00f3n de Click2Shell est\u00e1 dise\u00f1ada para ser utilizada en campa\u00f1as de phishing masivo o selectivo, dirigidas a administradores con buenos conocimientos t\u00e9cnicos pero que presentan fatiga ante el exceso de parches. La sofisticaci\u00f3n reside no en el vector inicial, sino en la cadena de explotaci\u00f3n que utiliza un componente de confianza (el tema) para ejecutar c\u00f3digo arbitrario.<\/p>\n La reacci\u00f3n de WordPress, al publicar silenciosamente la correcci\u00f3n una semana antes de la divulgaci\u00f3n p\u00fablica, sugiere un proceso de divulgaci\u00f3n coordinada que respet\u00f3 los plazos de desarrollo. No obstante, la decisi\u00f3n de retrasar la divulgaci\u00f3n p\u00fablica hasta tener listo el parche es una espada de doble filo. Por un lado, da tiempo a los sitios m\u00e1s grandes a prepararse; por otro, no hay evidencia de que se haya contactado a los administradores de manera masiva antes del 15 de abril, fecha en la que se public\u00f3 la informaci\u00f3n. Esta ventana de tiempo, conocida como \u00abzero-day\u00bb para los sistemas desactualizados, sigue siendo un caldo de cultivo para la explotaci\u00f3n activa.<\/p>\n Desde una perspectiva empresarial, la publicaci\u00f3n de un PoC suele acelerar la adopci\u00f3n de parches. La conferencia sobre el Validation Summit 2026<\/a> de este a\u00f1o ya enfatiza la necesidad de validar la seguridad de forma continua. Este caso es un ejemplo perfecto de la nueva realidad: la validaci\u00f3n de la seguridad ya no es un evento trimestral, sino un proceso continuo en el que se deben simular ataques y verificar que los controles funcionan. La cloud y las infraestructuras h\u00edbridas son las m\u00e1s expuestas a este tipo de fallos, lo que indica que los CISO<\/a> deben operar bajo un modelo de \u00abasumir que el atacante ya est\u00e1 dentro\u00bb.<\/p>\n Ante la confusi\u00f3n generada por este tipo de amenazas, los administradores de sitios web suelen formular una serie de consultas claras. Respondemos a las cuatro m\u00e1s relevantes para aportar claridad y orientaci\u00f3n accionable.<\/p>\n En el contexto de Click2Shell, nos referimos a la \u00abfuerza bruta\u00bb de instalar un tema de forma forzada, sin que el administrador lo desee. El atacante fuerza al navegador a ejecutar una solicitud que instala un tema malicioso. Esta t\u00e9cnica se basa en el abuso de la confianza del usuario en la URL, no en adivinar contrase\u00f1as. Es una distinci\u00f3n importante que subraya por qu\u00e9 la MFA (Multi-Factor Authentication<\/em>) es \u00fatil, pero no siempre suficiente si el atacante secuestra la sesi\u00f3n.<\/p>\n Si su sitio no se ha actualizado a la 7.1.1, el primer paso es aplicar el parche lo antes posible. Si el sistema est\u00e1 comprometido, actualizar no es suficiente. Debe consultar a un experto en seguridad para que realice una limpieza exhaustiva del sitio. Mientras tanto, la habilitaci\u00f3n de DISALLOW_FILE_MODS<\/strong> en el archivo de configuraci\u00f3n es una barrera temporal, pero recuerde eliminar esa directiva despu\u00e9s de actualizar para no bloquear futuras actualizaciones leg\u00edtimas.<\/p>\n S\u00ed y no. La interfaz de administraci\u00f3n es segura desde el punto de vista de transporte (HTTPS). Sin embargo, la vulnerabilidad no reside en la red de transporte, sino en la l\u00f3gica de la aplicaci\u00f3n. Un atacante no necesita interceptar su tr\u00e1fico para explotar Click2Shell; solo necesitan que usted visite un enlace malicioso. El uso de una VPN en el m\u00f3vil no le protege de este tipo de ataque de secuestro de navegador.<\/p>\n Un \u00abnonce\u00bb (number used once – n\u00famero de uso \u00fanico) es un token de seguridad que se utiliza en WordPress para verificar la intenci\u00f3n del usuario y proteger contra ataques CSRF. La ausencia de necesidad de un nonce en el exploit es lo que hace tan peligroso a Click2Shell, ya que el atacante ahorra tiempo al no tener que robar este token. El parche refuerza la validaci\u00f3n de tipo de archivo y el uso de una lista blanca de car\u00e1cteres, cortando la posibilidad de que una inyecci\u00f3n se confunda con una petici\u00f3n leg\u00edtima.<\/p>\n Con el fin de contextualizar la amenaza, es \u00fatil comparar la seguridad de este vector con otros t\u00edpicos del ecosistema. A continuaci\u00f3n, se presenta un an\u00e1lisis de las medidas m\u00e1s com\u00fanmente recomendadas y su efectividad para esta vulnerabilidad espec\u00edfica.<\/p>\n Esta tabla pone de manifiesto una realidad subyacente: la seguridad en WordPress sigue siendo reactiva. Muchas de las protecciones que se recomiendan a diario (como los plugins de seguridad) no est\u00e1n dise\u00f1adas para detener una amenaza que se origina en el propio n\u00facleo. Las herramientas de terceros pueden ayudar a monitorizar el tr\u00e1fico, pero necesitan actualizaciones constantes para reconocer las firmas de ataque, que hasta la fecha de la publicaci\u00f3n no se conoc\u00edan. Por esta raz\u00f3n, los principios de privilegio m\u00ednimo y la segmentaci\u00f3n de red siguen siendo los pilares de una estrategia de defensa en profundidad.<\/p>\n La aparici\u00f3n de esta vulnerabilidad reconfigura el panorama de la seguridad de WordPress. Los agentes de amenaza est\u00e1n evolucionando hacia la explotaci\u00f3n de la confianza en el ecosistema. Ahora que conocemos las consecuencias de una URL mal formada, la industria de la seguridad debe avanzar hacia la implementaci\u00f3n del principio de \u00abno confiar en la entrada del usuario\u00bb, incluso cuando proviene de la consola de administraci\u00f3n. Es probable que veamos una ola de auditor\u00edas de c\u00f3digo en el n\u00facleo de WordPress y en los temas m\u00e1s populares, buscando patrones de inclusi\u00f3n de errores que puedan ser forzados desde una URL. La anticipaci\u00f3n estrat\u00e9gica sugiere que la pr\u00f3xima gran batalla se librar\u00e1 en el \u00e1mbito de la seguridad aplicativa, donde la validaci\u00f3n de entrada ser\u00e1 tan importante como la gesti\u00f3n de contrase\u00f1as.<\/p>\n Para los administradores, la conclusi\u00f3n principal es que la vigilancia tecnol\u00f3gica es un deber continuo. Adoptar una postura de \u00abZero Trust\u00bb implica verificar cada solicitud y no fiarse ciegamente de las fuentes internas. Esto significa que las copias de seguridad peri\u00f3dicas no son un seguro, sino un requisito de resiliencia para una recuperaci\u00f3n r\u00e1pida ante un desastre de seguridad. La infraestructura debe estar preparada para un ataque de este tipo, con playbooks espec\u00edficos sobre c\u00f3mo aislar el tema comprometido y reconstruir el sitio desde cero con im\u00e1genes limpias.<\/p>\n Por \u00faltimo, la colaboraci\u00f3n entre la comunidad de investigadores y el proveedor principal ser\u00e1 m\u00e1s cr\u00edtica que nunca. El equipo que trabaja en el n\u00facleo de WordPress ahora est\u00e1 m\u00e1s accesible que nunca, y la publicaci\u00f3n de este PoC les obliga a mejorar sus procesos de revisi\u00f3n de seguridad. Para el administrador medio, lo que queda es una llamada a la acci\u00f3n clara: revise sus versiones, forme a sus equipos sobre phishing y no asuma que porque el proveedor es seguro, el c\u00f3digo es seguro. La seguridad es una pr\u00e1ctica, no un producto.<\/p>\n","protected":false},"excerpt":{"rendered":" El ecosistema de WordPress vuelve a estar en el punto de mira de la ciberseguridad mundial. Una nueva vulnerabilidad bautizada como ‘Click2Shell’ ha puesto en alerta a administradores y empresas que gestionan sitios en la plataforma m\u00e1s utilizada de la web. Se trata de una cadena de ejecuci\u00f3n remota de c\u00f3digo que afecta al componente […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-69452","post","type-post","status-publish","format-standard","category-tecnologia"],"_links":{"self":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69452","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/comments?post=69452"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69452\/revisions"}],"predecessor-version":[{"id":69454,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69452\/revisions\/69454"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media?parent=69452"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/categories?post=69452"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/tags?post=69452"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\u00bfQu\u00e9 es Click2Shell y c\u00f3mo funciona la cadena de ataque?<\/h2>\n
El papel del Customizer y la ejecuci\u00f3n de PHP en temas inactivos<\/h3>\n
Requisitos y alcance: qui\u00e9n puede explotar Click2Shell<\/h2>\n
El impacto m\u00e1s all\u00e1 de la instalaci\u00f3n de temas<\/h3>\n
Parche necesario: \u00bfEst\u00e1 su sitio protegido contra Click2Shell?<\/h2>\n
\n
El contexto cr\u00edtico: Por qu\u00e9 la falta de un CVE no resta gravedad<\/h2>\n
Respuesta de los investigadores y la reacci\u00f3n del ecosistema<\/h2>\n
Preguntas frecuentes sobre Click2Shell<\/h2>\n
\u00bfQu\u00e9 es exactamente un ataque de fuerza bruta en este contexto?<\/h3>\n
\u00bfC\u00f3mo protejo mi sitio si me olvid\u00e9 de actualizar WordPress?<\/h3>\n
\u00bfEs seguro el entorno de administraci\u00f3n en m\u00f3viles?<\/h3>\n
\u00bfQu\u00e9 es el \u00abnonce\u00bb de instalaci\u00f3n y por qu\u00e9 se menciona tanto?<\/h3>\n
Comparativa y alternativas de mitigaci\u00f3n para WordPress<\/h2>\n
\n
\n Medida de Seguridad<\/th>\n Efectividad contra Click2Shell<\/th>\n Comentario de Expertos<\/th>\n<\/tr>\n \n Actualizaci\u00f3n a 7.1.1<\/td>\n Alta<\/td>\n La \u00fanica soluci\u00f3n completa que elimina la vulnerabilidad en el c\u00f3digo fuente.<\/td>\n<\/tr>\n \n Firewall de Aplicaciones (WAF)<\/td>\n Media<\/td>\n Puede bloquear patrones de URL maliciosos si se actualizan las reglas, pero puede tener falsos positivos y no detiene la causa ra\u00edz si la solicitud es leg\u00edtima.<\/td>\n<\/tr>\n \n Deshabilitar edici\u00f3n de archivos<\/td>\n Media<\/td>\n Bloquea la explotaci\u00f3n directa si el atacante intenta inyectar c\u00f3digo, pero no detiene la instalaci\u00f3n de un tema externo malicioso. Es como cerrar la puerta trasera, pero dejando la ventana abierta.<\/td>\n<\/tr>\n \n MFA o Autenticaci\u00f3n de Dos Factores<\/td>\n Baja<\/td>\n No previene el ataque, sino que dificulta el acceso posterior a la cuenta si el atacante roba la contrase\u00f1a. No detiene la solicitud maliciosa que se env\u00eda desde el navegador ya autenticado.<\/td>\n<\/tr>\n<\/table>\n Mirando hacia el futuro: Refuerzo de la seguridad en la era post-Click2Shell<\/h2>\n