Vulnerabilidades

OpenClaw versión 2026.2.22-2 anterior a 2026.2.23, la validación de tools.exec.safeBins para el comando sort no valida correctamente las abreviaturas de opciones largas de GNU, lo que permite a los atacantes eludir las comprobaciones de banderas denegadas mediante opciones abreviadas. Los atacantes remotos pueden ejecutar comandos sort con opciones largas abreviadas para omitir los requisitos de aprobación en modo de lista de permitidos.

Las versiones de OpenClaw anteriores a 2026.2.14 contienen una vulnerabilidad de salto de ruta en apply_patch que permite a los atacantes escribir o eliminar archivos fuera del directorio de espacio de trabajo configurado. Cuando apply_patch está habilitado sin contención de sandbox del sistema de archivos, los atacantes pueden explotar rutas manipuladas, incluyendo secuencias de salto de directorio o rutas absolutas, para escapar de los límites del espacio de trabajo y modificar archivos arbitrarios.

Una vulnerabilidad fue determinada en itsourcecode University Management System 1.0. Esta vulnerabilidad afecta código desconocido del archivo /att_add.php. Esta manipulación del argumento Name causa inyección SQL. El ataque puede ser iniciado remotamente. El exploit ha sido divulgado públicamente y puede ser utilizado.

Se encontró una vulnerabilidad en H3C ACG1000-AK230 hasta 20260227. Esto afecta una parte desconocida del archivo /webui/?aaa_portal_auth_local_submit. La manipulación del argumento suffix resulta en inyección de comandos. El ataque puede ser lanzado de forma remota. El exploit ha sido hecho público y podría ser usado. El proveedor fue contactado con antelación sobre esta divulgación pero no respondió de ninguna manera.

El plugin Name Directory para WordPress es vulnerable a cross-site scripting almacenado a través del parámetro 'name_directory_name' en todas las versiones hasta la 1.32.1, inclusive, debido a una sanitización de entrada y un escape de salida insuficientes. Esto hace posible que atacantes no autenticados inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada. La vulnerabilidad fue parcialmente parcheada en las versiones 1.30.3 y 1.32.1.

Cuando se utiliza un token portador OAuth2 para una transferencia HTTP(S), y esa transferencia realiza una redirección a una segunda URL, curl podría filtrar ese token al segundo nombre de host bajo algunas circunstancias.<br /> <br /> Si el nombre de host al que se redirige la primera solicitud tiene información en el archivo .netrc utilizado, con cualquiera de las palabras clave &amp;#39;machine&amp;#39; o &amp;#39;default&amp;#39;, curl pasaría el token portador establecido para el primer host también al segundo.

curl reutilizaría erróneamente una conexión proxy HTTP existente haciendo CONNECT a un servidor, incluso si la nueva solicitud utiliza credenciales diferentes para el proxy HTTP. El comportamiento adecuado es crear o usar una conexión separada.

Al hacer una segunda solicitud SMB al mismo host de nuevo, curl usaría erróneamente un puntero de datos apuntando a memoria ya liberada.

libcurl puede en algunas circunstancias reutilizar la conexión incorrecta cuando se le pide que realice una solicitud HTTP o HTTPS autenticada con Negotiate.<br /> <br /> libcurl cuenta con un grupo de conexiones recientes para que las solicitudes posteriores puedan reutilizar una conexión existente y evitar la sobrecarga.<br /> <br /> Al reutilizar una conexión, una serie de criterios deben cumplirse primero. Debido a un error lógico en el código, una solicitud emitida por una aplicación podría reutilizar erróneamente una conexión existente al mismo servidor que fue autenticado usando credenciales diferentes. Una razón subyacente es que Negotiate a veces autentica *conexiones* y no *solicitudes*, al contrario de cómo HTTP está diseñado para funcionar.<br /> <br /> Una aplicación que permite la autenticación Negotiate a un servidor (que responde queriendo Negotiate) con &amp;#39;user1:password1&amp;#39; y luego realiza otra operación al mismo servidor también usando Negotiate pero con &amp;#39;user2:password2&amp;#39; (mientras la conexión anterior sigue activa) - la segunda solicitud reutilizó erróneamente la misma conexión y dado que luego ve que la negociación de Negotiate ya está hecha, simplemente envía la solicitud a través de esa conexión pensando que usa las credenciales de user2 cuando de hecho sigue usando la conexión autenticada para user1...<br /> <br /> El conjunto de métodos de autenticación a usar se establece con &amp;#39;CURLOPT_HTTPAUTH&amp;#39;.<br /> <br /> Las aplicaciones pueden deshabilitar la reutilización de conexiones de libcurl y así mitigar este problema, usando una de las siguientes opciones de libcurl para alterar cómo las conexiones son o no son reutilizadas: &amp;#39;CURLOPT_FRESH_CONNECT&amp;#39;, &amp;#39;CURLOPT_MAXCONNECTS&amp;#39; y &amp;#39;CURLMOPT_MAX_HOST_CONNECTIONS&amp;#39; (si se usa la API curl_multi).

El plugin Gravity Forms para WordPress es vulnerable a cross-site scripting almacenado en todas las versiones hasta la 2.9.28.1, inclusive. Esto se debe a un fallo compuesto que implica una autorización faltante en el endpoint AJAX `create_from_template` (permitiendo a cualquier usuario autenticado crear formularios), saneamiento de entrada insuficiente (`sanitize_text_field()` conserva las comillas simples), y escape de salida faltante cuando el título del formulario se renderiza en el desplegable del Selector de Formularios (atributo `title` construido sin `esc_attr()`, y la utilidad JavaScript `saferHtml` solo escapa `&amp;amp;`, `&amp;lt;`, `&amp;gt;` pero no las comillas). Esto hace posible que atacantes autenticados, con acceso de nivel Suscriptor y superior, inyecten JavaScript arbitrario que se ejecuta cuando un Administrador busca en el desplegable del Selector de Formularios en el Editor de Formularios.

El núcleo de WordPress es vulnerable a acceso no autorizado en las versiones 6.9 a 6.9.1. La función de Notas (anotaciones de colaboración a nivel de bloque) se introdujo en WordPress 6.9 para permitir comentarios editoriales directamente en las publicaciones en el editor de bloques. Sin embargo, el método `create_item_permissions_check()` de la API REST en el controlador de comentarios no verificó que el usuario autenticado tuviera permiso `edit_post` en la publicación objetivo al crear una nota. Esto hace posible que atacantes autenticados con acceso de nivel de Suscriptor creen notas en cualquier publicación, incluyendo publicaciones creadas por otros usuarios, publicaciones privadas y publicaciones en cualquier estado.

El plugin Checkout Field Editor (Checkout Manager) para WooCommerce para WordPress es vulnerable a cross-site scripting almacenado a través de valores de campo personalizados de tipo radio y checkboxgroup enviados a través de la API de la tienda de pago por bloques de WooCommerce en todas las versiones hasta la 2.1.7, inclusive. Esto se debe al método `prepare_single_field_data()` en `class-thwcfd-block-order-data.php` que primero escapa los valores con `esc_html()` y luego revierte inmediatamente el escape con `html_entity_decode()` para los tipos de campo radio y checkboxgroup, combinado con una lista de permitidos `wp_kses()` permisiva en `get_allowed_html()` que permite explícitamente el elemento `` con el atributo gestor de eventos `onchange`. Esto hace posible que atacantes no autenticados inyecten scripts web arbitrarios a través del endpoint de pago de la API de la tienda que se ejecutan cuando un administrador ve la página de detalles del pedido.