| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The SAP Cloud SDK for Python contains an improper cryptographic signature verification vulnerability (CWE-347) in IASContextProvider, the runtime-context provider registered by default via bootstrap(app).IASContextProvider extracted the app_tid, sap_gtid and user_uuid claims from the IAS JWT in the Authorization header using an unverified decoder and wrote them into the request-scoped RuntimeContext without validating the token signature. A remote caller could submit a self-signed JWT naming a victim tenant/user; the forged identity then propagated to every consumer of the runtime context:OTel span attributes (sap.tenancy.tenant_id, user.id) via RuntimeContextSpanProcessorlog records via IdentityLogFilteraudit events (tenant_id, user_initiator_id) via AuditClienttenant routing via CBCClientThis completes an earlier remediation that fixed the same unverified pattern in StarletteIASTelemetryMiddleware but did not cover IASContextProvider. |
| In SAP/astonish, an authenticated user could potentially identify and operate on another team�s sandbox containers because of improper tenant isolation in the legacy Incus sandbox-management API handlers. The affected handlers did not use the tenant-aware session lookup path, allowing cross-tenant container operations such as listing, exposing or proxying, and deleting containers.The issue affects only the legacy Incus backend. Kubernetes and OpenShell deployments are not affected because the relevant Incus-specific handlers are unavailable there. |
| Nuxt Content is the file-based CMS for Nuxt applications, powered by Markdown and Vue components. From 3.0.0 until 3.15.2, the unauthenticated POST /__nuxt_content/:collection/query endpoint accepts an attacker-controlled sql field in src/runtime/api/query.post.ts and permits expensive SQLite expressions. Version 3.0.0 performed no query validation; in affected releases using assertSafeQuery in src/runtime/internal/security.ts, the reported validation gap rejects a short list of SQL command keywords in WHERE clauses but permits function calls including randomblob(), zeroblob(), hex(), and length(). The query reaches the synchronous better-sqlite3 sink in src/runtime/internal/database.server.ts, allowing a single remote request to consume substantial CPU and memory while blocking the Node.js event loop and all concurrent request handling. Fully static prerendered deployments that do not expose the server endpoint are not affected. This issue is fixed in version 3.15.2. |
| A use-after-free weakness in MongoDB Server's server-side JavaScript support for aggregation may allow a stale reference to previously freed process memory to be read and returned. An authenticated user with minimal or no assigned roles can trigger this condition over the normal network protocol by submitting a single crafted aggregation request, with no additional privileges or non-default configuration. Successful triggering this issue may result in adjacent process memory contents being returned, including data that undermines memory-layout randomization, and may in some cases affect server availability. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()
When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does
not reset the length of the largest extent to 0 and update the inode
folio. Since modifications to the extent tree are disallowed afterward,
the cached largest extent may become stale. This can trigger the
following error in xfstests generic/388:
F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix
In the f2fs_drop_inode path, __destroy_extent_node() does not need to
guarantee that et->node_cnt is 0, because concurrency with writeback
is expected in this path, and writeback may update the extent cache.
This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between
extent node destroy and writeback"), and remove the unnecessary zero
check of et->node_cnt. |
| An incorrect authorization check in the MongoDB Server authorization subsystem may allow an unauthenticated party with local host access to obtain administrative privileges on a database server that has authorization enabled. This may result in unintended access to stored data and credentials, unintended modification of data, and loss of availability of the server. |
| An improper privilege management issue in the sharding subsystem of MongoDB Server may allow a user holding certain shard-level administrative privileges to cause persisted internal coordination state to be reprocessed with elevated internal authority. Because that state is trusted rather than re-validated, operations may be carried out beyond the user's authorized scope, including changes to cluster-wide security configuration. Successful triggering this issue requires an authenticated session directly against a cluster member and can result in unauthorized access to and modification of data across the cluster. |
| In multiple locations, there is a possible out of bounds read/write due to an incorrect bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in untrusted projects via the Terraform File Watchers |
| In JetBrains IntelliJ IDEA before 2026.3 host name verification was missing for server TLS certificates |
| On affected EOS versions with the eAPI service enabled, a specially crafted HTTP request can allow an unauthenticated, remote attacker to read arbitrary files, including sensitive credentials from the switch filesystem. |
| On affected platforms running Arista EOS with Precision Time Protocol (PTP) configured, an unauthenticated attacker with network access to a PTP-enabled port can create a denial of service (DoS) condition by sending traffic to the system. |
| On affected platforms running Arista EOS with Bidirectional Forwarding Detection (BFD) configured to use keyed MD5 or keyed SHA1 authentication, an unauthenticated attacker with network adjacency (direct or multi-hop) to a BFD-enabled interface can send a specially crafted BFD packet resulting in a system reboot. |
| On affected platforms running Arista EOS configured as S-BFD peers, an unauthenticated attacker could send a crafted S-BFD PDU to an initiator device. This crafted PDU could cause the kernel on the initiator device to crash, resulting in an unexpected device reboot. |
| A malformed Error Report can cause EOS to read beyond packet boundaries, potentially terminating the RPKI agent or exposing unintended memory contents through logging. |
| A crafted Error Report can leave EOS stuck believing that a cache reset is in progress, preventing ROA publication, withdrawal reconciliation, and BGP origin-validation updates. |
| On affected platforms running Arista EOS with Border Gateway Protocol (BGP) changing the BGP listen port from its default value disables default protective Access Control List (ACL) rules against unexpected BGP peering attempts. |
| An unauthenticated attacker on an adjacent network segment can bypass MD5 authentication and have unauthorized RIP route updates accepted by the device. Successful exploitation requires that RIPv2 MD5 authentication is configured on the affected interface. An attacker who can inject crafted RIPv2 packets could cause the device to install routes that redirect network traffic through attacker-controlled paths, create routing loops, or blackhole traffic, disrupting network connectivity. |
| An unauthenticated attacker on an adjacent network segment can send crafted RIPv2 packets to a RIP-enabled interface on the device to trigger the Rip agent crash without providing valid credentials. Repeated exploitation reliably interrupts routing service on the affected device, which may also disrupt routing for other devices that depend on it. In a worst-case scenario, the vulnerability may allow an attacker to execute arbitrary code on the affected device. |
| On affected EOS platforms where 802.1x is configured in multi-host authenticated mode and the device is configured with Policy Based Routing (PBR), traffic from unauthenticated hosts may be forwarded to the destination configured in the PBR policies. This could potentially allow unauthenticated hosts access to networks. Additionally Layer 2 and Layer 3 control packets from unauthenticated hosts may get copied to the CPU. |
