Vulnerabilidades

El plugin Delete All Comments Easily de WordPress versiones hasta 1.3, carece de comprobaciones de tipo Cross-Site Request Forgery (CSRF), lo que podría resultar en que un atacante no autenticado hiciera que un administrador conectado borrara todos los comentarios del blog

El plugin Coming Soon, Under Construction & Maintenance Mode By Dazzler de WordPress versiones anteriores a 1.6.7, no sanea ni escapa de su ajuste de descripción cuando se muestra en el frontend cuando el modo Coming Soon está habilitado, incluso cuando la capacidad unfiltered_html no está permitida, conllevando a un problema de tipo Cross-Site Scripting Almacenado autenticado

El plugin Connections Business Directory de WordPress versiones anteriores a 9.7, no comprueba ni sanea algunos campos de las conexiones, lo que podría conllevar a un problema de inyección de CSV

El plugin WP-Pro-Quiz de WordPress versiones hasta 0.37, no presenta una comprobación de CSRF cuando se elimina un cuestionario, lo que podría permitir a un atacante hacer que un administrador conectado elimine un cuestionario arbitrario en el blog

El plugin WP Attachment Export de WordPress versiones anteriores a 0.2.4, no presenta controles de acceso apropiados, permitiendo a usuarios no autenticados descargar los datos XML que contienen todos los detalles de los archivos adjuntos/posts en un Wordpress

El plugin LearnDash LMS de WordPress versiones anteriores a 2.5.4, no presenta ninguna autorización ni comprobación del archivo a subir en la función learndash_assignment_process_init(), lo que podría permitir a usuarios no autenticados subir archivos arbitrarios al servidor web

El plugin Accept Donations with PayPal de WordPress versiones anteriores a 1.3.1, ofrece una función para crear botones de donación, que internamente son posts. El proceso para crear un nuevo botón carece de una comprobación de tipo CSRF. Un atacante podría usar esto para que un administrador autenticado cree un nuevo botón. Además, uno de los campos Button no se escapa antes de ser emitido en un atributo cuando se edita un botón, conllevando también a un problema de tipo Cross-Site Scripting Almacenado<br />

El plugin Flat Preloader de WordPress versiones anteriores a 1.5.4, no aplica la comprobación de nonce cuando guarda su configuración, ni sanea ni escapa de ella, lo que podría permitir a atacantes hacer que un administrador con sesión iniciada la cambie con una carga útil de tipo Cross-Site Scripting (desencadenada en el frontend o en el backend, dependiendo de la carga útil)

El plugin WP-Stats de WordPress versiones anteriores a 2.52 no presenta una comprobación de CSRF cuando guarda sus configuraciones, y no escapa de algunas de ellas cuando las emite, permitiendo a un atacante hacer que los usuarios con altos privilegios que han iniciado sesión las cambien y establezcan cargas útiles de tipo Cross-Site Scripting

Spacewalk versión 2.10, y sus derivados como Uyuni versión 2021.08, permiten la inyección de código. El archivo rhn-config-satellite.pl no sanea el nombre del archivo de configuración usado para añadir el par clave-valor específico de Spacewalk. El script está pensado para ser ejecutado por la cuenta de usuario tomcat con Sudo, según la configuración de la instalación. Esto puede conllevar a la posibilidad de que un atacante use la opción --option para anexar código arbitrario a un archivo propiedad de root que finalmente será ejecutado por el sistema. Esto es corregido en Uyuni spacewalk-admin versión 4.3.2-1

** EN DISPUTA ** Se ha detectado un problema en las definiciones de caracteres de la especificación Unicode hasta la versión 14.0. La especificación permite que un adversario produzca identificadores de código fuente, tales como nombres de funciones, utilizando homoglifos que son visualmente idénticos a un identificador de destino. Los adversarios pueden aprovechar esto para inyectar código a través de definiciones de identificadores adversos en dependencias de software ascendente invocadas de forma engañosa en software descendente. NOTA: el Consorcio Unicode ofrece el siguiente enfoque alternativo para presentar este problema. Se observa un problema en la naturaleza del texto internacional que puede afectar a las aplicaciones que implementan la compatibilidad con el estándar Unicode (todas las versiones). A menos que se mitigue, un adversario podría producir identificadores de código fuente utilizando caracteres homogéneos que son visualmente idénticos pero distintos a un identificador de destino. De esta manera, un adversario podría inyectar definiciones de identificadores adversos en el software de entrada que no son detectados por los revisores humanos y son invocados engañosamente en el software de salida. El Consorcio Unicode ha documentado esta clase de vulnerabilidad de seguridad en su documento, Informe Técnico de Unicode #36, Consideraciones de Seguridad de Unicode. El Consorcio Unicode también proporciona orientación sobre las mitigaciones para esta clase de problemas en la Norma Técnica de Unicode #39, Mecanismos de Seguridad de Unicode.

** EN DISPUTA** Se ha detectado un problema en el algoritmo bidireccional de la especificación Unicode hasta la versión 14.0. Permite la reordenación visual de los caracteres a través de secuencias de control, lo que puede ser utilizado para crear código fuente que se traduce en una lógica diferente a la ordenación lógica de los tokens ingeridos por los compiladores e intérpretes. Los adversarios pueden aprovechar esto para codificar el código fuente de los compiladores que aceptan Unicode, de manera que las vulnerabilidades objetivo se introduzcan de forma invisible para los revisores humanos. NOTA: el Consorcio Unicode ofrece el siguiente enfoque alternativo para presentar esta preocupación. Se observa un problema en la naturaleza del texto internacional que puede afectar a las aplicaciones que implementan la compatibilidad con el estándar Unicode y el algoritmo bidireccional Unicode (todas las versiones). Debido al comportamiento de la visualización del texto cuando éste incluye caracteres de izquierda a derecha y de derecha a izquierda, el orden visual de los tokens puede ser diferente de su orden lógico. Además, los caracteres de control necesarios para cumplir los requisitos del texto bidireccional pueden ofuscar aún más el orden lógico de las fichas. A menos que se mitigue, un adversario podría elaborar el código fuente de tal manera que el orden de los tokens percibido por los revisores humanos no coincida con el que será procesado por un compilador/interpretador/etc. El Consorcio Unicode ha documentado esta clase de vulnerabilidad en su documento, Informe Técnico de Unicode #36, Consideraciones de Seguridad de Unicode. El Consorcio Unicode también proporciona orientación sobre las mitigaciones para esta clase de problemas en la Norma Técnica de Unicode #39, Mecanismos de Seguridad de Unicode, y en el Anexo de la Norma de Unicode #31, Identificador de Unicode y Sintaxis de Patrones. Además, la especificación BIDI permite a las aplicaciones adaptar la implementación de manera que pueda mitigar la reordenación visual engañosa en el texto del programa; véase HL4 en el Anexo #9 del Estándar Unicode, Algoritmo Bidireccional Unicode.