Export limit exceeded: 29957 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (29957 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-65630 | 1 Potatosalad | 1 Jose | 2026-11-02 | N/A |
| Observable Timing Discrepancy vulnerability in potatosalad jose allows recovery of a long-term X25519 private key through a timing side channel in the pure-Erlang Curve25519 fallback. The pure-Erlang X25519 implementation performs scalar multiplication over the secret private key using a recursive Montgomery ladder (jose_jwa_x25519:curve25519/2) whose clauses branch on individual bits of the clamped private scalar, and whose per-step operations (jose_jwa_x25519:montgomery_add/3 and jose_jwa_x25519:montgomery_double/1) and field inversion are built from value-dependent Erlang bignum arithmetic (multiplication, remainder, and modular exponentiation). Although the ladder is operation-count balanced and fixed at 254 steps, the concrete integer values processed at each step, and therefore the running time, depend on the secret scalar. The execution time of the public entry points jose_jwa_x25519:scalarmult/2, jose_jwa_x25519:x25519/2, jose_jwa_x25519:x25519_base/1, and jose_jwa_x25519:sk_to_pk/1 is thus a function of the private key. This path is reachable from the public API, most notably when a service decrypts attacker-supplied ECDH-ES (JWE) messages with a long-term X25519 key (for example through JOSE.JWK.box_decrypt_ecdh_es/2, which reaches jose_jwa_curve25519:x25519_shared_secret/2 and the ladder). An attacker who can submit ciphertexts and measure decryption timing can, in principle, recover the private key bit by bit, defeating the resistance X25519 was designed to provide. Recovery of the key compromises the confidentiality and authenticity of all data protected by it. This issue affects jose: from 1.10.0 before 1.11.13. | ||||
| CVE-2026-116768 | 1 Absolute | 1 Secure Access | 2026-11-02 | N/A |
| CVE-2026-116768 is a missing length validation vulnerability in Secure Access servers prior to 14.61. Authenticated attackers can cause a persistent denial of service when connecting for the first time. | ||||
| CVE-2026-116671 | 1 Xpdf | 1 Xpdf | 2026-11-02 | 5.5 Medium |
| Infinite loop in Xpdf 4.06 and earlier, due to incorrect validation of progression order field in JPEG 2000 image. | ||||
| CVE-2026-58930 | 1 Google | 1 Android | 2026-11-02 | N/A |
| An unprivileged application can exploit a lack of package/signature validation in SystemUI's `RemoteQCController` when resolving a hardcoded `content://` URI. This allows the attacker to squat on a specific authority if the legitimate package is absent, inject spoofed UI elements into the trusted SystemUI Quick Controls panel, and gain a Background Activity Launch (BAL) grant from SystemUI when the user interacts with the spoofed element. | ||||
| CVE-2026-116766 | 1 Absolute | 1 Secure Access | 2026-11-02 | N/A |
| CVE-2026-116766 is an improper input handling vulnerability in the Secure Access server versions between 13.0 and prior to 14.61. Attackers can cause a persistent denial of service of the server. | ||||
| CVE-2026-76306 | 1 Splunk | 1 Splunk | 2026-11-02 | 7.5 High |
| In Splunk SOAR versions below 8.7.0, a user that has the "Observer" role could use query filters in the Representational State Transfer (REST) API to infer password hashes and authorization tokens for other users. The information disclosure is possible because Splunk SOAR applies REST API query filters to user records before it protects sensitive fields from query processing. For more information see Using the REST API reference for Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/8.5.0/using-the-splunk-soar-rest-api/using-the-rest-api-reference-for-splunk-soar-on-premises), Query for Data (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/7.1.0/using-the-splunk-soar-rest-api/query-for-data), and Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation. | ||||
| CVE-2026-118643 | 1 N8n | 1 N8n | 2026-11-02 | 8.2 High |
| n8n before 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1 stores credential secrets in execution error data when operations fail in the Git, MongoDB Atlas Vector Store, and Google Cloud Storage nodes. Users who can view a workflow's executions but cannot read the credential can recover Git passwords or tokens, MongoDB database passwords, or Google access tokens from that data. | ||||
| CVE-2026-117688 | 2 Red Hat, Redhat | 5 Red Hat Build Of Keycloak 26.4, Build Keycloak, Build Of Keycloak and 2 more | 2026-11-02 | 5.3 Medium |
| A flaw was found in the client registration component of Keycloak, an open-source identity and access management solution. When a vault provider is used to store sensitive information, an authenticated client owner can use a specially crafted reference to trick the system into revealing secrets. By updating a client secret to point to a vault entry and then requesting the client configuration, the owner can see the secret value in plain text. This could lead to the exposure of sensitive credentials that the user should not be able to access. | ||||
| CVE-2026-101259 | 1 Apache | 2 Apache Camel, Camel | 2026-11-02 | 5.3 Medium |
| Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. When the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route's error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value's string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer. | ||||
| CVE-2026-112707 | 1 Apple | 3 Ios And Ipados, Ipados, Iphone Os | 2026-11-02 | 3.3 Low |
| A privacy issue was addressed by moving sensitive data to a protected location. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2. An app may be able to identify what other apps a user has installed. | ||||
| CVE-2026-11460 | 1 Boost | 1 Serialization | 2026-11-02 | 7.3 High |
| A flaw has been found in Boost Serialization. The impacted element is an unknown function. This manipulation causes improper validation of specified type of input. It is possible to initiate the attack remotely. The exploit has been published and may be used. The maintainer was notified on Aug 2025 and a disclosure deadline was set for 90 days. The maintainer acknowledged but postponed indefinitely citing time concerns. No patch is currently available and the disclosure deadline has expired. | ||||
| CVE-2026-120503 | 1 Echohs | 1 Geekezbrowser | 2026-11-02 | 3.3 Low |
| A vulnerability was detected in EchoHS GeekezBrowser up to 1.7.2/1.8.0. This affects an unknown part of the file /api/status of the component Public API. The manipulation results in information disclosure. The attack requires a local approach. The exploit is now public and may be used. Upgrading to version 1.8.1 is able to mitigate this issue. The patch is identified as 9317a89aa0fd2715d9c2bd27bdbb52b5d228dd9e. Upgrading the affected component is recommended. | ||||
| CVE-2026-77817 | 2 Ibm, Langflow | 2 Langflow Oss, Langflow | 2026-11-02 | 6.5 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to obtain sensitive information due to improper sanitization of secrets during flow and project exports. | ||||
| CVE-2026-65626 | 1 Potatosalad | 1 Jose | 2026-11-02 | N/A |
| The pure-Erlang RSAES-PKCS1-v1_5 decryption in the jose_jwa_pkcs1 module is a Bleichenbacher padding oracle. eme_pkcs1_decode/2 returns the recovered message when a decrypted block has valid PKCS#1 v1.5 padding (a leading 0x00 0x02, a padding string of at least eight non-zero bytes, and a 0x00 separator) and returns a distinct error result otherwise, and rsaes_pkcs1_decrypt/2 additionally returns {error, {badsize, _}} when the length check fails. The implementation applies no implicit-rejection countermeasure (RFC 8017 §7.2.2): it does not substitute a deterministic pseudo-random plaintext on a padding failure, so a one-bit padding-conformance signal leaks to the caller. Because the underlying modular exponentiation in dp/2 is a raw, non-blinded crypto:mod_pow/3, the padding check also stays distinguishable by timing even when an application normalizes every failure to a single error value. An unauthenticated attacker who knows only the public RSA key and can submit ciphertexts to a decryption endpoint that unwraps RSA1_5 JWE keys (or otherwise calls decrypt_private/3 with rsa_pkcs1_padding) can use this oracle to recover the plaintext of intercepted ciphertexts, such as content-encryption keys and thus the protected message, or to forge signatures, through roughly 10^4 to 10^6 adaptive chosen-ciphertext queries. This issue affects jose: from 1.3.0 before 1.11.13. | ||||
| CVE-2026-117604 | 1 Getgrav | 1 Grav | 2026-11-02 | 7.5 High |
| Grav from 1.7.53.3 before 1.7.53.6 contains an authorization bypass in Debugger::isDebuggerRequestAuthorized() that allows unauthenticated visitors to read /__clockwork/ profiler data via a loopback REMOTE_ADDR fallback. Behind a same-host reverse proxy, remote requests appear as loopback, letting attackers read stored records including administrator plaintext passwords and configuration credentials. | ||||
| CVE-2026-101181 | 1 Huawei | 1 Harmonyos | 2026-11-02 | 5.5 Medium |
| Permission control vulnerability in the WLAN module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2026-101178 | 1 Huawei | 2 Emui, Harmonyos | 2026-11-02 | 6.6 Medium |
| Permission control vulnerability in the autofill service module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-22424 | 1 Google | 1 Android | 2026-11-02 | 7.8 High |
| In multiple locations, there is a possible way to reveal images across users due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. | ||||
| CVE-2026-116478 | 1 A2aproject | 1 A2a-go | 2026-11-02 | 5.3 Medium |
| A vulnerability was detected in a2aproject a2a-go up to 2.4.0. This affects the function CreateExecutor of the file a2asrv/agentexec.go of the component Push Notification Handler. The manipulation results in information exposure through error message. It is possible to launch the attack remotely. Upgrading to version 2.5.0 mitigates this issue. The patch is identified as f4d588216b0c9520e94d571bab725c38ce23064c. It is recommended to upgrade the affected component. | ||||
| CVE-2026-116372 | 1 Misp | 1 Misp-guard | 2026-11-02 | N/A |
| MISP mispguard is a security filtering proxy that inspects and blocks MISP feed responses based on configured rules. The process_feed_response method in src/mispguard.py was responsible for evaluating feed responses before they reached the MISP instance. The original logic only explicitly handled the case where the HTTP status code was not 200 by passing the response through without filtering, on the assumption that non-200 responses would not carry ingestible event data. However, HTTP 2xx status codes other than 200 (such as 201 Created, 203 Non-Authoritative Information, and 206 Partial Content) were also passed through unfiltered. Because MISP may still ingest content from these responses, a malicious or compromised feed host could return a 203 or 206 status code with arbitrary content, effectively bypassing all of mispguard's filtering rules. This allowed unfiltered or malicious feed data to be ingested into the MISP instance, undermining the security controls that mispguard is designed to enforce. The vulnerability requires the attacker to control or compromise a feed endpoint configured in the MISP instance. No authentication or user interaction is required beyond the feed polling mechanism already in place. | ||||