Vulnerabilidades

Los complementos File Manager y File Manager Pro para WordPress son vulnerables a Directory Traversal en versiones hasta la versión 7.2.1 (versión gratuita) y 8.3.4 (versión Pro) incluida a través del parámetro de destino en la función mk_file_folder_manager_action_callback_shortcode. Esto hace posible que los atacantes lean el contenido de archivos arbitrarios en el servidor, que pueden contener información confidencial, y cargar archivos en directorios distintos al directorio previsto para la carga de archivos. La versión gratuita requiere acceso de administrador para que esta vulnerabilidad sea explotable. La versión Pro permite integrar un administrador de archivos a través de un código corto y también permite a los administradores otorgar privilegios de manejo de archivos a otros niveles de usuario, lo que podría llevar a que usuarios de niveles inferiores aprovechen esta vulnerabilidad.

El complemento Custom fields shortcode para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del código abreviado cf del complemento en todas las versiones hasta la 0.1 incluida debido a una sanitización de entrada insuficiente y a un escape de salida en los metavalores de publicación personalizados proporcionados por el usuario. Esto hace posible que atacantes autenticados con permisos de nivel de colaborador y superiores inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

El complemento Download Manager para WordPress es vulnerable a la descarga no autorizada de archivos agregados a través del complemento en todas las versiones hasta la 3.2.84 incluida. Esto hace posible que atacantes no autenticados descarguen archivos agregados con el complemento (incluso cuando se publican de forma privada).

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

En FileCatalyst Direct 3.8.8 y versiones anteriores hasta 3.8.6, el servidor web no sanitiza adecuadamente los caracteres ilegales en una URL que luego se muestra en una página de error posterior. Un actor malicioso podría crear una URL que luego ejecutaría código arbitrario dentro de una etiqueta de script HTML.

Una validación de URL incorrecta provoca un path traversal en FileCatalyst Direct 3.8.8 y versiones anteriores, lo que permite que un payload codificado haga que el servidor web devuelva archivos ubicados fuera de la raíz web, lo que puede provocar una fuga de datos.

Un directory traversal dentro del 'ftpservlet' de FileCatalyst Workflow Web Portal permite cargar archivos fuera del directorio 'uploadtemp' previsto con una solicitud POST especialmente manipulada. En situaciones en las que un archivo se carga correctamente en DocumentRoot del portal web, se pueden utilizar archivos JSP especialmente manipulados para ejecutar código, incluidos los shells web.

El complemento Prime Slider – Addons For Elementor para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del atributo 'settings['title_tags']' del widget Mercury en todas las versiones hasta la 3.13.2 incluida debido a una sanitización de entrada insuficiente y la salida se escapa. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

El complemento Prime Slider – Addons For Elementor para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del atributo 'title_tags' del widget Rubix en todas las versiones hasta la 3.13.2 incluida debido a una sanitización de entrada y un escape de salida insuficientes. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: comprueba la coherencia del buzón/canal SMT Al recibir una interrupción de finalización, se accede al área de memoria compartida para recuperar el encabezado del mensaje al principio y luego, si el número de secuencia del mensaje identifica una transacción que aún está pendiente, el payload relacionado también se recupera. Cuando se agota el tiempo de espera de un comando SCMI, la propiedad del canal permanece en la plataforma hasta que finalmente se recibe una respuesta tardía y, como consecuencia, cualquier intento de transmisión adicional permanece pendiente, esperando que la plataforma abandone el canal. Una vez que se recibe esa respuesta tardía, la propiedad del canal se devuelve al agente y cualquier solicitud pendiente puede continuar y sobrescribir el área SMT de la respuesta tardía recién entregada; luego comienza la espera de la respuesta a la nueva solicitud. Se ha observado que la IRQ espuria relacionada con la respuesta tardía puede asociarse erróneamente con la solicitud recién puesta en cola: cuando eso sucede, el procedimiento de búsqueda en curso de la pila SCMI se ve engañado por el hecho de que el encabezado del mensaje ahora presente en el área SMT es relacionado con la nueva transacción pendiente, aunque la respuesta real aún no ha llegado. Esta condición de ejecución en el canal A2P se puede detectar observando los bits de estado del canal: una respuesta genuina de la plataforma habrá configurado el bit libre del canal antes de activar la IRQ de finalización. Agregue una verificación de coherencia para validar dicha condición en el ISR A2P.

Las versiones de JFrog Artifactory inferiores a 7.77.7 son vulnerables a Cross Site Scripting basadas en DOM debido a un manejo inadecuado del mecanismo de anulación de importación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: arreglar RELEASE_LOCKOWNER La prueba en so_count en nfsd4_release_lockowner() no tiene sentido y es dañina. Vuelva a usar check_for_locks(), cambiándolo para no dormir. Primero: dañino. Como se documenta en el comentario de kdoc para nfsd4_release_lockowner(), la prueba en so_count puede devolver transitoriamente un falso positivo, lo que resulta en una devolución de NFS4ERR_LOCKS_HELD cuando en realidad no se mantienen bloqueos. Esto es claramente una violación del protocolo y con el cliente NFS de Linux puede provocar un comportamiento incorrecto. Si se envía RELEASE_LOCKOWNER mientras algún otro subproceso todavía está procesando una solicitud de LOCK que falló porque, en el momento en que se recibió esa solicitud, el propietario determinado tenía un bloqueo en conflicto, entonces el subproceso nfsd que procesa esa solicitud de LOCK puede contener una referencia (conflock) a el propietario del bloqueo que hace que nfsd4_release_lockowner() devuelva un error incorrecto. El cliente NFS de Linux ignora ese error NFS4ERR_LOCKS_HELD porque nunca envía NFS4_RELEASE_LOCKOWNER sin liberar primero ningún bloqueo, por lo que sabe que el error es imposible. Se supone que el propietario de la cerradura fue liberado, por lo que puede utilizar el mismo identificador de propietario de la cerradura en alguna solicitud de bloqueo posterior. Cuando reutiliza un identificador de propietario de bloqueo para el cual falló una RELEASE anterior, naturalmente usará un lock_seqid de cero. Sin embargo, el servidor, que no liberó al propietario del bloqueo, esperará un lock_seqid mayor y, por lo tanto, responderá con NFS4ERR_BAD_SEQID. Claramente es perjudicial permitir un falso positivo, lo que permite la prueba so_count. La prueba es una tontería porque... bueno... no significa nada. so_count es la suma de tres recuentos diferentes. 1/ el conjunto de estados enumerados en so_stateids 2/ el conjunto de bloqueos vfs activos propiedad de cualquiera de esos estados 3/ varios recuentos transitorios, como bloqueos en conflicto. Cuando se prueba con '2', queda claro que una de ellas es la referencia transitoria obtenida por find_lockowner_str_locked(). No está claro cuál se espera que sea el otro. En la práctica, el recuento suele ser 2 porque hay precisamente un estado en so_stateids. Si hubiera más, esto fracasaría. En mis pruebas veo dos circunstancias en las que se llama a RELEASE_LOCKOWNER. En un caso, se llama a CLOSE antes de RELEASE_LOCKOWNER. Eso da como resultado que se eliminen todos los estados de bloqueo y, por lo tanto, se descarte el propietario de la cerradura (se elimina cuando no hay más referencias, lo que generalmente sucede cuando se descarta el estado de bloqueo). Cuando nfsd4_release_lockowner() descubre que el propietario del bloqueo no existe, devuelve éxito. El otro caso muestra un so_count de '2' y precisamente un estado listado en so_stateid. Parece que el cliente Linux utiliza un propietario de bloqueo independiente para cada archivo, lo que da como resultado un estado de bloqueo por propietario de bloqueo, por lo que esta prueba en '2' es segura. Para otro cliente puede que no sea seguro. Entonces, este parche cambia check_for_locks() para usar el (nuevo) find_any_file_locked() para que no tome una referencia en nfs4_file y así nunca llame a nfsd_file_put(), y por lo tanto nunca duerma. Con esta verificación, es seguro restaurar el uso de check_for_locks() en lugar de probar so_count con el misterioso '2'.