Export limit exceeded: 10659 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10659 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-36984 | 1 Splunk | 2 Enterprise Security, Splunk | 2026-11-04 | 8.8 High |
| In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 on Windows, an authenticated user could execute a specially crafted query that they could then use to serialize untrusted data. The attacker could use the query to execute arbitrary code. | ||||
| CVE-2024-29847 | 1 Ivanti | 1 Endpoint Manager | 2026-11-04 | 9.8 Critical |
| Deserialization of untrusted data in the agent portal of Ivanti EPM before 2022 SU6, or the 2024 September update allows a remote unauthenticated attacker to achieve remote code execution. | ||||
| CVE-2024-53677 | 1 Apache | 1 Struts | 2026-11-04 | 9.8 Critical |
| File upload logic in Apache Struts is flawed. An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution. This issue affects Apache Struts: from 2.0.0 before 6.4.0. Users are recommended to upgrade to version 6.4.0 at least and migrate to the new file upload mechanism https://struts.apache.org/core-developers/file-upload . If you are not using an old file upload logic based on FileuploadInterceptor your application is safe. You can find more details in https://cwiki.apache.org/confluence/display/WW/S2-067 | ||||
| CVE-2024-37081 | 1 Vmware | 2 Cloud Foundation, Vcenter Server | 2026-11-04 | 7.8 High |
| The vCenter Server contains multiple local privilege escalation vulnerabilities due to misconfiguration of sudo. An authenticated local user with non-administrative privileges may exploit these issues to elevate privileges to root on vCenter Server Appliance. | ||||
| CVE-2024-37051 | 1 Jetbrains | 13 Aqua, Clion, Datagrip and 10 more | 2026-11-03 | 9.3 Critical |
| GitHub access token could be exposed to third-party sites in JetBrains IDEs after version 2023.1 and less than: IntelliJ IDEA 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; Aqua 2024.1.2; CLion 2023.1.7, 2023.2.4, 2023.3.5, 2024.1.3, 2024.2 EAP2; DataGrip 2023.1.3, 2023.2.4, 2023.3.5, 2024.1.4; DataSpell 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.2, 2024.2 EAP1; GoLand 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; MPS 2023.2.1, 2023.3.1, 2024.1 EAP2; PhpStorm 2023.1.6, 2023.2.6, 2023.3.7, 2024.1.3, 2024.2 EAP3; PyCharm 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.3, 2024.2 EAP2; Rider 2023.1.7, 2023.2.5, 2023.3.6, 2024.1.3; RubyMine 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP4; RustRover 2024.1.1; WebStorm 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.4 | ||||
| CVE-2024-32030 | 1 Provectus | 1 Ui | 2026-11-03 | 8.1 High |
| Kafka UI is an Open-Source Web UI for Apache Kafka Management. Kafka UI API allows users to connect to different Kafka brokers by specifying their network address and port. As a separate feature, it also provides the ability to monitor the performance of Kafka brokers by connecting to their JMX ports. JMX is based on the RMI protocol, so it is inherently susceptible to deserialization attacks. A potential attacker can exploit this feature by connecting Kafka UI backend to its own malicious broker. This vulnerability affects the deployments where one of the following occurs: 1. dynamic.config.enabled property is set in settings. It's not enabled by default, but it's suggested to be enabled in many tutorials for Kafka UI, including its own README.md. OR 2. an attacker has access to the Kafka cluster that is being connected to Kafka UI. In this scenario the attacker can exploit this vulnerability to expand their access and execute code on Kafka UI as well. Instead of setting up a legitimate JMX port, an attacker can create an RMI listener that returns a malicious serialized object for any RMI call. In the worst case it could lead to remote code execution as Kafka UI has the required gadget chains in its classpath. This issue may lead to post-auth remote code execution. This is particularly dangerous as Kafka-UI does not have authentication enabled by default. This issue has been addressed in version 0.7.2. All users are advised to upgrade. There are no known workarounds for this vulnerability. These issues were discovered and reported by the GitHub Security lab and is also tracked as GHSL-2023-230. | ||||
| CVE-2024-30104 | 1 Microsoft | 6 365 Apps, Office, Office 2016 and 3 more | 2026-11-03 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2024-28074 | 1 Solarwinds | 1 Access Rights Manager | 2026-11-03 | 9.6 Critical |
| It was discovered that a previous vulnerability was not completely fixed with SolarWinds Access Rights Manager. While some controls were implemented the researcher was able to bypass these and use a different method to exploit the vulnerability. | ||||
| CVE-2026-92190 | 2026-11-03 | N/A | ||
| Quest Foglight for Databases baseRmiServiceExporter Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Quest Foglight for Databases. Authentication is not required to exploit this vulnerability. The specific flaw exists within the configuration of the baseRmiServiceExporter bean. The issue results from the lack of proper validation of user-supplied data prior to deserializing it. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-29170. | ||||
| CVE-2026-64672 | 1 Gruntwork-io | 1 Terragrunt | 2026-11-03 | N/A |
| Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu or Terraform to scale. Prior to 1.1.1, the terragrunt catalog command derives a predictable per-repository catalog clone root under the shared system temporary directory and follows a symlink already placed at that path. A local attacker who can write to the temporary directory and predict the cataloged repository can redirect cleanup and cloning outside the intended root, causing an existing repository-named directory to be deleted and replaced in the victim's security context. The attack requires the victim to run terragrunt catalog on a shared host while the symlink is present, and it is not remotely exploitable. This issue is fixed in version 1.1.1. | ||||
| CVE-2026-52811 | 1 Gogs | 1 Gogs | 2026-11-03 | N/A |
| Gogs is an open source self-hosted Git service. Prior to 0.14.3, (*Repository).UploadRepoFiles checks for symlinks only on the leaf of the upload target (osx.IsSymlink(targetPath)). The siblings UpdateRepoFile, DeleteRepoFile, and GetDiffPreview use hasSymlinkInPath, which lstats every component — UploadRepoFiles is the lone outlier. An attacker with repo-write access plus a multipart upload whose filename contains a literal backslash (preserved by filepath.Base on Linux, then converted to / by pathx.Clean) redirects the write through a previously-committed directory symlink. iox.CopyFile opens the destination with os.Create (no O_NOFOLLOW), so the kernel follows the parent symlink and writes attacker bytes anywhere the gogs UID can write — ~git/.ssh/authorized_keys → SSH foothold, or <repo>.git/hooks/post-receive → next-push RCE. This vulnerability is fixed in 0.14.3. | ||||
| CVE-2026-115878 | 1 Stanfordnlp | 1 Stanza | 2026-11-03 | 7.8 High |
| Stanza is a Stanford NLP Python library for tokenization, sentence segmentation, NER, and parsing of many human languages. From 1.14.0 until 1.15.0, loading an attacker-supplied lemmatizer checkpoint can execute arbitrary code because stanza/models/lemma/trainer.py stores pos_dict as gzip-compressed pickle bytes and Trainer.load passes the decompressed stream to unrestricted pickle.loads. The outer torch.load call uses weights_only=True, but the nested bytes are treated as a primitive and are not inspected by that allowlist. The path is reachable during pipeline construction through a caller-influenced lemma_model_path, before inference begins. This issue is fixed in version 1.15.0. | ||||
| CVE-2026-73466 | 2026-11-03 | 6.3 Medium | ||
| On affected platforms running Arista EOS, under certain circumstances user passwordss may be written in clear text to log files during operations when specialized non-standard debugging trace levels are explicitly enabled. To exploit these vulnerabilities, a malicious actor must already possess authenticated local administrative access to the device shell, and specialized non-standard debugging trace levels must be explicitly enabled. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks. | ||||
| CVE-2026-7312 | 1 Progress | 1 Sitefinity | 2026-11-03 | 10 Critical |
| CWE‑522: Insufficiently Protected Credentials in web services in Progress Sitefinity version from 14.0.7700 to 14.4.8152, and 15.0.8200 to 15.0.8234, and 15.1.8300 to 15.1.8335, 15.2.8400 to 15.2.8441, 15.3.8500 to 15.3.8531, and 15.4.8600 to 15.4.8630 allows a remote unauthenticated attacker to obtain plain-text credentials used connect to Sitefinity Insight service. Successful exploitation requires active integration with Sitefinity Insight and non-default site configuration. | ||||
| 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. | ||||