Export limit exceeded: 418975 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (418975 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-121062 1 Google 1 Chrome 2026-11-03 N/A
Incorrect authorization in API in Google Chrome prior to 157.0.8103.38 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121040 1 Google 1 Chrome 2026-11-03 N/A
Incorrect authorization in Core in Google Chrome prior to 157.0.8103.38 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121030 1 Google 1 Chrome 2026-11-03 N/A
Incorrect authorization in DevTools in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121048 1 Google 1 Chrome 2026-11-03 N/A
Race condition in V8 in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121042 2026-11-03 N/A
Incorrect authorization in Permissions in Google Chrome on on Android prior to 157.0.8103.38 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121049 2026-11-03 N/A
Out of bounds read in V8 in Google Chrome prior to 157.0.8103.38 allowed a local attacker to read memory via a crafted file. (Chromium security severity: Medium)
CVE-2026-121053 2026-11-03 N/A
UI misrepresentation in Transactions Platform in Google Chrome on on Android prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121046 2026-11-03 N/A
Incorrect authorization in WebAppInstalls in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to spoof address bar via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121043 1 Google 1 Chrome 2026-11-03 N/A
UI misrepresentation in Payments in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121055 2026-11-03 N/A
Incomplete cleanup in DevTools in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass system access restrictions via a crafted Chrome extension. (Chromium security severity: Low)
CVE-2026-121045 2026-11-03 N/A
UI misrepresentation in Browser in Google Chrome on on Mac prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121029 2026-11-03 N/A
Incorrect authorization in ORB in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass site isolation via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121041 1 Google 1 Chrome 2026-11-03 N/A
Missing authorization in Input in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-121063 1 Google 1 Chrome 2026-11-03 N/A
Incorrect authorization in CacheStorage in Google Chrome prior to 157.0.8103.38 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-121039 1 Google 1 Chrome 2026-11-03 N/A
Incorrect authorization in Proxy Auth in Google Chrome prior to 157.0.8103.38 allowed an adjacent attacker to obtain sensitive information via crafted network traffic. (Chromium security severity: Medium)
CVE-2026-121059 1 Google 1 Chrome 2026-11-03 N/A
Information leak in Core in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-22058 2026-11-03 N/A
StorageGRID (formerly StorageGRID Webscale) versions 11.3 and higher allow an attacker with product-specific knowledge and the ability to communicate with the Grid Network on certain ports to make unauthorized requests.
CVE-2026-84180 1 Apache 2 Apache Camel, Camel 2026-11-03 5.3 Medium
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Knative component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. When processing of an exchange failed on the consumer side, the Knative HTTP consumer wrote the resulting exception back to the remote caller as the response body, including its class name, message and stack trace. An external sender could therefore provoke a failure and read internal detail about the deployment: class and package names, file system or host names carried in exception messages, and the shape of the route. That detail is useful for building a more targeted attack, and where an exception message embeds configuration or connection strings it is disclosure in its own right. camel-knative was the remaining HTTP-family consumer that had not been aligned with the muteException behaviour established for the other HTTP consumers by CAMEL-23651. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The consumer now honours a muteException option that defaults to true, so a route failure returns an empty body with the error status rather than the exception. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, add an onException handler that sets the response body explicitly, so that the framework never writes the exception back to the caller.
CVE-2026-84181 1 Apache 2 Apache Camel, Camel 2026-11-03 5.9 Medium
Improper Authentication vulnerability in Apache Camel Shiro component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Shiro security processor skipped credential verification when the subject already bound to the current thread carried the same principal as the incoming exchange. Because the thread that carries a Camel exchange is drawn from a pool and reused across exchanges, a subject left bound by an earlier authenticated exchange could satisfy the check for a later one that presented no valid credentials of its own. The password on the incoming exchange was, in that case, never verified. The condition depends on thread reuse and on the principal matching, which is why it is not reached on every request, but it requires nothing of the attacker beyond sending a request naming a principal that is in active use. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The processor now verifies the presented credentials on every exchange rather than accepting a subject already bound to the thread. Setting alwaysReauthenticate=false restores the previous behaviour for deployments that depend on it. For deployments that cannot upgrade immediately, ensure the Shiro subject is cleared from the thread at the end of every exchange so that no subject can be inherited by a later one.
CVE-2026-85243 1 Apache 2 Apache Camel, Camel 2026-11-03 5.9 Medium
Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.