Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-15619 | 2.1 low | 0.00% | no CPE yet | A weakness has been identified in mosaxiv clawlet up to 0.2.10. The impacted element is the function web_fetch of the file tools/tool_web_fetch.go of the component IPv4 Handler. This manipulation of the argument url causes server-side request forgery. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The reported GitHub issue was closed with the label "not planned". | 24 Oct |
| CVE-2026-15620 | 2.1 low | 0.00% | no CPE yet | A security vulnerability has been detected in mosaxiv clawlet up to 0.2.10. This affects the function tools.webFetch of the file tools/tool_web_fetch.go. Such manipulation leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The reported GitHub issue was closed with the label "not planned". | 24 Oct |
| CVE-2026-16017 | 2.1 low | 0.00% | no CPE yet | A security flaw has been discovered in mosaxiv clawlet up to 0.2.10. Impacted is the function list/remove of the file tools/tool_cron.go of the component cron Chat Tool. The manipulation results in missing authorization. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. The reported GitHub issue was closed with the label "not planned". | 24 Oct |
| CVE-2026-16195 | 2.1 low | 0.00% | no CPE yet | A security flaw has been discovered in Sipeed PicoClaw up to 0.2.9. This issue affects the function dispatchIncoming of the file pkg/channels/wecom/wecom.go of the component Group Message Handler. The manipulation results in incorrect authorization. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The reported GitHub issue was closed automatically due to inactivity. | 24 Oct |
| CVE-2026-16197 | 2.1 low | 0.00% | no CPE yet | A security vulnerability has been detected in Sipeed PicoClaw up to 0.2.9. The affected element is the function handleMessageReceive of the file pkg/channels/feishu/feishu_64.go of the component Group Message Handler. Such manipulation leads to missing authorization. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The reported GitHub issue was closed automatically due to inactivity. | 24 Oct |
| CVE-2026-96618 | 2.1 low | 0.00% | no CPE yet | Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running mix deps.get, mix deps.update, mix hex.package fetch or mix hex.docs fetch. Hex treats a mirror configured with HEX_MIRROR_URL, HEX_MIRROR or mirror_url as untrusted: it doesn't send credentials to it, and it checks registry signatures and package checksums that the mirror can't forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run. Hex.HTTP.request/5 reads the whole response body into memory and decompresses it with :zlib.gunzip/1 whenever the response's Content-Encoding contains gzip, with no limit on the compressed or decompressed size. Hex doesn't ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses. Package tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into deps/<app> in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry. mix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 applies. The signed registry doesn't cover docs tarballs, so nothing checks them. Registry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq. This issue affects hex: from 0.11.2 before 2.5.2. | 16 Oct |
| CVE-2025-11029 | 2.1 low | 0.00% | vvveb | A weakness has been identified in givanz Vvveb up to 1.0.7.2. This vulnerability affects unknown code. Executing manipulation can lead to cross-site request forgery. The attack can be executed remotely. The exploit has been made available to the public and could be exploited. Once again the project maintainer reacted very professional: "I accept the existence of these vulnerabilities. (...) I fixed the code to remove these vulnerabilities and will push the code to github and make a new release." | 9 Oct |
| CVE-2025-9646 | 2.0 low | 0.00% | zoneland, o2oa | A security flaw has been discovered in O2OA up to 10.0-410. This vulnerability affects unknown code of the file /x_organization_assemble_personal/jaxrs/definition/calendarConfig. The manipulation of the argument toMonthViewName results in cross site scripting. The attack can be launched remotely. The exploit has been released to the public and may be exploited. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9657 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was detected in O2OA up to 10.0-410. This issue affects some unknown processing of the file /x_program_center/jaxrs/script of the component Personal Profile Page. The manipulation of the argument name/alias/description results in cross site scripting. The attack may be launched remotely. The exploit is now public and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9658 | 2.0 low | 0.00% | zoneland, o2oa | A flaw has been found in O2OA up to 10.0-410. Impacted is an unknown function of the file /x_portal_assemble_designer/jaxrs/dict/ of the component Personal Profile Page. This manipulation of the argument name/alias/description causes cross site scripting. Remote exploitation of the attack is possible. The exploit has been published and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9659 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability has been found in O2OA up to 10.0-410. The affected element is an unknown function of the file /x_portal_assemble_designer/jaxrs/widget of the component Personal Profile Page. Such manipulation leads to cross site scripting. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9680 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was detected in O2OA up to 10.0-410. This impacts an unknown function of the file /x_portal_assemble_designer/jaxrs/page of the component Personal Profile Page. Performing manipulation results in cross site scripting. The attack can be initiated remotely. The exploit is now public and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9681 | 2.0 low | 0.00% | zoneland, o2oa | A flaw has been found in O2OA up to 10.0-410. Affected is an unknown function of the file /x_program_center/jaxrs/agent of the component Personal Profile Page. Executing manipulation can lead to cross site scripting. The attack can be launched remotely. The exploit has been published and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9682 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability has been found in O2OA up to 10.0-410. Affected by this vulnerability is an unknown functionality of the file /x_cms_assemble_control/jaxrs/design/appdict of the component Personal Profile Page. The manipulation leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9683 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was found in O2OA up to 10.0-410. Affected by this issue is some unknown functionality of the file /x_cms_assemble_control/jaxrs/form of the component Personal Profile Page. The manipulation results in cross site scripting. The attack may be launched remotely. The exploit has been made public and could be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9715 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was found in O2OA up to 10.0-410. Affected is an unknown function of the file /x_cms_assemble_control/jaxrs/script of the component Personal Profile Page. The manipulation of the argument name/alias/description results in cross site scripting. The attack can be launched remotely. The exploit has been made public and could be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9716 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was determined in O2OA up to 10.0-410. Affected by this vulnerability is an unknown functionality of the file /x_processplatform_assemble_designer/jaxrs/form of the component Personal Profile Page. This manipulation of the argument name/alias/description causes cross site scripting. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9718 | 2.0 low | 0.00% | zoneland, o2oa | A security flaw has been discovered in O2OA up to 10.0-410. This affects an unknown part of the file /x_processplatform_assemble_designer/jaxrs/process of the component Personal Profile Page. Performing manipulation of the argument name/alias results in cross site scripting. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9734 | 2.0 low | 0.00% | zoneland, o2oa | A security flaw has been discovered in O2OA up to 10.0-410. The impacted element is an unknown function of the file /x_query_assemble_designer/jaxrs/stat of the component Personal Profile Page. The manipulation of the argument name/alias/description/applicationName results in cross site scripting. The attack can be launched remotely. The exploit has been released to the public and may be exploited. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9735 | 2.0 low | 0.00% | zoneland, o2oa | A weakness has been identified in O2OA up to 10.0-410. This affects an unknown function of the file /x_query_assemble_designer/jaxrs/table of the component Personal Profile Page. This manipulation of the argument description/applicationName/queryName causes cross site scripting. The attack may be initiated remotely. The exploit has been made available to the public and could be exploited. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9736 | 2.0 low | 0.00% | zoneland, o2oa | A security vulnerability has been detected in O2OA up to 10.0-410. This impacts an unknown function of the file /x_query_assemble_designer/jaxrs/statement of the component Personal Profile Page. Such manipulation of the argument description/queryName leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-9737 | 2.0 low | 0.00% | zoneland, o2oa | A vulnerability was detected in O2OA up to 10.0-410. Affected is an unknown function of the file /x_query_assemble_designer/jaxrs/importmodel of the component Personal Profile Page. Performing manipulation of the argument description/applicationName/queryName results in cross site scripting. Remote exploitation of the attack is possible. The exploit is now public and may be used. The vendor replied in the GitHub issue (translated from simplified Chinese): "This issue will be fixed in the new version." | 19 Oct |
| CVE-2025-11026 | 2.0 low | 0.00% | vvveb | A vulnerability was determined in givanz Vvveb up to 1.0.7.2. Affected by this vulnerability is an unknown functionality of the component Configuration File Handler. This manipulation causes information disclosure. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. Once again the project maintainer reacted very professional: "I accept the existence of these vulnerabilities. (...) I fixed the code to remove these vulnerabilities and will push the code to github and make a new release." | 9 Oct |
| CVE-2026-16082 | 1.9 low | 0.00% | no CPE yet | A vulnerability was identified in Sipeed PicoClaw up to 0.2.9. The impacted element is the function ExecTool.executeRun of the file pkg/agent/pipeline_execute.go. The manipulation of the argument cwe leads to time-of-check time-of-use. The attack must be carried out locally. The exploit is publicly available and might be used. The reported GitHub issue was closed automatically with the label "not planned" by a bot. | 24 Oct |
| CVE-2026-16085 | 1.9 low | 0.00% | no CPE yet | A security vulnerability has been detected in Sipeed PicoClaw up to 0.2.9. Affected is the function NewContextBuilder of the file pkg/agent/context.go. Such manipulation leads to inclusion of functionality from untrusted control sphere. The attack needs to be performed locally. The exploit has been disclosed publicly and may be used. The reported GitHub issue was closed automatically with the label "not planned" by a bot. | 24 Oct |
| CVE-2025-9649 | 1.9 low | 0.00% | broadcom, tcpreplay | A security vulnerability has been detected in appneta tcpreplay 4.5.1. Impacted is the function calc_sleep_time of the file send_packets.c. Such manipulation leads to divide by zero. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. Upgrading to version 4.5.3-beta3 is recommended to address this issue. It is advisable to upgrade the affected component. The vendor confirms in a GitHub issue reply: "Was able to reproduce in 6fcbf03 but NOT 4.5.3-beta3." | 18 Oct |
| CVE-2025-11027 | 1.9 low | 0.00% | vvveb | A vulnerability was identified in givanz Vvveb up to 1.0.7.2. Affected by this issue is some unknown functionality of the component SVG File Handler. Such manipulation leads to cross site scripting. The attack may be launched remotely. The exploit is publicly available and might be used. Once again the project maintainer reacted very professional: "I accept the existence of these vulnerabilities. (...) I fixed the code to remove these vulnerabilities and will push the code to github and make a new release." | 9 Oct |
| CVE-2025-11282 | 1.9 low | 0.00% | frappe, learning | A vulnerability was found in Frappe LMS 2.34.x/2.35.0. The impacted element is an unknown function of the component Incomplete Fix CVE-2025-55006. Performing a manipulation results in cross site scripting. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The affected component should be upgraded. The vendor was informed early about a total of four security issues and confirmed that those have been fixed. However, the release notes on GitHub do not mention them. | 9 Oct |
| CVE-2025-11283 | 1.9 low | 0.00% | frappe, learning | A vulnerability was determined in Frappe LMS 2.35.0. This affects an unknown function of the component Course Handler. Executing manipulation of the argument Description can lead to cross site scripting. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. It is suggested to upgrade the affected component. The vendor was informed early about a total of four security issues and confirmed that those have been fixed. However, the release notes on GitHub do not mention them. | 9 Oct |
| CVE-2026-15997 | 1.7 low | 0.00% | no CPE yet | Out-of-bounds write vulnerability in Legion of the Bouncy Castle Inc. BC-LTS bcprov-lts8on on ARM allows Overflow Buffers. This vulnerability is associated with program files https://github.Com/bcgit/bc-lts-java/blob/main/native_c/arm/sha/shake.C, https://github.Com/bcgit/bc-lts-java/blob/main/native_c/arm/sha/sha3.C. This issue affects BC-LTS: from 2.73.0 before 2.73.12.1. Issue is only applicable if application involved is accepting memoable SHA3 / SHAKE states from potentially untrusted sources. | 24 Oct |
| CVE-2026-76993 | 1.3 low | 0.00% | no CPE yet | A vulnerability was determined in GreyDGL PentestGPT up to 1.0.0. This vulnerability affects unknown code of the component Web-Page Crawling. Executing a manipulation of the argument Traceback can lead to injection. The attack can be executed remotely. A high complexity level is associated with this attack. It is stated that the exploitability is difficult. The exploit has been publicly disclosed and may be utilized. The reported GitHub issue was closed with the label "not planned". | 18 Oct |
| CVE-2026-66392 | unscored | 0.00% | no CPE yet | Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint. Affected Scenarios: Applications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint. How to Fix: Upgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from https://github.com/apache/brpc/pull/3408 . Note: The new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected. | Fri 30 Oct |
| CVE-2026-84748 | unscored | 0.00% | no CPE yet | Improper authorization in Apache bRPC (versions < 1.18.0) on all platforms allows remote attackers to access builtin services through the public port. Root Cause: ServerOptions.internal_port is documented to make builtin services (and Tabbed services) reachable only from the internal port, and the HTTP/h2 dispatch path enforced this. However, all protobuf-based protocol dispatch paths (baidu_std, hulu_pbrpc, sofa_pbrpc, and the nshead-based protocols public_pbrpc, nshead_mcpack, nova_pbrpc and ubrpc2pb) computed the security_mode flag but never enforced it between method resolution and method invocation. Since builtin services share the method map with user services, a client able to reach the public port could invoke builtin services such as brpc.vars or hotspots by name over these pb protocols and disclose sensitive runtime information (metrics, flags, profiler data) that the operator intended to expose only via the internal port. Affected Scenarios: Use a bRPC server with ServerOptions.internal_port configured (or with builtin/Tabbed services otherwise expected to be gated by it) while the public port is reachable from an untrusted network and any pb-based protocol is enabled. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3511 | Fri 30 Oct |
| CVE-2026-84747 | unscored | 0.00% | no CPE yet | Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy. Root Cause: The method dispatch function FindMethodPropertyByURI() in bRPC's HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with '/' nor is the asterisk-form '*', contrary to RFC 9113 section 8.3.1, were not rejected. Affected Scenarios: Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front proxy intended to block. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3512 Note: After applying the fix, HTTP and HTTP/2 request paths containing empty path segments (consecutive slashes) are rejected by default, and HTTP/2 :path values that are empty or neither begin with '/' nor equal '*' are rejected. Deployments that depend on the previous lenient behavior can restore it by turning on the gflag -http_allow_empty_path_segments, which is not recommended for servers exposed to untrusted traffic. | Fri 30 Oct |
| CVE-2026-82942 | unscored | 0.00% | no CPE yet | A data race in the RDMA transport of Apache bRPC (versions < 1.18.0) allows a remote client to crash the server process (denial of service) when RDMA is enabled at build time and runtime. Root Cause: When a bRPC server negotiates RDMA with a client, the handshake completes on the TCP fd, but the server kept parsing that fd afterwards as if it were still an RPC channel. The TCP-fd input stream and the RDMA QP input stream (driven by CQ events) shared the same Socket::_read_buf, preferred_index and parsing_context without synchronization. In addition, CQ event processing could start while the handshake parsing was still in progress, and the handshake ACK phase could consume bytes belonging to the next protocol. A remote, unauthenticated client that has completed the RDMA handshake can send data on the TCP fd at the same time RDMA messages are being processed, corrupting the shared input buffer and parser state and crashing the server process (CWE-362, availability impact). Affected Scenarios: Use a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA and serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections from untrusted clients. Deployments without RDMA are not affected. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3505 | Fri 30 Oct |
| CVE-2026-82425 | unscored | 0.00% | no CPE yet | A reachable assertion in Apache bRPC (version < 1.18.0) on all platforms allows a malicious remote peer to crash the process, resulting in denial of service. Root Cause: When a Socket with health checking enabled fails, Socket::WaitAndReset closes its file descriptor while the event dispatcher may still be delivering an input event (EPOLLIN/EVFILT_READ) that was fetched for the just-closed fd. If the health check then succeeds and revives the Socket, Socket::Address succeeds again while the fd is still -1 (the next write reconnects on demand). In that window, Socket::OnInputEvent hits CHECK(!(events & EPOLLIN)) (or the kqueue equivalent) because the Socket is addressable but has no fd. CHECK failures terminate the process when bRPC is built with glog or when the gflag -crash_on_fatal_log is enabled (CHECK always terminates in OFFICIAL_BUILD/NDEBUG builds as well). Affected Scenarios: Applications using bRPC clients with health check enabled (-health_check_interval). A malicious remote peer that the client connects to can deliberately abort connections and immediately accept the health check probes, racing connection teardown against health check revival to trigger the assertion and abort the process. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3510 Note: After applying the fix, stale input events on a Socket revived without an fd are silently dropped instead of triggering the assertion. No user-visible interface or wire protocol is changed. | Fri 30 Oct |
| CVE-2026-82231 | unscored | 0.00% | no CPE yet | A Thrift client in Apache bRPC (version < 1.18.0, built with WITH_THRIFT which is off by default) can be crashed by the server peer it talks to. When the server returns a T_EXCEPTION reply whose exception struct is malformed, the client decodes it without catching what Apache Thrift throws (TProtocolException, TTransportException or std::length_error). The exception unwinds out of the bthread task function and the process calls std::terminate(), terminating the whole process along with every other in-flight RPC. This is the client response path, so the adversary is the server peer, which THREAT_MODEL.md treats as untrusted. It requires a WITH_THRIFT build (off by default). How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3500 | Fri 30 Oct |
| CVE-2026-82210 | unscored | 0.00% | no CPE yet | Enforceable assertion in the streaming feature of Apache bRPC (version < 1.18.0) on all platforms allows a remote attacker to crash the server process by sending a malformed stream feedback frame. Root Cause: When handling FRAME_TYPE_FEEDBACK frames, bRPC calls Stream::SetRemoteConsumed() which contains CHECK(_cur_buf_size > 0) and unconditionally asserts CHECK(buf.IsEmpty()) on the frame payload. A feedback frame that carries an unexpected payload, or a feedback frame received on a stream where flow control is disabled (cur_buf_size == 0), reaches these assertions. On failure, CHECK failures abort the process, allowing an unauthenticated single client (once a stream is established) to terminate the server and cause a denial of service. Affected Scenarios: Use bRPC server with the streaming control feature (Stream API) served from untrusted network. How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3494 The fix rejects malformed feedback frames with EPROTO and closes only the affected stream instead of crashing the whole process, and it bounds buffer shrinking so cur_buf_size never drops to 0 while flow control is enabled. | Fri 30 Oct |
| CVE-2026-61902 | unscored | 0.00% | no CPE yet | Apache bRPC versions before 1.18.0 do not consistently enforce the configured max_body_size limit in non-progressive HTTP/1 and HTTP/2 parsing and in memcache and couchbase response parsing. A remote unauthenticated peer can cause an affected process to buffer message data beyond the configured limit, which may lead to memory exhaustion and denial of service. Users should upgrade to 1.18.0 or apply the patch from PR https://github.com/apache/brpc/pull/3382 . The fix rejects oversized buffered HTTP bodies, returns HTTP 413 for HTTP/1 requests, resets oversized HTTP/2 streams, and rejects oversized memcache and couchbase responses from their declared lengths. Progressive HTTP reading remains supported because it uses bounded buffering. | Fri 30 Oct |
| CVE-2026-54426 | unscored | 0.00% | no CPE yet | Uncontrolled recursion in the Redis reply parser in Apache bRPC < 1.18.0 allows a remote Redis server peer to crash a bRPC Redis client process by returning a deeply nested RESP array reply. The parser recursed once for each nested array level without enforcing a depth limit. The fix adds a configurable Redis reply depth limit with default value 128 and rejects replies exceeding that limit. Affected Scenarios: Applications using bRPC as a Redis client with ChannelOptions.protocol="redis" and receiving replies from an untrusted or faulty Redis server peer. How to Fix: 1. Upgrade Apache bRPC to 1.18.0. 2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 . Note: After applying the fix, Redis replies with array nesting deeper than redis_max_reply_depth are rejected. | Fri 30 Oct |
| CVE-2025-40163 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Stop dl_server before CPU goes offline IBM CI tool reported kernel warning[1] when running a CPU removal operation through drmgr[2]. i.e "drmgr -c cpu -r -q 1" WARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170 NIP [c0000000002b6ed8] cpudl_set+0x58/0x170 LR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 Call Trace: [c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable) [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 [c00000000034df84] __hrtimer_run_queues+0x1a4/0x390 [c00000000034f624] hrtimer_interrupt+0x124/0x300 [c00000000002a230] timer_interrupt+0x140/0x320 Git bisects to: commit 4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck") This happens since: - dl_server hrtimer gets enqueued close to cpu offline, when kthread_park enqueues a fair task. - CPU goes offline and drmgr removes it from cpu_present_mask. - hrtimer fires and warning is hit. Fix it by stopping the dl_server before CPU is marked dead. [1]: https://lore.kernel.org/all/[email protected]/ [2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr [sshegde: wrote the changelog and tested it] | 19 Oct |
| CVE-2026-97974 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0]. The stack trace hinted towards a null dereference of rt->fib6_node when fn->leaf is accessed in __ip6_del_rt_siblings(). With RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run concurrently without acquiring the RTNL lock. In ip6_route_del(), the route lookup happens under rcu_read_lock() without acquiring table->tb6_lock. Between ip6_route_del() looking up the route and __ip6_del_rt_siblings() acquiring table->tb6_lock, another thread can modify the routing table. For example, when an ECMP route is replaced via RTM_NEWROUTE with NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets iter->fib6_node = NULL. A reproducer was found that triggers this [1]. Add a check to ensure rt->fib6_node is non-null before accessing it. [0] KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056 Call Trace: <TASK> ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232 inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900 sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800 __sock_sendmsg net/socket.c:815 [inline] ____sys_sendmsg+0x565/0x870 net/socket.c:2713 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2767 __sys_sendmsg net/socket.c:2799 [inline] __do_sys_sendmsg net/socket.c:2804 [inline] __se_sys_sendmsg net/socket.c:2802 [inline] __x64_sys_sendmsg+0x1b7/0x290 net/socket.c:2802 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> [1] https://gist.github.com/NamanGulati/0766a1159b6ca61928faaf87425ff899 | 19 Oct |
| CVE-2026-97618 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: io_uring/net: don't overconsume buffers when using MSG_TRUNC When a recv/recvmsg is issued with MSG_TRUNC and the incoming packet is larger than the provided buffer, the net layer returns the full length of the packet rather than the number of bytes actually copied into the buffer. As a result, io_uring advances more of the provided buffer ring than was actually filled. Use the actual filled region size to consume the buffer, but still return the full size to preserve MSG_TRUNC semantics. Take care with multishot, because that seems to already truncate the consumption based on the available payload size. This was reported in https://github.com/axboe/liburing/issues/1619. [axboe: fold in size_t unsigned fix] | 19 Oct |
| CVE-2026-90171 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: smb: smbdirect: release pending child sockets outside the handler lock smbdirect_socket_destroy() releases the listener's pending/ready child sockets while still holding the listener's handler lock, the &id_priv->handler_mutex taken via rdma_lock_handler(), not sc->listen.lock, and before the listener's own rdma_destroy_id(). That ordering has one real consequence and one cosmetic one. The real one: smbdirect_socket_release() drops the child's last reference, which destroys the child's cm_id. Doing that before the listener's rdma_destroy_id() lets _cma_cancel_listens(), running from the listener's _destroy_id(), walk an already freed child id_priv, which KASAN catches as a slab-use-after-free during listener shutdown: [ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469/0x1560 [ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652 [ 4758.913262] Call Trace: [ 4758.913267] <TASK> [ 4758.913299] __mutex_lock+0x1469/0x1560 [ 4758.913408] _cma_cancel_listens+0x312/0x3b0 [ 4758.913413] _destroy_id+0x363/0xee0 [ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440 [ 4758.913443] smbdirect_socket_release+0x124/0x230 [ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190 [ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0 [ 4758.913463] kill_server_store+0x1fb/0x2b0 [ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0 [ 4758.913507] vfs_write+0x5e7/0xc70 [ 4758.913528] ksys_write+0x12a/0x210 [ 4758.913541] do_syscall_64+0x135/0x460 [ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f The cosmetic one: releasing a child recurses into smbdirect_socket_destroy(), which takes the child's own rdma_lock_handler() lock nested under the listener's. The listener's and the child's cm_id are always different instances, so this cannot deadlock for real; the CM core itself nests a new connection id's handler_mutex under the listening id's in cma_ib_req_handler(). But lockdep only sees one lock class, reports possible recursive locking, and then disables itself, hiding real locking bugs for the rest of the run: [ 2424.579653] WARNING: possible recursive locking detected [ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted [ 2424.582548] -------------------------------------------- [ 2424.584500] ksmbd.control/8854 is trying to acquire lock: [ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.590590] [ 2424.590590] but task is already holding lock: [ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.594178] [ 2424.594178] other info that might help us debug this: [ 2424.596634] Possible unsafe locking scenario: [ 2424.596634] [ 2424.598841] CPU0 [ 2424.599765] ---- [ 2424.600695] lock(&id_priv->handler_mutex); [ 2424.601836] lock(&id_priv->handler_mutex); [ 2424.602590] [ 2424.602590] *** DEADLOCK *** [ 2424.602590] [ 2424.604512] May be due to missing lock nesting notation Splice the pending/ready children onto a local list under the listener's listen.lock, while the handler lock is held so a concurrent CM CONNECT_REQUEST cannot add more, but defer the actual smbdirect_socket_release() calls until after the listener's cm_id has been destroyed and its handler lock dropped. The children are independent sockets whose teardown needs neither the listener's handler lock nor its cm_id. Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a kcov-dataflow [1] coverage vector: it folds each instrumented comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage. [1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow | 19 Oct |
| CVE-2026-90015 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] | 19 Oct |
| CVE-2025-68259 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP. As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP. The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics. The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch[1] while running a drgn script[2] on the host to constantly swap out the memory containing the guest's TSS. [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b | 14 Oct |
346 of 346 · Previous
Download these 346 as CSV · subscribe to this list.
EPSS scores: 2026-10-31. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.