| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Klever-Go is the Go implementation of the Klever blockchain protocol. Versions from 1.7.14 through 1.7.17 are vulnerable to a remotely triggerable denial of service. Both REST APIs are started with the Gin Engine.Run convenience method, which serves requests through Go's default HTTP server with no ReadHeaderTimeout, ReadTimeout, or MaxHeaderBytes configured. As a result, incoming connections that never complete their request headers are held open indefinitely. When a REST listener is reachable beyond localhost through the documented all-interface bind or a Docker port-publish deployment, a single unauthenticated client can open many slow-header connections and hold them open until server file descriptors are exhausted, preventing the API from accepting new connections. This renders the REST API unavailable to legitimate clients. This issue is fixed in version 1.7.18. |
| Kakoune is a code editor. Prior to version 2026.05.21, the bundled, enabled by default, `autorestore.kak` script can be exploited by malicious backup files leading to arbitrary kakoune and shell commands being executed by simply opening a file. Kakoune 2026.05.21 fixes the issue. As a workaround, add `autorestore-disable` to the user kakrc will disable the autorestore feature. |
| OpenYak is a local-first agent runtime for reliable tool-using models, with a desktop workspace built on top. Prior to version 1.1.3, the OpenYak desktop backend binds an HTTP API to `127.0.0.1:<random port>` (commonly 19141) without server-side Origin validation, loopback authentication, or Content-Type enforcement, and with a wildcard CORS policy. Any webpage a user visits while OpenYak is running can issue cross-origin requests to this local server — the browser acts as a proxy into loopback, bypassing OS-level network isolation. Chained, this lets a malicious page execute arbitrary shell commands on the host (RCE) via the build agent with `permission_presets.bash=true`, shut down the service, and exfiltrate chat history and account PII — with no user interaction beyond opening the page. Version 1.1.3 patches the issue. |
| PraisonAI is a multi-agent teams system. Versions prior to 0.1.4 of the PraisonAI Platform API have two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires `min_role="member"`, which lets any workspace member promote themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to. Both issues come from the same gap: the route layer pulls `workspace_id` from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The `require_workspace_member()` dependency does its job correctly. The problem is that the service layer doesn't use the information it provides. Version 0.1.4 of the PraisonAI Platform API patch the issue. |
| JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. Prior to 5.5.0, invalid input to form-based login authenticators can place an unbounded attacker-controlled username in failed-login logs, allowing an unauthenticated attacker to consume logging and storage resources. This issue is fixed in version 5.5.0. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix stale skb->prev after async crypto steals a GSO segment
skb_gso_segment() leaves the segment list head with ->prev pointing at
the last segment, an invariant validate_xmit_skb_list() relies on when
it sets its tail pointer (tail = skb->prev).
When validate_xmit_xfrm() walks a GSO list and some segments are stolen
by async crypto (->xmit() returns -EINPROGRESS), those segments are
unlinked from the list but the head ->prev is never updated. If the
last segment is the one stolen, the returned head still has ->prev
pointing at it, even though it is now owned by the crypto engine and may
be freed. validate_xmit_skb_list() later does tail->next = skb, writing
through that stale pointer -- a use-after-free.
Repoint skb->prev at the last retained segment before returning. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, OpenBao's inline auth functionality incorrectly redacted audit log entries, resulting in non-auth headers being removed and auth-related headers being retained in cleartext. This requires an attacker to compromise access to the audit device. Operators should review leaked source authentication material and rotate it as appropriate. This is fixed in OpenBao v2.5.4. |
| Pathling is a set of tools that make it easier to use FHIR and clinical terminology within health data analytics. Prior to version 2.0.0 of Pathling Server, Pathling's `/$result` endpoint allows a caller who can obtain any valid async export job ID to supply `file` parameter values containing path traversal sequences. The handler verifies only the supplied `job` and never normalises or confines the requested `file` path to that job's `jobs/<jobId>` directory before opening it as a filesystem resource. Because async export scratch space lives under the same warehouse database root as persisted resource tables, an attacker can use their own export job to read other files from the warehouse. This is fixed in Pathling Server 2.0.0. As an interim mitigation, disable the async export operations (`pathling.operations.exportEnabled`, `patientExportEnabled`, `groupExportEnabled`, `bulkSubmitEnabled`) or enable authentication and restrict export capability to trusted callers. |
| A security vulnerability has been detected in HKUDS nanobot up to 0.2.1. Impacted is the function ExecTool._guard_command/ExecTool._spawn of the file nanobot/agent/tools/shell.py of the component Shell Allowlist Handler. Such manipulation leads to os command injection. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 0.3.0 is recommended to address this issue. The name of the patch is 4562. It is advisable to upgrade the affected component. Multiple issues were reported to the project. They reacted with a high level of professionalism and kindness: "These five reports are variants of the same root cause: validation of shell commands containing multiple segments, wrappers, comments, or chained commands. The issue was fixed by validating every executable shell segment against the configured allowlist". |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Prevent rereg_mr for non-mem regions
When a QP/CQ/SRQ is created, a two step process is used
where the buffer is allocated in userspace and explicitly
registered with the normal reg_mr mechanism prior to creating
the actual QP/CQ/SRQ object.
These special registrations are indicated via an ABI field
so the driver knows that they do not have a valid mkey and
to skip the actual CQP command submission.
Since these are real MR objects from the core's perspective,
it is possible for a user application to invoke rereg_mr on them
and cause a real CQP op to be emitted with the zero-initialized
mkey value of 0.
Fix this by preventing rereg_mr on these special regions. |
| A flaw was identified in Argo CD, the GitOps engine used by Red Hat OpenShift GitOps, that could allow an unauthenticated attacker with network access to the Argo CD repo-server to achieve remote code execution. Under certain conditions, the attacker may then manipulate cached data to deploy malicious Kubernetes resources to managed clusters, potentially resulting in complete cluster compromise. |
| When using the "configparser" module to write configuration files
containing multi-line text values with carriage return characters (\r) the
resulting file could be injected with unexpected keys and values if the
attacker controls the written value. |
| tarfile.extractall() with the 'data' or 'tar'
filter could be bypassed by a crafted archive where a hardlink
references a symlink stored at a deeper name than the hardlink itself.
The extraction fallback validated the symlink at it's archived location
but recreated it at the hardlink's shallower
path, letting a relative
target the filter judged contained escape the destination directory.
This allowed a malicious tar archive to create a symlink pointing
outside the destination, enabling out-of-destination file reads or
writes. This was an incomplete fix of CVE-2025-4330. |
| To allow builds of Python to be run from an in-tree layout (rather than
an installed file layout), the VPATH variable is defined at build time
and used to locate certain landmarks - specifically,
Modules/setup.local. When this landmark is found relative to VPATH
relative to the executable, Python assumes it is running in a source
tree and generates a different default sys.path. This code remains in
release builds, so that release-ready builds can be built in-tree.
On Windows, since builds are written to 'PCbuild/', the value of
VPATH is set to '..\..', which results in a landmark of
'..\..\Modules\setup.local'. This path is outside the install directory
of Python, and may have different permissions, potentially allowing a
low-privilege user to create the landmark and an alternative `Lib`
folder that will be discovered by an otherwise restricted install.
Such a setup occurs with the legacy default install location for all
users (in the now superseded EXE installer), due to how Windows allows
all users to create folders in the root directory of their OS drive.
Our recommended mitigation on Windows is to migrate away from the
legacy installer and use the new [Python install
manager](https://www.python.org/downloads/latest/pymanager/) to install
for the current user. Installs where the directory two levels above the
Python installation directory have equivalent permissions are unaffected
(in general, a per-user install cannot be modified at all by other
users, removing any escalation of privilege risk, and could be directly
modified by a privileged user, making the potential tampering
irrelevant). Alternative mitigations might include preemptively creating
and restricting access to a `Modules` directory. Be aware that only 3.13
and 3.14 will receive updated legacy installers - earlier fixes are only
provided as sources.
Platforms other than Windows allow VPATH to be overridden, but as they
don't usually use a separated directory in the build for binaries, are
unlikely to have a landmark reference outside of the install directory.
The landmark detection involving VPATH is a fallback for when a more
specific landmark - .\pybuilddir.txt - is absent, and was included for
compatibility. Future releases of Python will no longer include the
fallback, and so builds will need to generate or preserve the
pybuilddir.txt file in order to work in-tree. This landmark file has
been generated on Windows since 3.11, and on other platforms for longer. |
| The incremental HTML parser (html.parser.HTMLParser) allows for CPU
denial-of-service through repeated unterminated markup declarations when
processing uncontrolled data. |
| unicodedata.normalize() can take excessive CPU time when processing
specially crafted Unicode input containing long runs of combining characters
with alternating Canonical Combining Class values.
This affects all normalization forms. |
| `Element.findall()` and fully-consumed `Element.iterfind()` exhibit `O(n^2)` time complexity when using XPath index predicates (e.g. `[1]`, `[last()]`, `[last()-N]`) on XML documents with many same-tag siblings. `Element.find()` is only affected when the first match is near the end of the sibling list, such as with `[last()]` or `[last()-N]`; `.//item[1]` short-circuits after the first match. |
| bz2.BZ2Decompressor objects could be reused after a decompression error. If an application caught the resulting OSError and retried with the same decompressor, crafted input could cause the decompressor to resume from an invalid internal state and perform out-of-bounds writes to a stack buffer. This could crash the process when processing untrusted data. |
| A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi OS devices to access files on the underlying system that could be manipulated to access an underlying account. |
| In the Linux kernel, the following vulnerability has been resolved:
smb/client: handle overlapping allocated ranges in fallocate
smb3_simple_fallocate_range() can skip holes when an allocated range
returned by the server starts before the current fallocate offset. The
skipped hole is not zero-filled, but fallocate still returns success. A
later write to that hole may therefore fail with ENOSPC.
The function queries allocated ranges so that it can preserve existing
contents and write zeroes only into holes. However, the server may return
a range that starts before the current fallocate offset.
For example, assume the fallocate request is [100, 400) and the only
allocated range returned by the server is [0, 200):
Request: [100, 400)
Server range: [ 0, 200) allocated
Correct:
[100, 200) allocated data, skip
[200, 400) hole, zero-fill
Current:
[100, 300) skipped
[300, 400) zero-filled afterwards
The current code adds the full server range length, 200, to the current
offset 100 and moves to 300. As a result, the hole in [200, 300) is
skipped without being zero-filled.
Fix this by advancing only over the part of the allocated range that
overlaps the current fallocate offset. Ignore ranges that end before the
current offset and reject ranges whose end offset overflows.
This also prevents a malformed range length from causing an out-of-bounds
zero-buffer read. |
