| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets — normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner — to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: The sole source documents PE-format conformance defects in innosetup-5.5.9.exe with no exploit, attack path, or untrusted search path condition (CWE-426/427), and the author states Windows loads these files normally; the record's remote/exploited claims are unsupported, as is the product maintainer's contention. |
| Integer underflow (wrap or wraparound) in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| In MONAI 1.6.0, PersistentDataset (monai/data/dataset.py) explicitly rejects the combination track_meta=True with weights_only=True, forcing users who cache MetaTensors (the default tensor type in MONAI >= 1.0) to run torch.load(hashfile, weights_only=False). Related cache helpers in monai/data/utils.py also call pickle.loads on cached content and derive cache keys with hashlib.md5. As a result, a local user with write access to a shared or world-writable cache_dir (e.g. /tmp/monai_cache, HPC scratch, ~/.cache/monai) can place a malicious pickle file that is deserialized the next time another user's MONAI pipeline reads the cache, resulting in arbitrary code execution in that user's context. All released versions of the monai pip package are affected; no patched version is available as of the advisory. |
| MONAI through 1.6.0 contains an eval injection vulnerability in _get_fake_spatial_shape() in monai/bundle/scripts.py. The function validates shape expressions with a helper that walks the AST and only collects ast.Name nodes, rejecting any name other than 'p' or 'n', before passing the string to eval(). Expressions built solely from constants and attribute, subscript, or call nodes (for example "(1).__class__.__bases__[0].__subclasses__()" or "int.__class__.__init__.__globals__") contain no ast.Name nodes and therefore bypass the allowlist. Because the shape value originates from bundle metadata consumed by _get_real_input_data and verify_net_in_out (reachable through the bundle 'verify_net_in_out' CLI flow), an attacker who can influence a bundle's metadata can escape the eval sandbox via object introspection chains and achieve code execution in this non-default flow. |
| bbs-go through 4.4.6 contains a permission bypass vulnerability in the AdminMiddleware authorization logic where the read-only dashboard.user.view permission rule matches the /api/admin/user/synccount endpoint before the intended dashboard.user.update rule. Authenticated users with only view permissions can call the synccount endpoint to trigger expensive full-table user recounts and cache invalidations, causing denial of service through repeated concurrent database operations. |
| In JetBrains YouTrack before 2026.2.18991 sSRF via stored XHTML injection was possible during PDF export |
| In JetBrains YouTrack before 2026.2.19197 low-level Admin Read permission users could disclose integration credentials via import configurations |
| In JetBrains YouTrack before 2026.2.19197 missing authorisation on several endpoints allowed authenticated users to access information from other projects |
| In JetBrains YouTrack before 2026.2.19197 authorisation bypass in the scripts debugger allowed arbitrary code execution |
| In JetBrains YouTrack before 2026.2.19197 stored XSS in the workflow error notification toast was possible |
| An issue was discovered in matio 1.5.28. A heap-based memory corruption can occur in Mat_VarCreateStruct() when the nfields value does not match the actual number of strings in the fields array. This leads to out-of-bounds reads and invalid memory frees during cleanup, potentially causing a segmentation fault or heap corruption. NOTE: Multiple third-parties note that the available evidence does not demonstrate a vulnerability exploitable through an attacker-controlled input path. |
| Without NO_SESSION_CACHE_REF, wolfSSL_get_session() does not return a session object but a ClientSession reference of the form {row, index, hash(sessionID)} into the process-global SessionCache, and ClientSessionToSession() validates it against that hash alone. Because the TLS 1.2 session ID is chosen by the server and sent in clear, AddSessionToCache() matches any other server's session on the same ID and overwrites the client-side entry with that server's master secret, cipher suite and version, while the handle continues to resolve; nothing on the write path compares the peer, the application's server ID or the WOLFSSL_CTX. Resuming through the handle then produces an abbreviated handshake in which no Certificate message is sent, so neither chain verification nor wolfSSL_check_domain_name() runs, and the attacker is accepted as the original server for the whole of that connection. Affected builds are those leaving NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE and TITAN_SESSION_CACHE all undefined, which includes a plain ./configure, --enable-opensslextra and --enable-opensslall; fifteen integration options define NO_SESSION_CACHE_REF and are therefore not affected, among them --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-wpas and the rest of the OPENSSL_COMPATIBLE_DEFAULTS family, and --enable-leanpsk, --enable-leantls, --enable-lowresource and --enable-tinytls13 disable the cache outright. The application must use the legacy reference flow, wolfSSL_get_session() or SSL_get_session() followed by wolfSSL_set_session(); wolfSSL_get1_session() returns the session object itself and is not affected, nor are wolfSSL_SetServerID() lookups. Only TLS 1.2 and below and DTLS 1.2 and below are reachable, since TLS 1.3 and ticket resumption with an empty ServerHello session ID both use a client-chosen cache key. The poisoned entry lives in the process-global cache, so it crosses WOLFSSL_CTX boundaries and persists until the entry is evicted or the session times out, 500 seconds by default. Releases v5.3.0 through v5.9.2 are affected; the fix adds a per-write generation counter to the cache and raises WOLFSSL_CACHE_VERSION from 2 to 3, so a cache persisted by an older build is rejected by a fixed one. |
| AiSOC versions before 12.0.0 contain an authorization bypass vulnerability in the MSSP module that allows authenticated users to add arbitrary tenants to portfolios they own. Attackers can submit tenant UUIDs via the add_tenants_to_portfolio endpoint to claim unclaimed tenants and read their security alerts, incidents, and posture metrics without consent. |
