Vulnerabilities

A vulnerability was found in kirilkirkov Ecommerce-CodeIgniter-Bootstrap up to 95dfa8cebbb87ab46ae450643a07241274a74dce. Affected by this issue is the function setReferrer of the file application/core/MY_Controller.php of the component Trusted Backend Interface. The manipulation of the argument href results in open redirect. The attack can be executed remotely. The exploit has been made public and could be used. This product implements a rolling release for ongoing delivery, which means version information for affected or updated releases is unavailable. The patch is identified as 213babdbaa949e94557246414db0130e01394517. A patch should be applied to remediate this issue.

A vulnerability was determined in kirilkirkov Ecommerce-CodeIgniter-Bootstrap up to 49b20f53de2b7ec34e920b11c863f1491d911a04. This affects an unknown part of the file /index.php/api/product/set of the component Hidden REST API Endpoint. This manipulation of the argument title/description causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. Patch name: d9785f995da77bdc62fb2d34bad5f7a162c9ad23. To fix this issue, it is recommended to deploy a patch.

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.