Total
363138 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-27608 | 1 Parseplatform | 1 Parse Dashboard | 2026-06-26 | N/A | 8.1 HIGH |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the AI Agent API endpoint (`POST /apps/:appId/agent`) does not enforce authorization. Authenticated users scoped to specific apps can access any other app's agent endpoint by changing the app ID in the URL. Read-only users are given the full master key instead of the read-only master key and can supply write permissions in the request body to perform write and delete operations. Only dashboards with `agent` configuration enabled are affected. The fix in version 9.0.0-alpha.8 adds per-app authorization checks and restricts read-only users to the `readOnlyMasterKey` with write permissions stripped server-side. As a workaround, remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected. | |||||
| CVE-2026-27610 | 1 Parseplatform | 1 Parse Dashboard | 2026-06-26 | N/A | 5.3 MEDIUM |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the `ConfigKeyCache` uses the same cache key for both master key and read-only master key when resolving function-typed keys. Under specific timing conditions, a read-only user can receive the cached full master key, or a regular user can receive the cached read-only master key. The fix in version 9.0.0-alpha.8 uses distinct cache keys for master key and read-only master key. As a workaround, avoid using function-typed master keys, or remove the `agent` configuration block from your dashboard configuration. | |||||
| CVE-2026-7531 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 9.8 CRITICAL |
| Use-after-free in PQC hybrid key-share handling. This is an incomplete-fix follow-up to CVE-2026-5460 (released in 5.9.1): a malicious TLS 1.3 server sending a truncated PQC hybrid KeyShare can still trigger the error cleanup path to operate on freed memory. | |||||
| CVE-2026-10512 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical. | |||||
| CVE-2026-56789 | 1 Rtklib | 1 Rtklib | 2026-06-26 | N/A | 6.5 MEDIUM |
| RTKLIB through 2.4.3 contains a heap buffer overflow vulnerability in the readrnxobsb function in src/rinex.c that allows attackers to trigger memory corruption by failing to clamp satellite count values from RINEX epoch headers. Attackers can craft malicious RINEX files declaring more than 64 satellites per epoch to cause heap buffer overflow writes and out-of-bounds stack reads, crashing RTKLIB-based applications including rnx2rtkp and RTKPOST. | |||||
| CVE-2026-56787 | 1 Rtklib | 1 Rtklib | 2026-06-26 | N/A | 6.5 MEDIUM |
| RTKLIB through 2.4.3 contains an off-by-one out-of-bounds read vulnerability in the decode_ssr3 function at src/rtcm3.c:1446 that allows remote attackers to trigger a global buffer overflow via crafted RTCM3 SSR messages with attacker-controlled signal mode fields. Remote attackers can exploit this vulnerability by sending malicious SSR correction streams over NTRIP or serial connections to cause denial of service or crash RTKLIB rovers and CORS servers. | |||||
| CVE-2026-56786 | 1 Rtklib | 1 Rtklib | 2026-06-26 | N/A | 9.8 CRITICAL |
| RTKLIB through 2.4.3 contains an out-of-bounds write vulnerability in decode_type1033 function that fails to clamp length counters to destination buffer size, allowing up to 191-byte overflow into fixed 64-byte descriptor fields. An attacker controlling an NTRIP or serial RTCM3 correction stream can craft a valid CRC-bearing type-1033 message to corrupt adjacent rtcm_t object members, potentially achieving arbitrary code execution or denial of service. | |||||
| CVE-2026-50549 | 1 Anysphere | 1 Cursor | 2026-06-26 | N/A | 9.8 CRITICAL |
| Cursor is a code editor built for programming with AI. Prior to 3.0, Cursor runs agent terminal commands in a sandbox by default. Before a Write, the agent canonicalizes the target path to confirm it stays inside the workspace, but when canonicalization fails it falls back to the original path and writes without approval. A malicious agent can create an in-workspace symlink that points outside the workspace and force canonicalization to fail — either because the target does not exist or because read permission is removed from the path — so the agent writes through the symlink to an arbitrary location without approval. A malicious agent could write arbitrary files outside the workspace under the user's privileges. This enables non-sandboxed Remote Code Execution — for example by overwriting the cursorsandbox helper so later commands run unsandboxed — with no user interaction beyond a benign prompt. This vulnerability is fixed in 3.0. | |||||
| CVE-2026-50548 | 1 Anysphere | 1 Cursor | 2026-06-26 | N/A | 9.8 CRITICAL |
| Cursor is a code editor built for programming with AI. Prior to 3.0, Cursor runs agent terminal commands in a sandbox by default, and the sandbox grants write access to the command's working directory. A flaw was identified in how the agent could modify the working_directory parameter, which could cause the sandbox to include writable paths outside the intended workspace. A malicious agent could set working_directory to a sensitive location and write arbitrary files outside the workspace under the user's privileges. This enables non-sandboxed Remote Code Execution — for example by overwriting the cursorsandbox helper so later commands run unsandboxed — with no user interaction beyond a benign prompt. This vulnerability is fixed in 3.0. | |||||
| CVE-2026-6291 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 6.5 MEDIUM |
| Bleichenbacher padding oracle in PKCS#7 KTRI decryption. When decrypting PKCS#7 EnvelopedData using RSA PKCS#1 v1.5 key transport, wolfSSL returned distinguishable error codes depending on whether RSA padding validation failed versus whether the decrypted content was malformed. An attacker able to submit crafted EnvelopedData messages and observe error responses could use this as a padding oracle to incrementally recover the encrypted Content Encryption Key (CEK). The fix generates a deterministic pseudo-random fake CEK on padding failure (via HMAC-SHA256) and proceeds with decryption identically, using constant-time operations throughout, so that all failure paths produce the same error regardless of padding validity. | |||||
| CVE-2026-6094 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 9.1 CRITICAL |
| Heap buffer overread in wc_PKCS7_DecodeEnvelopedData when parsing crafted PKCS7 EnvelopedData. This could theoretically be triggered by attacker-supplied data delivered via S/MIME or CMS. | |||||
| CVE-2026-6091 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 6.5 MEDIUM |
| Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled. | |||||
| CVE-2026-55967 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| AES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery. | |||||
| CVE-2026-55961 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles. | |||||
| CVE-2026-11999 | 1 Wolfssl | 1 Wolfssl | 2026-06-26 | N/A | 7.5 HIGH |
| X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are. | |||||
| CVE-2026-56123 | 1 Dest-unreach | 1 Socat | 2026-06-26 | N/A | 8.1 HIGH |
| socat versions 1.8.0.0 through 1.8.1.1 contain a heap-based buffer overflow vulnerability that allows a malicious SOCKS5 proxy server to overwrite adjacent heap memory by exploiting a sign-extension flaw in the DOMAINNAME reply parser. During connection setup, the domain name length byte is read through a signed char field causing a negative bytes_to_read value that is implicitly converted to size_t, resulting in an unbounded heap write into the 262-byte reply buffer with attacker-controlled size and content. | |||||
| CVE-2026-57588 | 1 Tenable | 1 Nessus | 2026-06-26 | N/A | 3.3 LOW |
| A SQL injection vulnerability in Nessus allows an attacker to craft a malicious scan result file that, when imported by a privileged user, injects malicious SQL into the scan results database, potentially enabling exfiltration of scan-result data. | |||||
| CVE-2026-57587 | 1 Tenable | 1 Nessus | 2026-06-26 | N/A | 5.3 MEDIUM |
| A SQL injection vulnerability in Nessus allows a remote, unauthenticated attacker who controls reverse DNS records for a scanned host to inject malicious SQL into the scan results database, potentially enabling exfiltration of scan-result data. | |||||
| CVE-2026-57437 | 1 Nokogiri | 1 Nokogiri | 2026-06-26 | N/A | 5.3 MEDIUM |
| Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::XPathContext did not keep its source document alive for garbage collection. If an XPathContext outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault. This is only reachable when application code constructs an XPathContext directly and lets the document become unreachable while continuing to use the context. The normal Document#xpath, #css, and related search methods are not affected, and it is not triggerable by malicious document input. This vulnerability is fixed in 1.19.4. | |||||
| CVE-2026-57436 | 1 Nokogiri | 1 Nokogiri | 2026-06-26 | N/A | 5.3 MEDIUM |
| Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::Document#root= validated only that the new root was a Nokogiri::XML::Node, allowing a DTD node to be set as the document root. The result is a heap use-after-free during garbage collection or finalization, leading to an invalid memory read or potentially a segfault. This vulnerability is fixed in 1.19.4. | |||||