Vulnerabilities

A vulnerability has been found in ForceInjection AI-fundermentals 2.0/3.0. Affected by this vulnerability is the function get_conversation_history of the file 08_agentic_system/memory/langchain/code/smart_customer_service.py of the component Memory Recall Handler. The manipulation leads to use of weak hash. Remote exploitation of the attack is possible. A high degree of complexity is needed for the attack. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is f57277fdd9ba373ace72d83c272023ec67f720d6. It is suggested to install a patch to address this issue. The project confirms (translated from Chinese): "We now require session ownership verification in methods such as `username`, `sessionowner`, etc., and we've chat()changed the generation of `sessionowner` to include verified user identity and security context metadata."

In Trail of Bits fickling versions up to and including 0.1.11, the UnsafeImportsML analysis pass unconditionally calls AnalysisContext.shorten_code(node) on every import node it inspects, regardless of whether the import is flagged as unsafe. This call registers the shortened code representation in the shared AnalysisContext.reported_shortened_code set. When the MLAllowlist analysis pass subsequently runs, it calls the same shorten_code() method, receives already_reported=True for every import, and executes a continue statement that skips its allowlist check entirely. This renders MLAllowlist dead code for all imports — it never evaluates whether an import is in the ML allowlist or not. The MLAllowlist pass was designed to catch imports of modules outside the known-safe ML ecosystem (torch, numpy, transformers, etc.) that slip past the UnsafeImports denylist. With MLAllowlist inoperative, any standard library module not in the UNSAFE_IMPORTS denylist can be invoked via pickle deserialization while fickling's check_safety() returns LIKELY_SAFE. The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate, meaning a LIKELY_SAFE verdict causes the payload to be deserialized and executed. The root cause is shared mutable state between independently-correct analysis passes — UnsafeImportsML works as designed in isolation, MLAllowlist works as designed in isolation, but the shared reported_shortened_code set causes UnsafeImportsML to poison MLAllowlist's deduplication logic.

A flaw has been found in RT-Thread up to 5.2.2. Affected is the function read/write/sys_ioctl of the file components/lwp/lwp_syscall.c of the component Parameter Handler. Executing a manipulation can lead to divide by zero. The attack may be launched remotely. The exploit has been published and may be used. The pull request to fix this issue awaits acceptance.

Trail of Bits fickling versions up to and including 0.1.10 do not include the Python standard library modules _posixsubprocess, site, and atexit in the UNSAFE_IMPORTS denylist (fickle.py). Because these modules are absent from the denylist, fickling's check_safety() function returns LIKELY_SAFE with zero findings for pickle payloads that invoke dangerous functions including _posixsubprocess.fork_exec (C-level process spawner capable of executing arbitrary binaries), site.execsitecustomize (executes arbitrary site customization code), and atexit._run_exitfuncs (triggers all registered exit handler callbacks). The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate; a LIKELY_SAFE verdict causes the payload to be deserialized and executed. This shares the same root cause as CVE-2026-22607 (cProfile), CVE-2025-67748 (pty), and CVE-2025-67747 (marshal/types). OvertlyBadEvals does not flag these modules because they are standard library imports. UnsafeImports does not flag them because they are not in the denylist. The UnusedVariables heuristic is defeated by the SETITEMS opcode pattern.

In multi-tenanted deployments, the application consent management mechanism fails to correctly isolate consent scopes between tenants. Consent granted by a user for a specific SaaS application within one tenant can be incorrectly applied to SaaS applications with the same name in other tenants, leading to unintended cross-tenant consent sharing.<br /> <br /> This vulnerability may result in the exposure of user data across tenants, enabling SaaS applications in different tenants to access and modify information without explicit user authorization. This can lead to unauthorized data access and privacy violations. This vulnerability has no impact if the deployment does not support multi-tenancy.

A security vulnerability has been detected in NousResearch hermes-agent up to 0.15.2. This affects the function DiscordAdapter._is_allowed_user of the file gateway/platforms/discord.py of the component Discord Platform Integration. Such manipulation leads to improper authentication. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was detected in NousResearch hermes-agent up to 2026.5.16. This impacts the function extract_media of the file gateway/platforms/base.py of the component Live Webhook Endpoint. Performing a manipulation results in path traversal. The attack may be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Set gc_in_progress to true in unix_gc().<br /> <br /> Igor Ushakov reported that unix_gc() could run with gc_in_progress<br /> being false if the work is scheduled while running:<br /> <br /> Thread 1 Thread 2 Thread 3<br /> -------- -------- --------<br /> unix_schedule_gc() unix_schedule_gc()<br /> `- if (!gc_in_progress) `- if (!gc_in_progress)<br /> |- gc_in_progress = true |<br /> `- queue_work() |<br /> unix_gc()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: account for fraggap on the paged allocation path<br /> <br /> In __ip6_append_data(), when the paged-allocation branch is taken<br /> (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are<br /> computed as<br /> <br /> alloclen = fragheaderlen + transhdrlen;<br /> pagedlen = datalen - transhdrlen;<br /> <br /> datalen already includes fraggap (datalen = length + fraggap). When<br /> fraggap is non-zero, this is not the first skb and transhdrlen is zero.<br /> The fraggap bytes carried over from the previous skb are copied just past<br /> the fragment headers in the new skb&amp;#39;s linear area. The linear area is<br /> therefore undersized by fraggap bytes while pagedlen is overstated by the<br /> same amount, and the copy writes past skb-&gt;end into the trailing<br /> skb_shared_info.<br /> <br /> An unprivileged user can trigger this via a UDPv6 socket using<br /> MSG_MORE together with MSG_SPLICE_PAGES.<br /> <br /> The bad accounting was introduced by commit 773ba4fe9104 ("ipv6:<br /> avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix<br /> __ip6_append_data()&amp;#39;s handling of MSG_SPLICE_PAGES"), the negative<br /> copy value caused -EINVAL to be returned. That later commit allowed<br /> MSG_SPLICE_PAGES to proceed in this case, making the corruption<br /> triggerable.<br /> <br /> The non-paged branch sets alloclen to fraglen, which already accounts<br /> for fraggap because datalen does. Bring the paged branch in line by<br /> adding fraggap to alloclen and subtracting it from pagedlen.<br /> <br /> After this adjustment, copy no longer collapses to -fraggap on the<br /> paged path, so remove the stale comment describing that old arithmetic.<br /> Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES<br /> case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix shadow paging use-after-free due to unexpected role<br /> <br /> Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due<br /> to unexpected GFN") fixed a shadow paging mismatch between stored and<br /> computed GFNs; the bug could be triggered by changing a PDE mapping from<br /> outside the guest, and then deleting a memslot. The rmap_remove()<br /> call would miss entries created after the PDE change because the GFN<br /> of the leaf SPTE does not match the GFN of the struct kvm_mmu_page.<br /> <br /> A similar hole however remains if the modified PDE points to a non-leaf<br /> page. In this case the gfn can be made to match, but the role does not<br /> match: the original large 2MB page creates a kvm_mmu_page with direct=1,<br /> while the new 4KB needs a kvm_mmu_page with direct=0. However,<br /> kvm_mmu_get_child_sp() does not compare the role, and therefore reuses<br /> the page.<br /> <br /> The next step is installing a leaf (4KB) SPTE on the new path which<br /> records an rmap entry under the gfn resolved by the walk. But when<br /> that child is zapped its parent kvm_mmu_page has direct=1 and<br /> kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as<br /> sp-&gt;gfn + index instead of using sp-&gt;shadowed_translation[] (or sp-&gt;gfns[]<br /> in older kernels). It therefore fails to remove the recorded entry.<br /> <br /> When the memslot is dropped the shadow page is freed but the rmap<br /> entry survives, as in the scenario that was already fixed. Code that<br /> later walks that gfn (dirty logging, MMU notifier invalidation, and<br /> so on) dereferences an sptep that lies in the freed page, causing the<br /> use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use<br /> <br /> As per the GHCB spec, when using GHCB v2+ require the software scratch area<br /> to reside in the GHCB&amp;#39;s shared buffer. Note, things like Page State Change<br /> (PSC) requests _rely_ on this behavior, as the guest can&amp;#39;t provide a length<br /> when making the request, i.e. the size of the guest payload is bounded by<br /> the size of the shared buffer.<br /> <br /> Failure to force usage of the GHCB, and a slew of other flaws, lets a<br /> malicious SNP guest corrupt host kernel heap memory, and leak host heap<br /> layout information.<br /> <br /> setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2),<br /> where exit_info_2 is guest-controlled. With exit_info_2=24, this yields<br /> a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer<br /> holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only<br /> entries[0] and entries[1] are in-bounds.<br /> <br /> snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253)<br /> but NOT against the actual buffer size:<br /> <br /> idx_end = hdr-&gt;end_entry;<br /> <br /> if (idx_end &gt;= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer<br /> snp_complete_psc(svm, ...);<br /> return 1;<br /> }<br /> <br /> for (idx = idx_start; idx = 2<br /> <br /> The guest sets end_entry=10+, causing the host to iterate entries[2+]<br /> which are OOB into adjacent slab objects. For each OOB entry:<br /> <br /> - The host reads 8 bytes (OOB READ / info leak oracle)<br /> - If the data passes PSC validation, __snp_complete_one_psc() writes<br /> cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806)<br /> - If validation fails, the error response reveals whether adjacent<br /> memory is zero vs non-zero (information disclosure to guest)<br /> <br /> The guest controls allocation size (exit_info_2), entry range<br /> (cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly<br /> hit different slab positions.<br /> <br /> By exploiting the variety of bugs, a malicious SEV-SNP guest can:<br /> - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure)<br /> - OOB write cur_page bits into adjacent objects (heap corruption)<br /> - Trigger use-after-free conditions across VMGEXITs<br /> <br /> E.g. with KASAN enabled, a single insmod of the PoC guest module<br /> produces 73 KASAN reports:<br /> <br /> BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890<br /> Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199<br /> <br /> BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890<br /> Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199<br /> <br /> The buggy address belongs to the object at ffff888XXXXXXXXX<br /> which belongs to the cache kmalloc-cg-32 of size 32<br /> The buggy address is located N bytes to the right of<br /> allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)<br /> <br /> Breakdown:<br /> 62 slab-out-of-bounds (reads + writes past allocation)<br /> 7 slab-use-after-free<br /> 4 use-after-free<br /> <br /> All credit to Stan for the wonderful description and reproducer!<br /> <br /> [sean: write changelog]

myVesta is affected by an authenticated remote code execution vulnerability. Low privileged users can insert arbitrary commands as a part of the v_ftp_user parameter when deleting FTP usernames. This could result in the execution of commands as the admin user or takevoer of the admin user in myVesta.