Export limit exceeded: 363527 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (363527 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-14389 | 1 Google | 1 Chrome | 2026-07-06 | 8.3 High |
| Integer overflow in Skia in Google Chrome prior to 150.0.7871.46 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-14430 | 1 Google | 1 Chrome | 2026-07-06 | 8.8 High |
| Integer overflow in V8 in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-14384 | 1 Google | 1 Chrome | 2026-07-06 | 6.5 Medium |
| Out of bounds read in ANGLE in Google Chrome on Windows prior to 150.0.7871.46 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-14416 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Out of bounds read in Dawn in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-14397 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Out of bounds write in ANGLE in Google Chrome on Mac prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-14399 | 1 Google | 1 Chrome | 2026-07-06 | 6.5 Medium |
| Uninitialized Use in Dawn in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-14405 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Uninitialized Use in V8 in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-14425 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Use after free in ANGLE in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-14424 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Use after free in Dawn in Google Chrome on Mac prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-14417 | 1 Google | 1 Chrome | 2026-07-06 | 9.6 Critical |
| Use after free in Dawn in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical) | ||||
| CVE-2026-14393 | 1 Google | 1 Chrome | 2026-07-06 | 8.8 High |
| Use after free in V8 in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-14394 | 1 Google | 1 Chrome | 2026-07-06 | 8.8 High |
| Use after free in V8 in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-14426 | 1 Google | 1 Chrome | 2026-07-06 | 7.5 High |
| Use after free in V8 in Google Chrome prior to 150.0.7871.46 allowed a remote attacker who convinced a user to engage in specific UI gestures to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-38968 | 1 Ntop | 1 Ntopng | 2026-07-06 | N/A |
| ntopng through 6.6 is vulnerable to Predictable Session Identifier which can lead to Session Hijacking. HTTP session identifiers in src/HTTPserver.cpp use weak time-seeded pseudo-randomness during session creation. As a result, fresh authenticated logins can receive deterministic or colliding session cookies under attacker-controlled timing. | ||||
| CVE-2026-38971 | 1 Ardupilot | 1 Ardupilot | 2026-07-06 | N/A |
| ardupilot through Plane-4.6.3 was found to contain an out-of-bounds read issue in libraries/GCS_MAVLink/GCS_serial_control.cpp in GCS_MAVLINK::handle_serial_control(). | ||||
| CVE-2026-40859 | 1 Apache | 1 Camel | 2026-07-06 | N/A |
| Deserialization of Untrusted Data vulnerability in Apache Camel. The camel-vertx-http component deserializes HTTP response bodies carrying the Content-Type application/x-java-serialized-object using a raw java.io.ObjectInputStream, without applying any ObjectInputFilter (VertxHttpHelper.deserializeJavaObjectFromStream) This deserialization path is reached only when the producer endpoint is configured with transferException=true (or the component-level allowJavaSerializedObject=true) and throwExceptionOnFailure is left at its default value of true; in that case a backend HTTP response with a 5xx status and the application/x-java-serialized-object content type has its body deserialized with no class restrictions. An attacker who controls the backend the Camel producer talks to - through a man-in-the-middle position on an unencrypted (plain HTTP) connection, or by compromising the backend service - can return a crafted serialized Java object and, if a suitable gadget chain is present on the classpath, achieve remote code execution on the Camel application host. The path is not reachable in the default configuration, where transferException is false. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, the deserialization performed by both helper utilities is constrained by a default ObjectInputFilter (allow-list java.**;javax.**;org.apache.camel.**;!*), which can be customised through the new deserializationFilter endpoint option or the JVM-wide -Djdk.serialFilter system property. For deployments that cannot upgrade immediately: do not enable transferException=true (or allowJavaSerializedObject=true) on producers that talk to untrusted or network-reachable backends; ensure producer connections use TLS (https) so that a response cannot be substituted by a man-in-the-middle; and, where the option is required, set an explicit -Djdk.serialFilter allow-list (for example java.**;org.apache.camel.**;!*) to constrain deserialization. | ||||
| CVE-2026-14544 | 1 Redhat | 1 Enterprise Linux | 2026-07-06 | 9.8 Critical |
| A flaw was found in HPLIP (HP Linux Imaging and Printing Software). This vulnerability, an incomplete fix for CVE-2026-8631, may allow a remote attacker to escalate privileges or achieve arbitrary code execution. This can occur through an integer overflow in the hpcups processing path when handling specially crafted print data. | ||||
| CVE-2026-14781 | 1 Redhat | 4 Build Keycloak, Jboss Data Grid, Jbosseapxp and 1 more | 2026-07-06 | 4.8 Medium |
| A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token's email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default). The userinfo endpoint must be enabled (default). The attacker must control or have compromised the upstream OIDC provider. Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database. Bypass email-based security controls or verification workflows. Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts. | ||||
| CVE-2026-54893 | 1 Swoosh | 1 Swoosh | 2026-07-06 | N/A |
| URL path injection in the Microsoft Graph adapter of Swoosh. Swoosh.Adapters.MsGraph builds its Microsoft Graph API request URL by interpolating the sender's email address into the URL path (/users/{from}/sendMail) without percent-encoding or validation. In applications that derive the from address from untrusted or user-influenced input (for example a relay, a contact form, or a "send as" feature), an attacker can place URL-special characters such as /, ?, or # in the local part of the address to escape the intended path segment and rewrite the path and query string of the request. Because the same authenticated POST is sent with the application's Microsoft Graph bearer token, the attacker can redirect it to other Graph endpoints within the token's scopes and control the request's query string. Applications that always use a fixed, trusted from address are not affected. This issue affects swoosh from 1.12.0 before 1.26.3. | ||||
| CVE-2026-55153 | 1 Swaldman | 1 Mchange-commons-java | 2026-07-06 | 7.1 High |
| mchange-commons-java is a Java library of shared utility classes used by mchange projects like the c3p0 connection pool. Prior to version 0.6.0, its JNDI ObjectFactory implementation (com.mchange.v2.naming.JavaBeanObjectFactory) will construct objects of arbitrary classes and initialize "JavaBean"-style properties, which for certain classes enables JNDI injection and "deserialization gadgets." Such initialization is unsafe for some classes: for example, setting the contentType property of a Swing JEditorPane to text/html and its text property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. The problem is aggravated by the library's ReferenceIndirector, through which malicious JNDI Reference objects can be smuggled in for dereferencing wherever an application reads a Java-serialized object. This has been resolved in version 0.6.0. | ||||