Export limit exceeded: 10620 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10620 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-64408 | 1 Apache | 1 Causeway | 2026-11-03 | 6.3 Medium |
| Apache Causeway faces Java deserialization vulnerabilities that allow remote code execution (RCE) through user-controllable URL parameters. These vulnerabilities affect all applications using Causeway's ViewModel functionality and can be exploited by authenticated attackers to execute arbitrary code with application privileges. This issue affects all current versions. Users are recommended to upgrade to version 3.5.0, which fixes the issue. | ||||
| CVE-2025-4234 | 3 Microsoft, Palo Alto, Paloaltonetworks | 5 365, Networks, Cortex Xdr and 2 more | 2026-11-03 | N/A |
| A problem with the Palo Alto Networks Cortex XDR Microsoft 365 Defender Pack can result in exposure of user credentials in application logs. Normally, these application logs are only viewable by local users and are included when generating logs for troubleshooting purposes. This means that these credentials are exposed to recipients of the application logs. | ||||
| CVE-2025-1697 | 1 Hp | 1 Touchpoint Analytics Service | 2026-11-03 | 7.8 High |
| A potential security vulnerability has been identified in the HP Touchpoint Analytics Service for certain HP PC products with versions prior to 4.2.2439. This vulnerability could potentially allow a local attacker to escalate privileges. HP is providing software updates to mitigate this potential vulnerability. | ||||
| 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-85260 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 5.5 Medium |
| Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records. 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. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly. | ||||
| CVE-2026-85317 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 4.8 Medium |
| Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low. 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 cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache. | ||||
| CVE-2026-88900 | 1 Apache | 2 Apache Camel, Camel | 2026-11-03 | 8.8 High |
| Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster's multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel's receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster's multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical. 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.1. 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 those lines must move to a supported release. | ||||
| CVE-2026-112432 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-11-03 | 6.2 Medium |
| A logging issue was addressed with improved data redaction. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to access sensitive user data. | ||||
| CVE-2026-89292 | 2026-11-03 | N/A | ||
| In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures. | ||||
| CVE-2026-76654 | 1 Kubernetes | 1 Kubelet | 2026-11-03 | 5.8 Medium |
| An NTLM coercion vulnerability exists on Windows nodes when the subPath supplied in a pod's volumeMounts is set to a symbolic link that points to an attacker-controlled network share. When a kubelet resolves symlinks, it does not reject a target that resolves to a UNC path. As a result, the kubelet will transparently attempt to authenticate to the share using NTLM. This allows an attacker to obtain the NetNTLMv2 hash of the account under which the kubelet is running. An attacker could then attempt to crack the hash to retrieve the corresponding password or relay it to impersonate the node, if the node is domain-joined. | ||||
| CVE-2026-121023 | 1 Axxonsoft | 1 Axxonnet Arp Agent | 2026-11-03 | 5.5 Medium |
| Insertion of Sensitive Information into Log File (CWE-532) in the ARP Agent component in AxxonSoft AxxonNet before 3.25.0 on Windows and Linux allows a local attacker with read access to ARP Agent log files or support packages to obtain the plaintext password of the LDAP directory service account via WARNING-level log entries that contain serialized user synchronization data. | ||||
| CVE-2026-120673 | 1 Mongodb | 1 Rust Driver | 2026-11-03 | 5.5 Medium |
| A component of the MongoDB Rust Driver that records diagnostic tracing data can capture command content before automatic client-side field level encryption is applied. In deployments that turn on the optional tracing capability together with automatic in-use encryption, a party with read access to the application's exported trace data may obtain field values that the application designated for encryption, without access to the encryption keys. This may result in unintended disclosure of data. | ||||
| CVE-2026-63417 | 1 Armurox | 1 Logging Redactor | 2026-11-03 | N/A |
| Logging Redactor is a Python library designed to redact sensitive data in logs based on regex patterns and / or dictionary keys. Prior to 0.0.7, personally identifiable information returned by custom object __str__ or __repr__ methods is not redacted when such non-primitive objects are logged, causing sensitive values to appear in logs that are expected to mask them. This issue is fixed in version 0.0.7. | ||||
| CVE-2026-118489 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-03 | 7.5 High |
| In Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users — the documented pattern of a per-user `WebClientSession` over a shared caching client — a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking. | ||||
| CVE-2026-113733 | 2 Django Project, Djangoproject | 2 Django, Django | 2026-11-03 | 2.2 Low |
| An issue was discovered in Django 6.1 before 6.1.3 and 6.0 before 6.0.10. The `django.contrib.admin.utils.display_for_field()` function did not obfuscate the password field of user models other than `AUTH_USER_MODEL`, or of an `AUTH_USER_MODEL` inheriting its password field from a concrete parent model through multi-table inheritance, which allows authenticated staff users with only the view permission on such a model to obtain full password hashes via the read-only change form. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Aaron chen for reporting this issue. | ||||
| CVE-2026-113593 | 2 Django Project, Djangoproject | 2 Django, Django | 2026-11-03 | 3.1 Low |
| An issue was discovered in Django 6.1 before 6.1.3, 6.0 before 6.0.10, and 5.2 before 5.2.19. The `django.middleware.cache.UpdateCacheMiddleware` and the `django.views.decorators.cache.cache_page()` decorator generate identical cache keys for requests that omit a header listed in the response’s `Vary` header and requests that include that header with an empty value, potentially allowing remote attackers to access private data cached for another request. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Andrew Gonzalez for reporting this issue. | ||||
| CVE-2026-109220 | 2026-11-03 | 9.8 Critical | ||
| The PDF Invoice for WooCommerce + Drag and Drop Template Builder plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 7.1.1 via the 'customer_note' parameter parameter. This is due to insufficient sanitization of the customer_note checkout field, which is inlined verbatim into invoice HTML, entity-decoded back into a live tag by simplehtmldom, reassembled into raw bytes by mPDF, and passed to unserialize() in _getObjAttr without validation. This makes it possible for unauthenticated attackers to execute code on the server. An unauthenticated attacker can trigger the vulnerable code path on a default install by placing an anonymous WooCommerce checkout via the public Store API (POST /wc/store/v1/checkout) using a Direct Bank Transfer or cheque payment method, which automatically transitions the order to 'on-hold' status and fires the plugin's invoice-generation hook. | ||||
| CVE-2026-102435 | 2026-11-03 | 9.8 Critical | ||
| The Ultra Addons for Contact Form 7 plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the _getObjAttr function in all versions up to, and including, 3.5.54. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). This requires the PDF Generator add-on to be active and a Contact Form 7 form to be configured for PDF generation, as the WPCF7_Submission POP gadget chain relies on CF7 being present to complete the file deletion via __destruct(). Note: This vulnerability can only be exploited when the PDF generator feature is enabled. | ||||
| CVE-2026-102709 | 1 Eclipse | 1 Threadx | 2026-11-03 | N/A |
| In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the four non-secure-callable secure stack functions of the TrustZone-M ports dereference a thread pointer supplied by the non-secure world without checking that it points to non-secure memory. Non-secure code can make the secure firmware reveal which secure bytes are zero, write chosen secure words, and fault the secure world, breaking TrustZone-M isolation and enabling recovery of secure-world secrets such as cryptographic keys. | ||||
| CVE-2026-115710 | 1 Elastic | 1 Elasticsearch | 2026-11-03 | 4.2 Medium |
| Use of Cache Containing Sensitive Information (CWE-524) in Elasticsearch can lead to information disclosure and incorrect search results via specially crafted search requests. For some query types, Elasticsearch can share cached query results between users who have field-level security restrictions and users who do not. A user restricted by field-level security can learn which documents match a value in a field that they cannot read. A restricted user can also cause users with full access to receive incomplete search results. Disclosure is only possible when a user with full access ran the same query on the same shard recently. | ||||