| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability in the API of Cisco Catalyst SD-WAN Manager could allow an authenticated, remote attacker to overwrite arbitrary files on the local file system. To exploit this vulnerability, the attacker must have valid read-only credentials with API access on the affected system.
This vulnerability is due to improper file handling on the API interface of an affected system. An attacker could exploit this vulnerability by uploading a malicious file on the local file system. A successful exploit could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges. |
| A vulnerability in the Data Collection Agent (DCA) feature of Cisco Catalyst SD-WAN Manager could allow an authenticated, local attacker to gain DCA user privileges on an affected system. To exploit this vulnerability, the attacker must have valid vmanage credentials on the affected system.
This vulnerability is due to the presence of a credential file for the DCA user on an affected system. An attacker could exploit this vulnerability by accessing the filesystem as a low-privileged user and reading the file that contains the DCA password from that affected system. A successful exploit could allow the attacker to access another affected system and gain DCA user privileges.
Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability. |
| A vulnerability in the API user authentication of Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to gain access to an affected system as a user who has the netadmin role.
The vulnerability is due to improper authentication for requests that are sent to the API. An attacker could exploit this vulnerability by sending a crafted request to the API of an affected system. A successful exploit could allow the attacker to execute commands with the privileges of the netadmin role.
Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability. |
| An Incorrect Permission Assignment for Critical Resource vulnerability in the On-Box Anomaly detection framework of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated, network-based attacker to execute code as root.
The On-Box Anomaly detection framework should only be reachable by other internal processes over the internal routing instance, but not over an externally exposed port. With the ability to access and manipulate the service to execute code as root a remote attacker can take complete control of the device.
Please note that this service is enabled by default as no specific configuration is required.
This issue affects Junos OS Evolved on PTX Series:
* 25.4 versions before 25.4R1-S1-EVO, 25.4R2-EVO.
This issue does not affect Junos OS Evolved versions before 25.4R1-EVO.
This issue does not affect Junos OS. |
| VMware Aria Operations contains a stored cross-site scripting vulnerability. A malicious actor with privileges to create custom benchmarks may be able to inject script to perform administrative actions in VMware Aria Operations.
To remediate CVE-2026-22720, apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' of VMSA-2026-0001 https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36947https:// . |
| Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain. In versions 1.6.2 and prior, the `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher's 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership. Apatch was merged at commit c76c5ad0dc9de1c966443bd946fafc6351f87587. Possible workarounds include deploying the patched contracts and pointing DNSSECImpl.setAlgorithm to the deployed contract. |
| Bitnami Sealed Secrets is vulnerable to a scope-widening attack during
the secret rotation (/v1/rotate) flow. The rotation handler derives the
sealing scope for the newly encrypted output from untrusted
spec.template.metadata.annotations present in the input SealedSecret.
By submitting a victim SealedSecret to the rotate endpoint with the
annotation sealedsecrets.bitnami.com/cluster-wide=true injected into the
template metadata, a remote attacker can obtain a rotated version of the
secret that is cluster-wide. This bypasses original "strict" or
"namespace-wide" constraints, allowing the attacker to retarget and unseal
the secret in any namespace or under any name to recover the plaintext
credentials. |
| The TP2WP Importer plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'Watched domains' textarea on the attachment importer settings page in all versions up to, and including, 1.1. This is due to insufficient input sanitization and output escaping when domains are saved via AJAX and rendered with echo implode() without esc_textarea(). This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the attachment importer settings page. |
| Kruise provides automated management of large-scale applications on Kubernetes. Prior to versions 1.8.3 and 1.7.5, PodProbeMarker allows defining custom probes with TCPSocket or HTTPGet handlers. The webhook validation does not restrict the Host field in these probe configurations. Since kruise-daemon runs with hostNetwork=true, it executes probes from the node network namespace. An attacker with PodProbeMarker creation permission can specify arbitrary Host values to trigger SSRF from the node, perform port scanning, and receive response feedback through NodePodProbe status messages. Versions 1.8.3 and 1.7.5 patch the issue. |
| This vulnerability is caused by a CWE‑159: "Improper Handling of Invalid Use of Special Elements" weakness, which leads to an unrecoverable inconsistency in the CLFS.sys driver. This condition forces a call to the KeBugCheckEx function, allowing an unprivileged user to trigger a system crash. Microsoft silently fixed this vulnerability in the September 2025 cumulative update for Windows 11 2024 LTSC and Windows Server 2025. Windows 25H2 (released in September) was released with the patch. Windows 1123h2 and earlier versions remain vulnerable. |
| The The Events Calendar plugin for WordPress is vulnerable to unauthorized modification of data and loss of data due to an improper capability check on the 'can_edit' and 'can_delete' function in all versions up to, and including, 6.15.16. This makes it possible for authenticated attackers, with Contributor-level access and above, to update or trash events, organizers and venues via REST API. |
| LORIS (Longitudinal Online Research and Imaging System) is a self-hosted web application that provides data- and project-management for neuroimaging research. Starting in version 24.0.0 and prior to versions 26.0.5, 27.0.2, and 28.0.0, an authenticated user with the appropriate authorization can read configuration files on the server by exploiting a path traversal vulnerability. Some of these files contain hard-coded credentials. The vulnerability allows an attacker to read configuration files containing hard-coded credentials. The attacker could then authenticate to the database or other services if those credentials are reused. The attacker must be authenticated and have the required permissions. However, the vulnerability is easy to exploit and the application source code is public. This problem is fixed in LORIS v26.0.5 and v27.0.2 and above, and v28.0.0 and above. As a workaround, the electrophysiogy_browser in LORIS can be disabled by an administrator using the module manager. |
| Vikunja is an open-source self-hosted task management platform. Prior to version 2.0.0, a reflected HTML injection vulnerability exists in the Projects module where the `filter` URL parameter is rendered into the DOM without output encoding when the user clicks "Filter." While `<script>` and `<iframe>` are blocked, `<svg>`, `<a>`, and formatting tags (`<h1>`, `<b>`, `<u>`) render without restriction — enabling SVG-based phishing buttons, external redirect links, and content spoofing within the trusted application origin. Version 2.0.0 fixes this issue. |
| n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, an authenticated user with permission to create or modify workflows could leverage the Merge node's SQL query mode to execute arbitrary code and write arbitrary files on the n8n server. The issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate all known vulnerabilities. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Limit workflow creation and editing permissions to fully trusted users only, and/or disable the Merge node by adding `n8n-nodes-base.merge` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. |
| The Dart and Flutter SDKs provide software development kits for the Dart programming language. In versions of the Dart SDK prior to 3.11.0 and the Flutter SDK prior to version 3.41.0, when the pub client (`dart pub` and `flutter pub`) extracts a package in the pub cache, a malicious package archive can have files extracted outside the destination directory in the `PUB_CACHE`. A fix has been landed in commit 26c6985c742593d081f8b58450f463a584a4203a. By normalizing the file path before writing file, the attacker can no longer traverse up via a symlink. This patch is released in Dart 3.11.0 and Flutter 3.41.0.vAll packages on pub.dev have been vetted for this vulnerability. New packages are no longer allowed to contain symlinks. The pub client itself doesn't upload symlinks, but duplicates the linked entry, and has been doing this for years. Those whose dependencies are all from pub.dev, third-party repositories trusted to not contain malicious code, or git dependencies are not affected by this vulnerability. |
| mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted `jaxax.naming.Reference` or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to `false`, `com.sun.jndi.ldap.object.trustURLCodebase`. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java's JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs. |
| LangGraph Checkpoint defines the base interface for LangGraph checkpointers. Prior to version 4.0.0, a Remote Code Execution vulnerability exists in LangGraph's caching layer when applications enable cache backends that inherit from `BaseCache` and opt nodes into caching via `CachePolicy`. Prior to `langgraph-checkpoint` 4.0.0, `BaseCache` defaults to `JsonPlusSerializer(pickle_fallback=True)`. When msgpack serialization fails, cached values can be deserialized via `pickle.loads(...)`. Caching is not enabled by default. Applications are affected only when the application explicitly enables a cache backend (for example by passing `cache=...` to `StateGraph.compile(...)` or otherwise configuring a `BaseCache` implementation), one or more nodes opt into caching via `CachePolicy`, and the attacker can write to the cache backend (for example a network-accessible Redis instance with weak/no auth, shared cache infrastructure reachable by other tenants/services, or a writable SQLite cache file). An attacker must be able to write attacker-controlled bytes into the cache backend such that the LangGraph process later reads and deserializes them. This typically requires write access to a networked cache (for example a network-accessible Redis instance with weak/no auth or shared cache infrastructure reachable by other tenants/services) or write access to local cache storage (for example a writable SQLite cache file via permissive file permissions or a shared writable volume). Because exploitation requires write access to the cache storage layer, this is a post-compromise / post-access escalation vector. LangGraph Checkpoint 4.0.0 patches the issue. |
| LangChain is a framework for building LLM-powered applications. Prior to version 1.1.8, a redirect-based Server-Side Request Forgery (SSRF) bypass exists in `RecursiveUrlLoader` in `@langchain/community`. The loader validates the initial URL but allows the underlying fetch to follow redirects automatically, which permits a transition from a safe public URL to an internal or metadata endpoint without revalidation. This is a bypass of the SSRF protections introduced in 1.1.14 (CVE-2026-26019). Users should upgrade to `@langchain/community` 1.1.18, which validates every redirect hop by disabling automatic redirects and re-validating `Location` targets before following them. In this version, automatic redirects are disabled (`redirect: "manual"`), each 3xx `Location` is resolved and validated with `validateSafeUrl()` before the next request, and a maximum redirect limit prevents infinite loops. |
| Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes. |
| ZITADEL is an open source identity management platform. Starting in version 2.31.0 and prior to versions 3.4.7 and 4.11.0, opaque OIDC access tokens in the v2 format truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID. V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token. The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. The patch in versions 4.11.0 and 3.4.7 resolves the issue by verifying the `user_id` from the token against the session data from the database. No known workarounds are available. |
