Vulnerabilidades

El complemento de inicio de sesión y registro social de Nextend para WordPress es vulnerable a Cross-Site Scripting Reflejado a través del parámetro 'error_description' en todas las versiones hasta la 3.1.12 incluida debido a una sanitización de entrada y un escape de salida insuficientes. Esto hace posible que atacantes no autenticados, con acceso a una cuenta de nivel de suscriptor, inyecten scripts web arbitrarios en páginas que se ejecutan si pueden engañar con éxito a un usuario para que realice una acción como hacer clic en un enlace. NOTA: Esta vulnerabilidad se puede explotar con éxito en una instancia vulnerable de WordPress contra un usuario de nivel superior autenticado previamente con OAuth (por ejemplo, administrador) aprovechando Cross-Site Scripting junto con una determinada técnica de ingeniería social para lograr un escenario de impacto crítico. (Cross-Site Scripting para la creación de cuentas a nivel de administrador). Sin embargo, una explotación exitosa requiere que el "modo de depuración" esté habilitado en la "Configuración global" del complemento.

El complemento Complianz – GDPR/CCPA Cookie Consent para WordPress es vulnerable a Cross-Site Request Forgery en todas las versiones hasta la 6.5.6 incluida. Esto se debe a una validación nonce faltante o incorrecta en la función Process_delete en class-DNSMPD.php. Esto hace posible que atacantes no autenticados eliminen solicitudes de datos GDPR a través de una solicitud falsificada, siempre que puedan engañar al administrador del sitio para que realice una acción como hacer clic en un enlace.

Debido a una validación insuficiente del lado del servidor, una explotación exitosa de esta vulnerabilidad podría permitir a un atacante obtener acceso a determinadas URL a las que no debería tener acceso.

Debido a una validación insuficiente del lado del servidor, un atacante con privilegios de inicio de sesión podría acceder a ciertos recursos a los que no debería tener acceso cambiando los valores de los parámetros.

Una vulnerabilidad de Cross-Site Scripting en Pkp OJS v.3.4 permite a un atacante ejecutar código arbitrario a través del componente Título de entrada.

Una vulnerabilidad de Cross-Site Scripting en Pkp OJS v.3.4 permite a un atacante ejecutar código arbitrario a través del componente de subtítulos de entrada.

Una vulnerabilidad de Cross-Site Scripting (XSS) en Pkp Ojs v3.3 permite a los atacantes ejecutar script web o HTML arbitrarios a través de un payload manipulado inyectado en el parámetro Publicname.

Una vulnerabilidad de Cross-Site Scripting (XSS) en el módulo de producción de Pkp Ojs v3.3 permite a los atacantes ejecutar script web o HTML arbitrarios a través de un payload manipulado inyectado en el campo Asunto de entrada bajo la función Agregar discusión.

Una vulnerabilidad de Cross-Site Scripting (XSS) en el módulo de envío de Pkp Ojs v3.3 permite a los atacantes ejecutar script web o HTML arbitrarios a través de un payload manipulado inyectado en el campo Asunto de entrada bajo la función Agregar discusión.

Se descubrió un problema en phpseclib 1.x anterior a 1.0.23, 2.x anterior a 2.0.47 y 3.x anterior a 3.0.36. Un atacante puede crear un certificado con formato incorrecto que contenga un valor principal extremadamente grande para provocar una denegación de servicio (consumo de CPU para una verificación de primalidad de isPrime). NOTA: este problema se introdujo al intentar solucionar CVE-2023-27560.

Se descubrió un problema en phpseclib 1.x anterior a 1.0.23, 2.x anterior a 2.0.47 y 3.x anterior a 3.0.36. Al procesar el identificador de objeto ASN.1 de un certificado, se puede proporcionar un subidentificador que conduzca a una denegación de servicio (consumo de CPU para decodeOID).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige las dentries eliminadas que aún existen después de sincronizar el registro. Cuando movemos un inodo de un directorio a otro y tanto el inodo como su directorio principal anterior se registraron antes, se supone que no tener la dentry del padre anterior si tenemos un corte de energía después de sincronizar el registro. Se supone que sólo existe el nuevo dentry. En general, esto funciona correctamente, sin embargo, hay un escenario en el que esto no funciona actualmente, porque el padre antiguo del archivo/directorio que se movió no tiene autoridad para un rango que incluye el índice de directorio y las claves de elemento de directorio del dentry anterior. Este caso se explica mejor con el siguiente ejemplo y reproductor: # La prueba requiere un diseño muy específico de claves y elementos en el árbol # fs/subvolume para activar el error. Por eso queremos asegurarnos de que # en cualquier plataforma en la que estemos, tengamos el mismo tamaño de hoja/nodo. # # Actualmente en btrfs el tamaño del nodo/hoja no puede ser menor que el tamaño de la página # (pero puede ser mayor que el tamaño de la página). Por lo tanto, utilice el mayor tamaño de nodo/hoja admitido (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # "testdir" is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory "testdir" with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory "dira", inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to # the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 ("testdir") that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing to inode 1458 (directory "dira"). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. So for the sake of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is th ---truncated---