Export limit exceeded: 419390 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419390 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-120952 | 1 Mongodb | 1 Atlas Sql Odbc Driver | 2026-11-03 | 7.1 High |
| An out-of-bounds write in the MongoDB Atlas SQL ODBC Driver may be triggered when a value of a particular database type is retrieved into a fixed-width client-side target. The driver produces a textual form of the value that is longer than the fixed target the ODBC interface defines, and copies it without limiting the copy to the target's real size. A database user with basic write privileges can influence part of the data written outside the target, which may corrupt memory in the application using the driver and cause that application to terminate unexpectedly. | ||||
| CVE-2026-120715 | 1 Devolutions | 1 Server | 2026-11-03 | N/A |
| Server-side request forgery in the Active Directory credential validation in Devolutions Server 2026.3.12.0 and earlier allows an authenticated low-privileged user to capture the NetNTLMv2 hash of the DVLS service account via an attacker-controlled domain name in the request. | ||||
| CVE-2026-120734 | 1 Devolutions | 1 Server | 2026-11-03 | N/A |
| Cleartext transmission of sensitive information in the email configuration test in Devolutions Server 2026.3.13.0 and earlier allows an authenticated user with access to the test action to obtain the stored SMTP password via a request that names an attacker-controlled SMTP host. | ||||
| CVE-2026-115731 | 2026-11-03 | 9.9 Critical | ||
| Deserialization of untrusted data in the report-processing code of Puppet, as used by Puppet Server, in the affected releases, allows a client that holds any CA-signed agent certificate to execute arbitrary code on the Puppet Server as its service user by submitting a report containing a crafted rich-data type via PUT request. Where the certificate authority autosigns requests without strong verification, an unauthenticated network attacker can obtain such a certificate. | ||||
| CVE-2026-120716 | 1 Devolutions | 1 Server | 2026-11-03 | N/A |
| Insertion of sensitive information into sent data in the identity provider user synchronization in Devolutions Server 2026.3.13.0 and earlier allows an authenticated user with the delegated permission to update users from the identity provider to obtain other users' MFA secrets via the synchronization API response. | ||||
| CVE-2026-121066 | 1 Google | 1 Chrome | 2026-11-03 | N/A |
| Incorrect authorization in Extensions in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted Chrome extension. (Chromium security severity: Medium) | ||||
| CVE-2026-121051 | 1 Google | 1 Chrome | 2026-11-03 | N/A |
| UI misrepresentation in iOSWeb in Google Chrome on on iOS prior to 157.0.8103.38 allowed a remote attacker to spoof address bar via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-121032 | 1 Google | 1 Chrome | 2026-11-03 | N/A |
| Out of bounds read in Skia in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-115541 | 1 Humhub | 1 Humhub Community Edition | 2026-11-03 | N/A |
| HumHub Community Edition 1.19.0 contains a stored cross-site scripting vulnerability in the friendship confirmation dialog. An authenticated low-privileged member can save HTML in their first and last name. When another authenticated user clicks Friends for that profile, HumHub places the decoded display name into a modal through jQuery html(), causing attacker-controlled markup to execute in the victim's HumHub origin. | ||||
| CVE-2026-121614 | 1 Docker | 1 Docker Sandboxes | 2026-11-03 | N/A |
| Docker Sandboxes versions 0.31.0 before 0.50.0 do not neutralize repository-controlled Git configuration when running certain host-side Git commands. An attacker who can modify a host repository's Git configuration, for example through a direct-mode sandbox with the repository mounted read-write, can configure core.fsmonitor or another Git setting that invokes an external program. Git can execute the program during a later clone-mode fetch or, starting in version 0.39.0, an sbx kit push initiated by the user. The program runs on the host with the invoking user's permissions, outside the sandbox's microVM isolation. The read-only host repository mount provided to a clone-mode sandbox does not itself allow that sandbox to modify the host repository's Git configuration. The issue is fixed in version 0.50.0. | ||||
| CVE-2025-0077 | 1 Google | 1 Android | 2026-11-03 | 4 Medium |
| In multiple functions of UserController.java, there is a possible lock screen bypass due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2024-49731 | 1 Google | 2 Android, Pixel Watch | 2026-11-03 | 4 Medium |
| In apk-versions.txt, there is a possible corruption of telemetry opt-in settings on other watches when setting up a new Pixel Watch due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. | ||||
| 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-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. | ||||
| CVE-2026-85245 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 5.9 Medium |
| Exposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message's values, so content belonging to one sender could be read while processing another sender's message, and concurrent exchanges could observe each other's partially written state. In a deployment that serves more than one tenant or user through the same route, that is disclosure of one party's data to another. 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. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to the returned object. | ||||
| CVE-2026-85246 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 5.3 Medium |
| Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina 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, the Mina consumer wrote exchange.getException() straight back over the socket to the remote peer. Over a textline codec that hands the peer the exception's class name and message; over the object codec it hands over the serialised exception, cause chain included. A remote peer able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever a message or nested cause happens to carry, which in practice can include paths, host names and connection detail. The consumer had no option to suppress this, unlike the HTTP-family consumers aligned 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. A muteException consumer option, defaulting to true, replaces the route exception with a generic one carrying no class name, message or stack trace, while still writing a reply so that a synchronous peer is not left to time out. Set muteException=false to restore the previous behaviour. For deployments that cannot upgrade immediately, add an onException handler that sets the reply body explicitly, so the framework never writes the exception back to the peer. | ||||
| CVE-2026-85247 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 5.9 Medium |
| Improper Certificate Validation 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 SSL was enabled on the Knative HTTP client but no truststore was configured, the client options fell back to trusting every presented certificate rather than to the JVM's default trust anchors. A deployment that switched TLS on without also configuring a truststore therefore obtained an encrypted connection with no peer authentication, which an attacker positioned on the network path can terminate and read. The dangerous state is reached by omission rather than by an explicit opt-in, which is what makes it a framework defect: turning TLS on should not be the thing that turns certificate validation off. 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. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate. For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately. | ||||