Export limit exceeded: 360698 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (360698 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2018-25126 | 1 Tvt | 1 Nvms-9000 Firmware | 2026-04-15 | N/A |
| Shenzhen TVT Digital Technology Co., Ltd. NVMS-9000 firmware (used by many white-labeled DVR/NVR/IPC products) contains hardcoded API credentials and an OS command injection flaw in its configuration services. The web/API interface accepts HTTP/XML requests authenticated with a fixed vendor credential string and passes user-controlled fields into shell execution contexts without proper argument sanitization. An unauthenticated remote attacker can leverage the hard-coded credential to access endpoints such as /editBlackAndWhiteList and inject shell metacharacters inside XML parameters, resulting in arbitrary command execution as root. The same vulnerable backend is also reachable in some models through a proprietary TCP service on port 4567 that accepts a magic GUID preface and base64-encoded XML, enabling the same command injection sink. Firmware releases from mid-February 2018 and later are reported to have addressed this issue. Exploitation evidence was observed by the Shadowserver Foundation on 2025-01-28 UTC. | ||||
| CVE-2016-15047 | 1 Avtech | 3 Dvr Devices, Ip Camera, Nvr Devices | 2026-04-15 | N/A |
| AVTECH devices that include the CloudSetup.cgi management endpoint are vulnerable to authenticated OS command injection. The `exefile` parameter in CloudSetup.cgi is passed to the underlying system command execution without proper validation or whitelisting. An authenticated attacker who can invoke this endpoint can supply crafted input to execute arbitrary system commands as root. Successful exploitation grants full control of the device, and - depending on deployment and whether the device stores credentials or has network reachability to internal systems - may enable credential theft, lateral movement, or data exfiltration. The archived SEARCH-LAB disclosure implies that this vulnerability was remediated in early 2017, but AVTECH has not defined an affected version range. | ||||
| CVE-2025-40107 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from sleep before interface was brought up"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks. | ||||
| CVE-2025-30168 | 1 Parse Community | 1 Parse Server | 2026-04-15 | 6.9 Medium |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 7.5.2 and 8.0.2, the 3rd party authentication handling of Parse Server allows the authentication credentials of some specific authentication providers to be used across multiple Parse Server apps. For example, if a user signed up using the same authentication provider in two unrelated Parse Server apps, the credentials stored by one app can be used to authenticate the same user in the other app. Note that this only affects Parse Server apps that specifically use an affected 3rd party authentication provider for user authentication, for example by setting the Parse Server option auth to configure a Parse Server authentication adapter. The fix of this vulnerability requires to upgrade Parse Server to a version that includes the bug fix, as well as upgrade the client app to send a secure payload, which is different from the previous insecure payload. This vulnerability is fixed in 7.5.2 and 8.0.2. | ||||
| CVE-2025-24363 | 1 Hl7 | 1 Fhir Ig Publisher | 2026-04-15 | 4.2 Medium |
| The HL7 FHIR IG publisher is a tool to take a set of inputs and create a standard FHIR IG. Prior to version 1.8.9, in CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. This problem has been patched in release 1.8.9. Some workarounds are available. Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token; or users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no username, password, or token. | ||||
| CVE-2025-12626 | 1 Jeecg | 1 Jeecgboot | 2026-04-15 | 4.3 Medium |
| A security flaw has been discovered in jeecgboot jeewx-boot up to 641ab52c3e1845fec39996d7794c33fb40dad1dd. This affects the function getImgUrl of the file WxActGoldeneggsPrizesController.java. Performing manipulation of the argument imgurl results in path traversal. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The root cause was initially fixed but can be evaded with additional encoding. | ||||
| CVE-2025-11030 | 1 Tutorials-website | 1 Employee Management System | 2026-04-15 | 7.3 High |
| A vulnerability was detected in Tutorials-Website Employee Management System up to 611887d8f8375271ce8abc704507d46340837a60. Impacted is an unknown function of the file /admin/all-applied-leave.php of the component HTTP Request Handler. The manipulation results in improper authorization. The attack may be performed from remote. The exploit is now public and may be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. | ||||
| CVE-2024-56331 | 2026-04-15 | 6.8 Medium | ||
| Uptime Kuma is an open source, self-hosted monitoring tool. An **Improper URL Handling Vulnerability** allows an attacker to access sensitive local files on the server by exploiting the `file:///` protocol. This vulnerability is triggered via the **"real-browser"** request type, which takes a screenshot of the URL provided by the attacker. By supplying local file paths, such as `file:///etc/passwd`, an attacker can read sensitive data from the server. This vulnerability arises because the system does not properly validate or sanitize the user input for the URL field. Specifically: 1. The URL input (`<input data-v-5f5c86d7="" id="url" type="url" class="form-control" pattern="https?://.+" required="">`) allows users to input arbitrary file paths, including those using the `file:///` protocol, without server-side validation. 2. The server then uses the user-provided URL to make a request, passing it to a browser instance that performs the "real-browser" request, which takes a screenshot of the content at the given URL. If a local file path is entered (e.g., `file:///etc/passwd`), the browser fetches and captures the file’s content. Since the user input is not validated, an attacker can manipulate the URL to request local files (e.g., `file:///etc/passwd`), and the system will capture a screenshot of the file's content, potentially exposing sensitive data. Any **authenticated user** who can submit a URL in "real-browser" mode is at risk of exposing sensitive data through screenshots of these files. This issue has been addressed in version 1.23.16 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| 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-2025-61765 | 2 Python, Python-socketio Project | 2 Python, Python-socketio | 2026-04-15 | 6.4 Medium |
| python-socketio is a Python implementation of the Socket.IO realtime client and server. A remote code execution vulnerability in python-socketio versions prior to 5.14.0 allows attackers to execute arbitrary Python code through malicious pickle deserialization in multi-server deployments on which the attacker previously gained access to the message queue that the servers use for internal communications. When Socket.IO servers are configured to use a message queue backend such as Redis for inter-server communication, messages sent between the servers are encoded using the `pickle` Python module. When a server receives one of these messages through the message queue, it assumes it is trusted and immediately deserializes it. The vulnerability stems from deserialization of messages using Python's `pickle.loads()` function. Having previously obtained access to the message queue, the attacker can send a python-socketio server a crafted pickle payload that executes arbitrary code during deserialization via Python's `__reduce__` method. This vulnerability only affects deployments with a compromised message queue. The attack can lead to the attacker executing random code in the context of, and with the privileges of a Socket.IO server process. Single-server systems that do not use a message queue, and multi-server systems with a secure message queue are not vulnerable. In addition to making sure standard security practices are followed in the deployment of the message queue, users of the python-socketio package can upgrade to version 5.14.0 or newer, which remove the `pickle` module and use the much safer JSON encoding for inter-server messaging. | ||||
| CVE-2025-54082 | 2026-04-15 | N/A | ||
| marshmallow-packages/nova-tiptap is a rich text editor for Laravel Nova based on tiptap. Prior to 5.7.0, a vulnerability was discovered in the marshmallow-packages/nova-tiptap Laravel Nova package that allows unauthenticated users to upload arbitrary files to any Laravel disk configured in the application. The vulnerability is due to missing authentication middleware (Nova and Nova.Auth) on the /nova-tiptap/api/file upload endpoint, the lack of validation on uploaded files (no MIME/type or extension restrictions), and the ability for an attacker to choose the disk parameter dynamically. This means an attacker can craft a custom form and send a POST request to /nova-tiptap/api/file, supplying a valid CSRF token, and upload executable or malicious files (e.g., .php, binaries) to public disks such as local, public, or s3. If a publicly accessible storage path is used (e.g. S3 with public access, or Laravel’s public disk), the attacker may gain the ability to execute or distribute arbitrary files — amounting to a potential Remote Code Execution (RCE) vector in some environments. This vulnerability was fixed in 5.7.0. | ||||
| CVE-2025-47934 | 1 Openpgpjs | 1 Openpgpjs | 2026-04-15 | N/A |
| OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`. | ||||
| CVE-2025-29923 | 2026-04-15 | 3.7 Low | ||
| go-redis is the official Redis client library for the Go programming language. Prior to 9.5.5, 9.6.3, and 9.7.3, go-redis potentially responds out of order when `CLIENT SETINFO` times out during connection establishment. This can happen when the client is configured to transmit its identity, there are network connectivity issues, or the client was configured with aggressive timeouts. The problem occurs for multiple use cases. For sticky connections, you receive persistent out-of-order responses for the lifetime of the connection. All commands in the pipeline receive incorrect responses. When used with the default ConnPool once a connection is returned after use with ConnPool#Put the read buffer will be checked and the connection will be marked as bad due to the unread data. This means that at most one out-of-order response before the connection is discarded. This issue is fixed in 9.5.5, 9.6.3, and 9.7.3. You can prevent the vulnerability by setting the flag DisableIndentity to true when constructing the client instance. | ||||
| CVE-2025-24976 | 1 Redhat | 1 Openshift | 2026-04-15 | 6.5 Medium |
| Distribution is a toolkit to pack, ship, store, and deliver container content. Systems running registry versions 3.0.0-beta.1 through 3.0.0-rc.2 with token authentication enabled may be vulnerable to an issue in which token authentication allows an attacker to inject an untrusted signing key in a JSON web token (JWT). The issue lies in how the JSON web key (JWK) verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (`kid`) matches one of the trusted keys, but doesn't verify that the actual key material matches. A fix for the issue is available at commit 5ea9aa028db65ca5665f6af2c20ecf9dc34e5fcd and expected to be a part of version 3.0.0-rc.3. There is no way to work around this issue without patching if the system requires token authentication. | ||||
| CVE-2025-24034 | 1 Himmelblau-idm | 1 Himmelblau | 2026-04-15 | 3.2 Low |
| Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Starting in version 0.7.0 and prior to versions 0.7.15 and 0.8.3, Himmelblau is vulnerable to leaking credentials in debug logs. When debug logging is enabled, user access tokens are inadvertently logged, potentially exposing sensitive authentication data. Similarly, Kerberos Ticket-Granting Tickets (TGTs) are logged when debug logging is enabled. Both issues pose a risk of exposing sensitive credentials, particularly in environments where debug logging is enabled. Himmelblau versions 0.7.15 and 0.8.3 contain a patch that fixes both issues. Some workarounds are available for users who are unable to upgrade. For the **logon compliance script issue**, disable the `logon_script` option in `/etc/himmelblau/himmelblau.conf`, and avoid using the `-d` flag when starting the `himmelblaud` daemon. For the Kerberos CCache issue, one may disable debug logging globally by setting the `debug` option in `/etc/himmelblau/himmelblau.conf` to `false` and avoiding the `-d` parameter when starting `himmelblaud`. | ||||
| CVE-2024-54150 | 2026-04-15 | 9.1 Critical | ||
| cjwt is a C JSON Web Token (JWT) Implementation. Algorithm confusion occurs when a system improperly verifies the type of signature used, allowing attackers to exploit the lack of distinction between signing methods. If the system doesn't differentiate between an HMAC signed token and an RS/EC/PS signed token during verification, it becomes vulnerable to this kind of attack. For instance, an attacker could craft a token with the alg field set to "HS256" while the server expects an asymmetric algorithm like "RS256". The server might mistakenly use the wrong verification method, such as using a public key as the HMAC secret, leading to unauthorised access. For RSA, the key can be computed from a few signatures. For Elliptic Curve (EC), two potential keys can be recovered from one signature. This can be used to bypass the signature mechanism if an application relies on asymmetrically signed tokens. This issue has been addressed in version 2.3.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-53844 | 2026-04-15 | 6.3 Medium | ||
| E.D.D.I (Enhanced Dialog Driven Interface) is a middleware to connect and manage LLM API bots. A path traversal vulnerability exists in the backup export functionality of EDDI, as implemented in `RestExportService.java`. This vulnerability allows an attacker to access sensitive files on the server by manipulating the `botFilename` parameter in requests. The application fails to sanitize user input, enabling malicious inputs such as `..%2f..%2fetc%2fpasswd` to access arbitrary files. However, the **severity of this vulnerability is significantly limited** because EDDI typically runs within a **Docker container**, which provides additional layers of isolation and restricted permissions. As a result, while this vulnerability exposes files within the container, it does not inherently threaten the underlying host system or other containers. A patch is required to sanitize and validate the botFilename input parameter. Users should ensure they are using version 5.4 which contains this patdch. For temporary mitigation, access to the vulnerable endpoint should be restricted through firewall rules or authentication mechanisms. | ||||
| CVE-2024-52337 | 1 Redhat | 9 Enterprise Linux, Rhel Aus, Rhel E4s and 6 more | 2026-04-15 | 5.5 Medium |
| A log spoofing flaw was found in the Tuned package due to improper sanitization of some API arguments. This flaw allows an attacker to pass a controlled sequence of characters; newlines can be inserted into the log. Instead of the 'evil' the attacker could mimic a valid TuneD log line and trick the administrator. The quotes '' are usually used in TuneD logs citing raw user input, so there will always be the ' character ending the spoofed input, and the administrator can easily overlook this. This logged string is later used in logging and in the output of utilities, for example, `tuned-adm get_instances` or other third-party programs that use Tuned's D-Bus interface for such operations. | ||||
| CVE-2021-42718 | 1 Replicated | 1 Replicated Classic | 2026-04-15 | 4.9 Medium |
| Information Disclosure in API in Replicated Replicated Classic versions prior to 2.53.1 on all platforms allows authenticated users with Admin Console access to retrieve sensitive data, including application secrets, via accessing container definitions with environment variables through the Admin Console API on port 8800. This CVE was originally reserved in 2021 and later publicly disclosed by Replicated on their website on 21 October 2021. However, it mistakenly remained in the Reserved But Public (RBP) status with the CVE Numbering Authority (CNA). Please note that this product reached its end of life on 31 December 2024. Publishing this CVE with the CNA was required to comply with CNA rules, despite the fact that the issue was disclosed and fixed four years ago, and the affected product is no longer supported as of 2024. Summary of VulnerabilityThis advisory discloses a low severity security vulnerability in the versions of Replicated Classic listed above (“Affected Replicated Classic Versions”) DescriptionReplicated Classic versions prior to 2.53.1 have an authenticated API from the Replicated Admin Console that may expose sensitive data including application secrets, depending on how the application manifests are written. A user with valid credentials and access to the Admin Console port (8800) on the Replicated Classic server can retrieve container definitions including environment variables which may contain passwords and other secrets depending on how the application is configured. This data is shared over authenticated sessions to the Admin Console only, and was never displayed or used in the application processing. To remediate this issue, we removed the sensitive data from the API, sending only the data to the Admin Console that was needed. TimelineThis issue was discovered during a security review on 16 September 2021. Patched versions were released on 23 September 2021. This advisory was published on 21 October 2021. The CVE Numbering Authority (CNA) notified Replicated on 23 January 2025 that the CVE was still in Reserved But Public (RBP) status. Upon discovering the oversight in updating the status to published with the CNA, Replicated submitted the updated report on the same day, 23 January 2025. | ||||
| CVE-2025-8869 | 1 Python | 2 Pip, Python | 2026-04-15 | 5.3 Medium |
| When extracting a tar archive pip may not check symbolic links point into the extraction directory if the tarfile module doesn't implement PEP 706. Note that upgrading pip to a "fixed" version for this vulnerability doesn't fix all known vulnerabilities that are remediated by using a Python version that implements PEP 706. Note that this is a vulnerability in pip's fallback implementation of tar extraction for Python versions that don't implement PEP 706 and therefore are not secure to all vulnerabilities in the Python 'tarfile' module. If you're using a Python version that implements PEP 706 then pip doesn't use the "vulnerable" fallback code. Mitigations include upgrading to a version of pip that includes the fix, upgrading to a Python version that implements PEP 706 (Python >=3.9.17, >=3.10.12, >=3.11.4, or >=3.12), applying the linked patch, or inspecting source distributions (sdists) before installation as is already a best-practice. | ||||