Vulnerabilities

A vulnerability was found in mf-yang openclaw-cn up to 0.2.1. This affects the function clickViaPlaywright of the file src/browser/routes/agent.act.ts of the component Browser Control HTTP API. Performing a manipulation results in server-side request forgery. It is possible to initiate the attack remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was determined in perwendel spark up to 2.9.4. This vulnerability affects the function staticFiles.externalLocation of the file src/main/java/spark/resource/ExternalResourceHandler.jav of the component SparkJava. Executing a manipulation can lead to symlink following. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability has been found in mf-yang openclaw-cn up to 0.2.1. Affected by this issue is the function assertBrowserNavigationAllowed of the file src/browser/navigation-guard.ts of the component Scheme Handler. Such manipulation of the argument url leads to information disclosure. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle<br /> <br /> tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the<br /> defragmentation engine (e.g. act_ct on out-of-order fragments). When<br /> that happens the skb is no longer owned by the caller and must not be<br /> touched again.<br /> <br /> tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the<br /> switch and returned the skb to the caller as if classification had<br /> passed. The only qdisc that wires up qevents today is RED, via three call sites<br /> (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop)<br /> red_enqueue() was continuing to operate on an skb it no longer owns in this<br /> case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF.<br /> <br /> tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10<br /> tc filter add block 10 ... action ct<br /> <br /> (with ct defrag enabled and traffic that produces out-of-order<br /> fragments, e.g. a fragmented UDP stream)<br /> <br /> Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress<br /> and egress fast paths do: treat it as stolen and return NULL without<br /> touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be<br /> dropped/freed here, as it is no longer owned by us.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nexthop: Increase weight to u16<br /> <br /> In CLOS networks, as link failures occur at various points in the network,<br /> ECMP weights of the involved nodes are adjusted to compensate. With high<br /> fan-out of the involved nodes, and overall high number of nodes,<br /> a (non-)ECMP weight ratio that we would like to configure does not fit into<br /> 8 bits. Instead of, say, 255:254, we might like to configure something like<br /> 1000:999. For these deployments, the 8-bit weight may not be enough.<br /> <br /> To that end, in this patch increase the next hop weight from u8 to u16.<br /> <br /> Increasing the width of an integral type can be tricky, because while the<br /> code still compiles, the types may not check out anymore, and numerical<br /> errors come up. To prevent this, the conversion was done in two steps.<br /> First the type was changed from u8 to a single-member structure, which<br /> invalidated all uses of the field. This allowed going through them one by<br /> one and audit for type correctness. Then the structure was replaced with a<br /> vanilla u16 again. This should ensure that no place was missed.<br /> <br /> The UAPI for configuring nexthop group members is that an attribute<br /> NHA_GROUP carries an array of struct nexthop_grp entries:<br /> <br /> struct nexthop_grp {<br /> __u32 id; /* nexthop id - must exist */<br /> __u8 weight; /* weight of this nexthop */<br /> __u8 resvd1;<br /> __u16 resvd2;<br /> };<br /> <br /> The field resvd1 is currently validated and required to be zero. We can<br /> lift this requirement and carry high-order bits of the weight in the<br /> reserved field:<br /> <br /> struct nexthop_grp {<br /> __u32 id; /* nexthop id - must exist */<br /> __u8 weight; /* weight of this nexthop */<br /> __u8 weight_high;<br /> __u16 resvd2;<br /> };<br /> <br /> Keeping the fields split this way was chosen in case an existing userspace<br /> makes assumptions about the width of the weight field, and to sidestep any<br /> endianness issues.<br /> <br /> The weight field is currently encoded as the weight value minus one,<br /> because weight of 0 is invalid. This same trick is impossible for the new<br /> weight_high field, because zero must mean actual zero. With this in place:<br /> <br /> - Old userspace is guaranteed to carry weight_high of 0, therefore<br /> configuring 8-bit weights as appropriate. When dumping nexthops with<br /> 16-bit weight, it would only show the lower 8 bits. But configuring such<br /> nexthops implies existence of userspace aware of the extension in the<br /> first place.<br /> <br /> - New userspace talking to an old kernel will work as long as it only<br /> attempts to configure 8-bit weights, where the high-order bits are zero.<br /> Old kernel will bounce attempts at configuring &gt;8-bit weights.<br /> <br /> Renaming reserved fields as they are allocated for some purpose is commonly<br /> done in Linux. Whoever touches a reserved field is doing so at their own<br /> risk. nexthop_grp::resvd1 in particular is currently used by at least<br /> strace, however they carry an own copy of UAPI headers, and the conversion<br /> should be trivial. A helper is provided for decoding the weight out of the<br /> two fields. Forcing a conversion seems preferable to bending backwards and<br /> introducing anonymous unions or whatever.

datamodel-code-generator prior to version 0.70.0 contains a code injection vulnerability that allows attackers who control input schemas to achieve remote code execution by supplying a malicious customBasePath value containing embedded newlines and a dot-free Python expression. The crafted value is emitted verbatim into a generated &amp;#39;from ... import ...&amp;#39; statement without identifier validation, causing arbitrary Python code to execute when the generated module is imported.

A flaw has been found in nanocoai NanoClaw up to 2.0.64. Affected is the function handleAddMcpServer of the file src/modules/self-mod/request.ts of the component add_mcp_server. Executing a manipulation can lead to improper authorization. The attack may be launched remotely. The exploit has been published and may be used. This patch is called e5b928783d5c485637565eb07d2967922dfbf8d8. A patch should be applied to remediate this issue.

A vulnerability was detected in nanocoai NanoClaw up to 2.0.64. This impacts the function createChatSdkBridge.setup of the file src/channels/chat-sdk-bridge.ts of the component MCP Server Approval. Performing a manipulation results in improper authorization. The attack needs to be approached locally. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

The Fluent Forms Pro Add On Pack plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 6.2.6 via deserialization of untrusted input. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject a PHP Object. The additional presence of a POP chain allows attackers to change user passwords and potentially take over administrator accounts. Note: This can only be exploited if user update integration is enabled and a user meta field is mapped.

A vulnerability was detected in NousResearch hermes-agent 2026.6.5. Affected by this vulnerability is an unknown functionality of the file hermes-agent/plugins/platforms/simplex/adapter.py of the component SimpleX Gateway Authorization. The manipulation of the argument contactId results in improper access controls. The attack may be launched remotely. A high complexity level is associated with this attack. The exploitation appears to be difficult. The exploit is now public and may be used. The patch is identified as 490c486ff65b766d9de0fe0e6f26e1778aaa8fb3. Applying a patch is advised to resolve this issue.

In Zephyr&amp;#39;s userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock.<br /> <br /> On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx.<br /> <br /> The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object&amp;#39;s perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &amp;=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool.<br /> <br /> The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).

SiYuan before v3.7.2 contains a missing authorization vulnerability in the POST /mcp kernel endpoint, which is gated only by a general auth check (model.CheckAuth) with no admin-role or read-only enforcement. This exposes 31 MCP tools, including a file tool with list/read/write/delete/rename/copy actions across the entire workspace. When the Publish server is enabled in anonymous mode (Conf.Publish.Enable=true and Conf.Publish.Auth.Enable=false), the Publish reverse proxy attaches an anonymous RoleReader JWT to proxied requests, allowing a remote unauthenticated attacker to reach /mcp. The attacker can read conf/conf.json to extract accessAuthCode, api.token, and cookieKey in plaintext, write arbitrary files in the workspace, and plant a plugin into data/plugins/ that executes with nodeIntegration:true and no contextIsolation on the next desktop launch, leading to administrator takeover.