Export limit exceeded: 357340 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 357340 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 357340 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (357340 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-7358 | 1 Getscreen | 1 Getscreen | 2026-04-15 | 7.8 High |
| A vulnerability was found in Point B Ltd Getscreen Agent 2.19.6 on Windows. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file getscreen.msi of the component Installation. The manipulation leads to creation of temporary file with insecure permissions. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier VDB-273337 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but was not able to provide a technical response in time. | ||||
| CVE-2024-6696 | 1 Hitachi | 1 Vantara Pentaho Business Analytics Server | 2026-04-15 | 4.9 Medium |
| The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets. (CWE-1220) Hitachi Vantara Pentaho Business Analytics Server versions before 10.2.0.0 and 9.3.0.9, including 8.3.x, do not correctly perform an authorization check in the user console trash content An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. | ||||
| CVE-2024-6162 | 1 Redhat | 11 Apache Camel Hawtio, Apache Camel Spring Boot, Build Keycloak and 8 more | 2026-04-15 | 7.5 High |
| A vulnerability was found in Undertow, where URL-encoded request paths can be mishandled during concurrent requests on the AJP listener. This issue arises because the same buffer is used to decode the paths for multiple requests simultaneously, leading to incorrect path information being processed. As a result, the server may attempt to access the wrong path, causing errors such as "404 Not Found" or other application failures. This flaw can potentially lead to a denial of service, as legitimate resources become inaccessible due to the path mix-up. | ||||
| CVE-2024-5971 | 1 Redhat | 12 Apache Camel Hawtio, Apache Camel Spring Boot, Build Keycloak and 9 more | 2026-04-15 | 7.5 High |
| A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed. The response headers and body were sent but the client would continue waiting as Undertow does not send the expected 0\r\n termination of the chunked response. This results in uncontrolled resource consumption, leaving the server side to a denial of service attack. This happens only with Java 17 TLSv1.3 scenarios. | ||||
| CVE-2024-56363 | 2026-04-15 | 7.8 High | ||
| APTRS (Automated Penetration Testing Reporting System) is a Python and Django-based automated reporting tool designed for penetration testers and security organizations. In 1.0, there is a vulnerability in the web application's handling of user-supplied input that is incorporated into a Jinja2 template. Specifically, when user input is improperly sanitized or validated, an attacker can inject Jinja2 syntax into the template, causing the server to execute arbitrary code. For example, an attacker might be able to inject expressions like {{ config }}, {{ self.class.mro[1].subclasses() }}, or more dangerous payloads that trigger execution of arbitrary Python code. The vulnerability can be reproduced by submitting crafted input to all the template fields handled by ckeditor, that are passed directly to a Jinja2 template. If the input is rendered without sufficient sanitization, it results in the execution of malicious Jinja2 code on the server. | ||||
| CVE-2024-54134 | 2026-04-15 | N/A | ||
| A publish-access account was compromised for `@solana/web3.js`, a JavaScript library that is commonly used by Solana dapps. This allowed an attacker to publish unauthorized and malicious packages that were modified, allowing them to steal private key material and drain funds from dapps, like bots, that handle private keys directly. This issue should not affect non-custodial wallets, as they generally do not expose private keys during transactions. This is not an issue with the Solana protocol itself, but with a specific JavaScript client library and only appears to affect projects that directly handle private keys and that updated within the window of 3:20pm UTC and 8:25pm UTC on Tuesday, December 3, 2024. These two unauthorized versions (1.95.6 and 1.95.7) were caught within hours and have since been unpublished. All Solana app developers should upgrade to version 1.95.8. Developers that suspect they might be compromised should rotate any suspect authority keys, including multisigs, program authorities, server keypairs, and so on. | ||||
| CVE-2024-54140 | 1 Sigstore | 1 Sigstore-java | 2026-04-15 | N/A |
| sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. This bug impacts clients using any variation of KeylessVerifier.verify(). Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients that are not monitors/witnesses is very low. This vulnerability is fixed in 1.2.0. | ||||
| CVE-2024-53858 | 1 Github | 1 Cli | 2026-04-15 | 6.5 Medium |
| The gh cli is GitHub’s official command line tool. A security vulnerability has been identified in the GitHub CLI that could leak authentication tokens when cloning repositories containing `git` submodules hosted outside of GitHub.com and ghe.com. This vulnerability stems from several `gh` commands used to clone a repository with submodules from a non-GitHub host including `gh repo clone`, `gh repo fork`, and `gh pr checkout`. These GitHub CLI commands invoke git with instructions to retrieve authentication tokens using the `credential.helper` configuration variable for any host encountered. Prior to version `2.63.0`, hosts other than GitHub.com and ghe.com are treated as GitHub Enterprise Server hosts and have tokens sourced from the following environment variables before falling back to host-specific tokens stored within system-specific secured storage: 1. `GITHUB_ENTERPRISE_TOKEN`, 2. `GH_ENTERPRISE_TOKEN` and 3. `GITHUB_TOKEN` when the `CODESPACES` environment variable is set. The result being `git` sending authentication tokens when cloning submodules. In version `2.63.0`, these GitHub CLI commands will limit the hosts for which `gh` acts as a credential helper to source authentication tokens. Additionally, `GITHUB_TOKEN` will only be used for GitHub.com and ghe.com. Users are advised to upgrade. Additionally users are advised to revoke authentication tokens used with the GitHub CLI and to review their personal security log and any relevant audit logs for actions associated with their account or enterprise | ||||
| CVE-2024-53845 | 1 Espressif | 1 Esp-idf | 2026-04-15 | N/A |
| ESPTouch is a connection protocol for internet of things devices. In the ESPTouchV2 protocol, while there is an option to use a custom AES key, there is no option to set the IV (Initialization Vector) prior to versions 5.3.2, 5.2.4, 5.1.6, and 5.0.8. The IV is set to zero and remains constant throughout the product's lifetime. In AES/CBC mode, if the IV is not properly initialized, the encrypted output becomes deterministic, leading to potential data leakage. To address the aforementioned issues, the application generates a random IV when activating the AES key starting in versions 5.3.2, 5.2.4, 5.1.6, and 5.0.8. This IV is then transmitted along with the provision data to the provision device. The provision device has also been equipped with a parser for the AES IV. The upgrade is applicable for all applications and users of ESPTouch v2 component from ESP-IDF. As it is implemented in the ESP Wi-Fi stack, there is no workaround for the user to fix the application layer without upgrading the underlying firmware. | ||||
| CVE-2024-54131 | 1 Kolide | 1 Launcher | 2026-04-15 | N/A |
| The Kolide Agent (aka: Launcher) is the lightweight agent designed to work with Kolide's service. An implementation bug in the Kolide Agent (known as `launcher`) allows for local privilege escalation to the SYSTEM user on Windows 10 and 11. The bug was introduced in version 1.5.3 when launcher started storing upgraded binaries in the ProgramData directory. This move to the new directory meant the launcher root directory inherited default permissions that are not as strict as the previous location. These incorrect default permissions in conjunction with an omitted SystemDrive environmental variable (when launcher starts osqueryd), allows a malicious actor with access to the local Windows device to successfully place an arbitrary DLL into the osqueryd process's search path. Under some circumstances, this DLL will be executed when osqueryd performs a WMI query. This combination of events could then allow the attacker to escalate their privileges to SYSTEM. Impacted versions include versions >= 1.5.3 and the fix has been released in 1.12.3. | ||||
| CVE-2024-53275 | 2026-04-15 | N/A | ||
| Home-Gallery.org is a self-hosted open-source web gallery to browse personal photos and videos. In 1.15.0 and earlier, the default setup of home-gallery is vulnerable to DNS rebinding. Home-gallery is set up without TLS and user authentication by default, leaving it vulnerable to DNS rebinding. In this attack, an attacker will ask a user to visit their website. The attacker website will then change the DNS records of their domain from their IP address to the internal IP address of the home-gallery instance. To tell which IP addresses are valid, we can rebind a subdomain to each IP address we want to check, and see if there is a response. Once potential candidates have been found, the attacker can launch the attack by reading the response of the web server after the IP address has changed. When the attacker domain is fetched, the response will be from the home-gallery instance, not the attacker website, because the IP address has been changed. Due to a lack of authentication, home-gallery photos can then be extracted by the attacker website. | ||||
| CVE-2024-53267 | 1 Sigstore | 1 Sigstore-java | 2026-04-15 | 5.5 Medium |
| sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log. This bug impacts clients using any variation of KeylessVerifier.verify(). The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. The signer's identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass. sigstore-gradle-plugin and sigstore-maven-plugin are not affected by this as they only provide signing functionality. This issue has been patched in v1.1.0 release with PR #856. All users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-53259 | 1 Redhat | 2 Acm, Ansible Automation Platform | 2026-04-15 | 6.5 Medium |
| quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2. | ||||
| CVE-2024-52288 | 2026-04-15 | 5.1 Medium | ||
| libosdp is an implementation of IEC 60839-11-5 OSDP (Open Supervised Device Protocol) and provides a C library with support for C++, Rust and Python3. In affected versions an unexpected `REPLY_CCRYPT` or `REPLY_RMAC_I` may be introduced into an active stream when they should not be. Once RMAC_I message can be sent during a session, attacker with MITM access to the communication may intercept the original RMAC_I reply and save it. While the session continues, the attacker will record all of the replies and save them, till capturing the message to be replied (can be detected by ID, length or time based on inspection of visual activity next to the reader) Once attacker captures a session with the message to be replayed, he stops resetting the connection and waits for signal to perform the replay to of the PD to CP message (ex: by signaling remotely to the MIMT device or setting a specific timing). In order to replay, the attacker will craft a specific RMAC_I message in the proper seq of the execution, which will result in reverting the RMAC to the beginning of the session. At that phase - attacker can replay all the messages from the beginning of the session. This issue has been addressed in commit `298576d9` which is included in release version 3.0.0. Users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-52286 | 1 Stirlingpdf | 1 Stirling Pdf | 2026-04-15 | N/A |
| Stirling-PDF is a locally hosted web application that allows you to perform various operations on PDF files. In affected versions the Merge functionality takes untrusted user input (file name) and uses it directly in the creation of HTML pages allowing any unauthenticated to execute JavaScript code in the context of the user. The issue stems to the code starting at `Line 24` in `src/main/resources/static/js/merge.js`. The file name is directly being input into InnerHTML with no sanitization on the file name, allowing a malicious user to be able to upload files with names containing HTML tags. As HTML tags can include JavaScript code, this can be used to execute JavaScript code in the context of the user. This is a self-injection style attack and relies on a user uploading the malicious file themselves and it impact only them, not other users. A user might be social engineered into running this to launch a phishing attack. Nevertheless, this breaks the expected security restrictions in place by the application. This issue has been addressed in version 0.32.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-51992 | 2026-04-15 | 4.1 Medium | ||
| Orchid is a @laravel package that allows for rapid application development of back-office applications, admin/user panels, and dashboards. This vulnerability is a method exposure issue (CWE-749: Exposed Dangerous Method or Function) in the Orchid Platform’s asynchronous modal functionality, affecting users of Orchid Platform version 8 through 14.42.x. Attackers could exploit this vulnerability to call arbitrary methods within the `Screen` class, leading to potential brute force of database tables, validation checks against user credentials, and disclosure of the server’s real IP address. The issue has been patched in the latest release, version 14.43.0, released on November 6, 2024. Users should upgrade to version 14.43.0 or later to address this vulnerability. If upgrading to version 14.43.0 is not immediately possible, users can mitigate the vulnerability by implementing middleware to intercept and validate requests to asynchronous modal endpoints, allowing only approved methods and parameters. | ||||
| CVE-2024-51989 | 1 Apnotic Llc | 1 Passwordpusher | 2026-04-15 | 7.1 High |
| Password Pusher is an open source application to communicate sensitive information over the web. A cross-site scripting (XSS) vulnerability was identified in the PasswordPusher application, affecting versions `v1.41.1` through and including `v.1.48.0`. The issue arises from an un-sanitized parameter which could allow attackers to inject malicious JavaScript into the application. Users who self-host and have the login system enabled are affected. Exploitation of this vulnerability could expose user data, access to user sessions or take unintended actions on behalf of users. To exploit this vulnerability, an attacker would need to convince a user to click a malicious account confirmation link. It is highly recommended to update to version `v1.48.1` or later to mitigate this risk. There are no known workarounds for this vulnerability. ### Solution Update to version `v1.48.1` or later where input sanitization has been applied to the account confirmation process. If updating is not immediately possible, | ||||
| CVE-2024-51758 | 1 Filament | 1 Excel Export | 2026-04-15 | N/A |
| Filament is a collection of full-stack components for accelerated Laravel development. All Filament features that interact with storage use the `default_filesystem_disk` config option. This allows the user to easily swap their storage driver to something production-ready like `s3` when deploying their app, without having to touch multiple configuration options and potentially forgetting about some. The default disk is set to `public` when you first install Filament, since this allows users to quickly get started developing with a functional disk that allows features such as file upload previews locally without the need to set up an S3 disk with temporary URL support. However, some features of Filament such as exports also rely on storage, and the files that are stored contain data that should often not be public. This is not an issue for the many deployed applications, since many use a secure default disk such as S3 in production. However, [CWE-1188](https://cwe.mitre.org/data/definitions/1188.html) suggests that having the `public` disk as the default disk in Filament is a security vulnerability itself. As such, we have implemented a measure to protect users whereby if the `public` disk is set as the default disk, the exports feature will automatically swap it out for the `local` disk, if that exists. Users who set the default disk to `local` or `s3` already are not affected. If a user wants to continue to use the `public` disk for exports, they can by setting the export disk deliberately. This change has been included in the 3.2.123 release and all users who use the `public` disk are advised to upgrade. | ||||
| CVE-2024-51746 | 1 Sigstore | 1 Gitsign | 2026-04-15 | 2.5 Low |
| Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder. | ||||
| CVE-2024-51501 | 1 Reactiveui | 1 Refit | 2026-04-15 | N/A |
| Refit is an automatic type-safe REST library for .NET Core, Xamarin and .NET The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection. The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method. This method does not check for CRLF characters in the header value. This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery. Strictly speaking this is a potential vulnerability in applications using Refit and not in Refit itself. This issue has been addressed in release versions 7.2.22 and 8.0.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||