Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix block_group_tree dirty_list corruption<br /> <br /> When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the<br /> block group tree to the switch_commits list before calling<br /> switch_commit_roots, as we do for the tree root and the chunk root.<br /> However, the block group tree uses normal root dirty tracking and in any<br /> transaction that does an allocation and dirties a block group, the block<br /> group root will already be linked to a list by the dirty_list field and<br /> this use of list_add_tail() is invalid and corrupts the prev/next<br /> members of block_group_root-&gt;dirty_list.<br /> <br /> This is apparent on a subsequent list_del on the prev if we enable<br /> CONFIG_DEBUG_LIST:<br /> <br /> [32.1571] ------------[ cut here ]------------<br /> [32.1572] list_del corruption. next-&gt;prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538)<br /> [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607<br /> [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none)<br /> [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014<br /> [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120<br /> [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202<br /> [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538<br /> [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00<br /> [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff<br /> [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538<br /> [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538<br /> [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000<br /> [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0<br /> [32.1609] Call Trace:<br /> [32.1610] <br /> [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs]<br /> [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs]<br /> [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs]<br /> [32.1621] __iterate_supers+0xe8/0x190<br /> [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10<br /> [32.1623] ksys_sync+0x63/0xb0<br /> [32.1624] __do_sys_sync+0xe/0x20<br /> [32.1625] do_syscall_64+0x73/0x450<br /> [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [32.1627] RIP: 0033:0x7f0c28d05d2b<br /> [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2<br /> [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b<br /> [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d<br /> [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000<br /> [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80<br /> [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034<br /> [32.1643] <br /> [32.1644] irq event stamp: 0<br /> [32.1644] hardirqs last enabled at (0): [] 0x0<br /> [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260<br /> [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260<br /> [32.1650] softirqs last disabled at (0): [] 0x0<br /> [32.1652] ---[ end trace 0000000000000000 ]---<br /> <br /> Furthermore, this list corruption eventually (when we happen to add a<br /> new block group) results in getting the switch_commits and<br /> dirty_cowonly_roots lists mixed up and attempting to call update_root<br /> on the tree root which can&amp;#39;t be found in the tree root, resulting in a<br /> transaction abort:<br /> <br /> [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1<br /> [87.8272] ------------[ cut here ]------------<br /> [87.8274] BTRFS: Transaction aborted (error -117)<br /> [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703<br /> [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none)<br /> [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 0<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath12k: limpiar el mapeo de enlace obsoleto de ahvif-&gt;links_map<br /> <br /> Cuando un arvif es inicializado en modo STA no-AP pero la preparación de la conexión MLO falla antes de que el arvif sea creado (arvif-&gt;is_created permanece falso), la ruta de error intenta eliminar todos los enlaces. Sin embargo, la eliminación de enlaces solo se ejecuta cuando arvif-&gt;is_created es verdadero. Como resultado, ahvif retiene una entrada obsoleta de arvif que está inicializado pero no creado.<br /> <br /> Cuando un nuevo arvif es inicializado con el mismo id de enlace, este mapeo obsoleto dispara el siguiente WARN_ON.<br /> <br /> ADVERTENCIA: drivers/net/wireless/ath/ath12k/mac.c:4271 en ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275<br /> <br /> Traza de llamada:<br /> ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P)<br /> drv_change_vif_links+0xbc/0x1a4 [mac80211]<br /> ieee80211_vif_update_links+0x54c/0x6a0 [mac80211]<br /> ieee80211_vif_set_links+0x40/0x70 [mac80211]<br /> ieee80211_prep_connection+0x84/0x450 [mac80211]<br /> ieee80211_mgd_auth+0x200/0x480 [mac80211]<br /> ieee80211_auth+0x14/0x20 [mac80211]<br /> cfg80211_mlme_auth+0x90/0xf0 [cfg80211]<br /> nl80211_authenticate+0x32c/0x380 [cfg80211]<br /> genl_family_rcv_msg_doit+0xc8/0x134<br /> <br /> Solucione este problema desasignando el vif de enlace y limpiando ahvif-&gt;links_map si arvif solo está inicializado pero no creado.<br /> <br /> Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeontx2-af: Solución a la caída del controlador PF con el arranque del kernel kexec<br /> <br /> Durante un reinicio kexec, el hardware no se apaga y enciende, por lo que el estado de AF del kernel antiguo puede persistir en el nuevo kernel. Cuando los controladores AF y PF se compilan como módulos, el controlador PF puede sondear antes de que AF reinicialice el hardware.<br /> <br /> El controlador PF trata la revisión del bloque RVUM como una indicación de que la inicialización de AF está completa. Si este valor se deja sin borrar al apagar, PF puede asumir incorrectamente que AF está listo y acceder a un estado de hardware obsoleto, lo que lleva a una caída.<br /> <br /> Borrar la revisión del bloque RVUM durante el apagado de AF para evitar que PF detecte incorrectamente la disponibilidad de AF después de kexec.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> MIPS: Solución alternativa para el error de LLVM cuando gp se usa como variable de registro global<br /> <br /> En MIPS, __current_thread_info se define como una variable de registro global ubicada en $gp, y simplemente se le asigna una nueva dirección durante la reubicación del kernel.<br /> <br /> Esto, sin embargo, se rompe con LLVM, que siempre restaura $gp si encuentra que $gp ha sido sobrescrito de alguna forma, incluso cuando es intencionalmente a través de una variable de registro global. Esto va en contra de la documentación de GCC[1], que requiere que un registro guardado por la función llamada, utilizado como variable de registro global, no sea restaurado si ha sido sobrescrito.<br /> <br /> Como resultado, $gp continuará apuntando al kernel no reubicado después del epílogo de relocate_kernel(), lo que lleva a un fallo temprano en init_idle,<br /> <br /> [ 0.000000] CPU 0 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90<br /> [ 0.000000] Oops[#1]:<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY<br /> [ 0.000000] Tainted: [W]=WARN<br /> [ 0.000000] Nombre del hardware: loongson,loongson64v-4core-virtio<br /> [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000<br /> [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240<br /> [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001<br /> [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002<br /> [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80<br /> [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80<br /> [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90<br /> [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90<br /> [ 0.000000] Hi : 0000000000000000<br /> [ 0.000000] Lo : 0000000000000000<br /> [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270<br /> [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270<br /> [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL<br /> [ 0.000000] Cause : 00000008 (ExcCode 02)<br /> [ 0.000000] BadVA : 0000000000000000<br /> [ 0.000000] PrId : 00006305 (ICT Loongson-3)<br /> [ 0.000000] Proceso swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)<br /> [ 0.000000] Pila : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528<br /> [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000<br /> [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258<br /> [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98<br /> [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002<br /> [ 0.000000] ...<br /> [ 0.000000] Rastro de llamadas:<br /> [ 0.000000] [] init_idle+0x130/0x270<br /> [ 0.000000] [] sched_init+0x5c8/0x6c0<br /> [ 0.000000] [] start_kernel+0x27c/0x7a8<br /> <br /> Este error ha sido reportado a LLVM[2] y afecta a las versiones desde (al menos) la 18 hasta la 21. Evitemos esto usando ensamblador en línea para asignar $gp antes de que una solución esté ampliamente disponible.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> regulator: core: corregir el bloqueo en la ruta de error de regulator_resolve_supply()<br /> <br /> Si la habilitación tardía de un regulador de suministro falla en regulator_resolve_supply(), el código actualmente activa una advertencia de lockdep:<br /> <br /> ADVERTENCIA: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596<br /> ...<br /> Traza de llamada:<br /> _regulator_put+0x80/0xa0 (P)<br /> regulator_resolve_supply+0x7cc/0xbe0<br /> regulator_register_resolve_supply+0x28/0xb8<br /> <br /> ya que el regulator_list_mutex debe mantenerse al llamar a _regulator_put().<br /> <br /> Para resolver esto, simplemente cambie a usar regulator_put().<br /> <br /> Ya que estamos en ello, también deberíamos asegurarnos de que no ocurra ningún acceso concurrente a nuestro rdev mientras borramos el puntero de suministro. Añada un bloqueo apropiado para asegurar eso.<br /> <br /> Aunque el código en cuestión será eliminado por completo en un commit de seguimiento, creo que sigue siendo beneficioso tener esto corregido antes de la eliminación para futuras referencias.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nft_inner: Corregir la desincronización de inner_thoff de IPv6<br /> <br /> En nft_inner_parse_l2l3(), al procesar paquetes IPv6 internos, ipv6_find_hdr() calcula correctamente el desplazamiento del encabezado de transporte atravesando todos los encabezados de extensión, pero el resultado es inmediatamente sobrescrito con nhoff + sizeof(_ip6h) (40 bytes), lo que solo tiene en cuenta el encabezado base de IPv6. Esto crea una desincronización entre inner_thoff (incorrecto - apunta al inicio del encabezado de extensión) y l4proto (correcto - p. ej., IPPROTO_TCP), lo que permite la falsificación de encabezados de transporte y una posible omisión del cortafuegos. Este problema afecta a versiones estables a partir de Linux 6.2.<br /> <br /> A modo de comparación, la ruta IPv6 normal (no interna) conserva correctamente el resultado de ipv6_find_hdr(). Eliminar la sobrescritura incorrecta asegura que el desplazamiento del encabezado de transporte calculado por ipv6_find_hdr() se preserve, corrigiendo así la desincronización.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amd/display: Corrección del manejo de dc_link NULL en la inicialización de HPD<br /> <br /> amdgpu_dm_hpd_init() puede encontrar conectores sin un dc_link válido.<br /> <br /> El código ya verifica dc_link para la decisión de sondeo, pero luego lo desreferencia incondicionalmente al configurar las interrupciones HPD.<br /> <br /> Asigne dc_link con antelación y omita los conectores donde sea NULL.<br /> <br /> Soluciona lo siguiente:<br /> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()<br /> error: previamente asumimos que &amp;#39;dc_link&amp;#39; podría ser nulo (ver línea 931)<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c<br /> 923 /*<br /> 924 * Los conectores analógicos pueden ser conectados en caliente a diferencia de otros tipos de conectores<br /> 925 * que no soportan HPD. Solo sondee los conectores analógicos.<br /> 926 */<br /> 927 use_polling |=<br /> 928 amdgpu_dm_connector-&gt;dc_link &amp;&amp;<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ El parche añade esta verificación de NULL pero ojalá pueda ser eliminada<br /> <br /> 929 dc_connector_supports_analog(amdgpu_dm_connector-&gt;dc_link-&gt;link_id.id);<br /> 930<br /> 931 dc_link = amdgpu_dm_connector-&gt;dc_link;<br /> <br /> dc_link asignado aquí.<br /> <br /> 932<br /> 933 /*<br /> 934 * Obtenga una referencia de irq del controlador base para las interrupciones hpd durante la vida útil<br /> 935 * de dm. Tenga en cuenta que solo los tipos de interrupción hpd se registran con<br /> 936 * el controlador base; los tipos hpd_rx no lo están. En otras palabras, amdgpu_irq_get/put en<br /> 937 * hpd_rx no está disponible. DM actualmente controla hpd_rx<br /> 938 * explícitamente con dc_interrupt_set()<br /> 939 */<br /> --&gt; 940 if (dc_link-&gt;irq_source_hpd != DC_IRQ_SOURCE_INVALID) {<br /> ^^^^^^^^^^^^^^^^^^^^^^^ Si es NULL, entonces tenemos problemas porque lo desreferenciamos aquí.<br /> <br /> 941 irq_type = dc_link-&gt;irq_source_hpd - DC_IRQ_SOURCE_HPD1;<br /> 942 /*<br /> 943 * PENDIENTE: Hay una discrepancia entre mode_info.num_hpd<br /> 944 * y lo que la BIOS informa como el número de conectores con hpd

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> power: supply: pm8916_lbc: Corrección de uso después de liberación para extcon en el gestor IRQ<br /> <br /> Usar la variante &amp;#39;devm_&amp;#39; para solicitar IRQ _antes_ de la variante &amp;#39;devm_&amp;#39; para asignar/registrar el manejador &amp;#39;extcon&amp;#39;, significa que el manejador &amp;#39;extcon&amp;#39; será desasignado/dado de baja _antes_ del gestor de interrupciones (ya que &amp;#39;devm_&amp;#39; desasigna naturalmente en orden inverso de asignación). Esto significa que durante la eliminación, hay una condición de carrera donde una interrupción puede dispararse justo _después_ de que el manejador &amp;#39;extcon&amp;#39; haya sido liberado, pero justo _antes_ de que se haya ejecutado la correspondiente anulación de registro del gestor IRQ.<br /> <br /> Esto llevará a que el gestor IRQ llame a &amp;#39;extcon_set_state_sync()&amp;#39; con un manejador &amp;#39;extcon&amp;#39; liberado. Lo que usualmente bloquea el sistema o de otra manera corrompe silenciosamente la memoria...<br /> <br /> Corrige este uso después de liberación propenso a condiciones de carrera asegurándose de que la IRQ sea solicitada _después_ del registro del manejador &amp;#39;extcon&amp;#39;.

En el kernel de Linux, la siguiente vulnerabilidad se ha resuelto:<br /> <br /> clk: qcom: gfx3d: añadir padre al mapa de solicitud de padre<br /> <br /> Después del commit d228ece36345 (&amp;#39;clk: divider: eliminar round_rate() en favor<br /> de determine_rate()&amp;#39;) la determinación de la frecuencia del reloj GFX3D falla, porque el<br /> mapa de padre pasado no proporciona el reloj best_parent_hw esperado<br /> (con la ruta roundd_rate antes del commit problemático, el<br /> best_parent_hw era ignorado).<br /> <br /> Establecer el campo en parent_req además de establecerlo en req,<br /> solucionando la falla.<br /> <br /> clk_hw_round_rate (drivers/clk/clk.c:1764) (P)<br /> clk_divider_bestdiv (drivers/clk/clk-divider.c:336)<br /> divider_determine_rate (drivers/clk/clk-divider.c:358)<br /> clk_alpha_pll_postdiv_determine_rate (drivers/clk/qcom/clk-alpha-pll.c:1275)<br /> clk_core_determine_round_nolock (drivers/clk/clk.c:1606)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1701)<br /> __clk_determine_rate (drivers/clk/clk.c:1741)<br /> clk_gfx3d_determine_rate (drivers/clk/qcom/clk-rcg2.c:1268)<br /> clk_core_determine_round_nolock (drivers/clk/clk.c:1606)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1701)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1710)<br /> clk_round_rate (drivers/clk/clk.c:1804)<br /> dev_pm_opp_set_rate (drivers/opp/core.c:1440 (discriminator 1))<br /> msm_devfreq_target (drivers/gpu/drm/msm/msm_gpu_devfreq.c:51)<br /> devfreq_set_target (drivers/devfreq/devfreq.c:360)<br /> devfreq_update_target (drivers/devfreq/devfreq.c:426)<br /> devfreq_monitor (drivers/devfreq/devfreq.c:458)<br /> process_one_work (arch/arm64/include/asm/jump_label.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284)<br /> worker_thread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2))<br /> kthread (kernel/kthread.c:467)<br /> ret_from_fork (arch/arm64/kernel/entry.S:861)

OP-TEE es un Entorno de Ejecución Confiable (TEE) diseñado como compañero de un kernel de Linux no seguro que se ejecuta en núcleos Arm; Cortex-A utilizando la tecnología TrustZone. A partir de la versión 3.16.0 y antes de la 4.11.0, existe una condición de carrera de uso después de liberación (UAF) en la lógica de desmantelamiento de memoria compartida de FF-A dentro de los flujos SPMC/SP de OP-TEE. Esto solo aplica cuando OP-TEE está configurado como un SPMC para SPs S-EL0, es decir, con &amp;#39;CFG_SECURE_PARTITION=y&amp;#39;. La función &amp;#39;sp_mem_remove()&amp;#39;, responsable de liberar entradas en &amp;#39;smem-&gt;receivers&amp;#39; y &amp;#39;smem-&gt;regions&amp;#39;, no logra adquirir el &amp;#39;sp_mem_lock&amp;#39; global antes de realizar las operaciones de &amp;#39;free()&amp;#39;. Concurrentemente, otras rutas de código, como &amp;#39;sp_mem_get_receiver()&amp;#39;, iteran sobre estas mismas listas sin mantener un bloqueo, o, como &amp;#39;sp_mem_is_shared()&amp;#39;, iteran mientras mantienen el bloqueo pero no están serializadas contra el &amp;#39;free()&amp;#39; desprotegido en &amp;#39;sp_mem_remove()&amp;#39;. Esto crea una condición de carrera entre hilos donde un hilo que itera la lista puede adquirir un puntero a una entrada (p. ej., &amp;#39;struct sp_mem_map_region&amp;#39; o &amp;#39;struct sp_mem_receiver&amp;#39;), y luego otro hilo llama a &amp;#39;sp_mem_remove()&amp;#39;, liberando el objeto. Cuando el primer hilo se reanuda y desreferencia el puntero, resulta en una vulnerabilidad de uso después de liberación. La versión 4.11.0 corrige el problema.

Mercusys AC12G (EU) V1 con firmware AC12G(EU)_V1_200909 responde a consultas TXT CHAOS de version.bind, divulgando la versión del software del resolvedor DNS (unbound 1.22.0), facilitando ataques dirigidos contra vulnerabilidades conocidas.

Una vulnerabilidad de Cross Site Scripting existe en la función &amp;#39;Preview&amp;#39; de la interfaz web de Kimi AI v1.0. La aplicación no logra sanitizar o codificar adecuadamente las cargas útiles HTML/JavaScript generadas por el modelo de IA. Cuando un usuario cambia a la pestaña &amp;#39;Preview&amp;#39; para ver código generado por IA, la carga útil maliciosa se renderiza directamente en el DOM, lo que lleva a la ejecución arbitraria de JavaScript en la sesión del navegador de la víctima.