Vulnerabilities

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.

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.

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.

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 /> 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 /> 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]

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.

A security flaw has been discovered in NousResearch hermes-agent up to 0.15.2. The affected element is the function shell.exec of the file tui_gateway/server.py. The manipulation results in protection mechanism failure. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

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.

HestiaCP panel cronjob feature is affected by a broken access control vulnerability. Low privilege users can modify the panel cronjob to execute scripts HestiaCP management scripts with passwordless sudo. This could result in the takeover of administrator users in the application and the underlying webserver.

A weakness has been identified in NousResearch hermes-agent up to 2026.4.30. The impacted element is the function AIAgent.run_conversation of the file run_agent.py of the component HTTP API. This manipulation of the argument todos causes denial of service. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was identified in omec-project amf up to 2.0.2/2.1.1. Impacted is an unknown function of the file /go/src/amf/ngap/handler.go of the component NGSetupRequest Handler. The manipulation leads to denial of service. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. The identifier of the patch is 34bc6724acc97dba1f8691e586da95b042cb612d. To fix this issue, it is recommended to deploy a patch.