Export limit exceeded: 363307 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (363307 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-25837 | 2026-02-07 | N/A | ||
| Not used | ||||
| CVE-2023-6763 | 2026-02-06 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2025-68138 | 2 Everest, Linuxfoundation | 2 Everest-core, Libocpp | 2026-02-06 | 4.7 Medium |
| EVerest is an EV charging software stack, and EVerest libocpp is a C++ implementation of the Open Charge Point Protocol. In libocpp prior to version 0.30.1, pointers returned by the `strdup` calls are never freed. At each connection attempt, the newly allocated memory area will be leaked, potentially causing memory exhaustion and denial of service. Version 0.30.1 fixes the issue. | ||||
| CVE-2025-68139 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 4.3 Medium |
| EVerest is an EV charging software stack. In all versions up to and including 2025.12.1, the default value for `terminate_connection_on_failed_response` is `False`, which leaves the responsibility for session and connection termination to the EV. In this configuration, any errors encountered by the module are logged but do not trigger countermeasures such as session and connection reset or termination. This could be abused by a malicious user in order to exploit other weaknesses or vulnerabilities. While the default will stay at the setting that is described as potentially problematic in this reported issue, a mitigation is available by changing the `terminate_connection_on_failed_response` setting to `true`. However this cannot be set to this value by default since it can trigger errors in vehicle ECUs requiring ECU resets and lengthy unavailability in charging for vehicles. The maintainers judge this to be a much more important workaround then short-term unavailability of an EVSE, therefore this setting will stay at the current value. | ||||
| CVE-2025-68140 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 4.3 Medium |
| EVerest is an EV charging software stack. Prior to version 2025.9.0, once the validity of the received V2G message has been verified, it is checked whether the submitted session ID matches the registered one. However, if no session has been registered, the default value is 0. Therefore, a message submitted with a session ID of 0 is accepted, as it matches the registered value. This could allow unauthorized and anonymous indirect emission of MQTT messages and communication with V2G messages handlers, updating a session context. Version 2025.9.0 fixes the issue. | ||||
| CVE-2025-68141 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 7.4 High |
| EVerest is an EV charging software stack. Prior to version 2025.10.0, during the deserialization of a `DC_ChargeLoopRes` message that includes Receipt as well as TaxCosts, the vector `<DetailedTax>tax_costs` in the target `Receipt` structure is accessed out of bounds. This occurs in the method `template <> void convert(const struct iso20_dc_DetailedTaxType& in, datatypes::DetailedTax& out)` which leads to a null pointer dereference and causes the module to terminate. The EVerest processes and all its modules shut down, affecting all EVSE. Version 2025.10.0 fixes the issue. | ||||
| CVE-2025-68137 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 8.4 High |
| EVerest is an EV charging software stack. Prior to version 2025.10.0, an integer overflow occurring in `SdpPacket::parse_header()` allows the current buffer length to be set to 7 after a complete header of size 8 has been read. The remaining length to read is computed using the current length subtracted by the header length which results in a negative value. This value is then interpreted as `SIZE_MAX` (or slightly less) because the expected type of the argument is `size_t`. Depending on whether the server is plain TCP or TLS, this leads to either an infinite loop or a stack buffer overflow. Version 2025.10.0 fixes the issue. | ||||
| CVE-2025-68136 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 7.4 High |
| EVerest is an EV charging software stack. Prior to version 2025.10.0, once the module receives a SDP request, it creates a whole new set of objects like `Session`, `IConnection` which open new TCP socket for the ISO15118-20 communications and registers callbacks for the created file descriptor, without closing and destroying the previous ones. Previous `Session` is not saved and the usage of an `unique_ptr` is lost, destroying connection data. Latter, if the used socket and therefore file descriptor is not the last one, it will lead to a null pointer dereference. Version 2025.10.0 fixes the issue. | ||||
| CVE-2025-68135 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 6.5 Medium |
| EVerest is an EV charging software stack. Prior to version 2025.10.0, C++ exceptions are not properly handled for and by the `TbdController` loop, leading to its caller and itself to silently terminates. Thus, this leads to a denial of service as it is responsible of SDP and ISO15118-20 servers. Version 2025.10.0 fixes the issue. | ||||
| CVE-2025-68134 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 7.4 High |
| EVerest is an EV charging software stack. Prior to version 2025.10.0, the use of the `assert` function to handle errors frequently causes the module to crash. This is particularly critical because the manager shuts down all other modules and exits when any one of them terminates, leading to a denial of service. In a context where a manager handles multiple EVSE, this would also impact other users. Version 2025.10.0 fixes the issue. | ||||
| CVE-2025-68133 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 7.4 High |
| EVerest is an EV charging software stack. In versions 2025.9.0 and below, an attacker can exhaust the operating system's memory and cause the module to terminate by initiating an unlimited number of TCP connections that never proceed to ISO 15118-2 communication. This is possible because a new thread is started for each incoming plain TCP or TLS socket connection before any verification occurs, and the verification performed is too permissive. The EVerest processes and all its modules shut down, affecting all EVSE functionality. This issue is fixed in version 2025.10.0. | ||||
| CVE-2025-68132 | 2 Everest, Linuxfoundation | 2 Everest-core, Everest | 2026-02-06 | 4.6 Medium |
| EVerest is an EV charging software stack. Prior to version 2025.12.0, `is_message_crc_correct` in the DZG_GSH01 powermeter SLIP parser reads `vec[vec.size()-1]` and `vec[vec.size()-2]` without checking that at least two bytes are present. Malformed SLIP frames on the serial link can reach `is_message_crc_correct` with `vec.size() < 2` (only via the multi-message path), causing an out-of-bounds read before CRC verification and `pop_back` underflow. Therefore, an attacker controlling the serial input can reliably crash the process. Version 2025.12.0 fixes the issue. | ||||
| CVE-2007-2774 | 1 Sunlight-cms | 1 Sunlight Cms | 2026-02-06 | N/A |
| Multiple PHP remote file inclusion vulnerabilities in SunLight CMS 5.3 allow remote attackers to execute arbitrary PHP code via a URL in the root parameter to (1) _connect.php or (2) modules/startup.php. | ||||
| CVE-2025-58381 | 2 Broadcom, Brocade | 2 Fabric Operating System, Fabric Os | 2026-02-06 | 2.3 Low |
| A vulnerability in Brocade Fabric OS before 9.2.1c2 could allow an authenticated attacker with admin privileges using the shell commands “source, ping6, sleep, disown, wait to modify the path variables and move upwards in the directory structure or to traverse to different directories. | ||||
| CVE-2025-58380 | 2 Broadcom, Brocade | 2 Fabric Operating System, Fabric Os | 2026-02-06 | 2.3 Low |
| A vulnerability in Brocade Fabric OS before 9.2.1 could allow an authenticated attacker with admin privileges using the shell command “grep” to modify the path variables and move upwards in the directory structure or to traverse to different directories. | ||||
| CVE-2025-58379 | 2 Broadcom, Brocade | 2 Fabric Operating System, Fabric Os | 2026-02-06 | 5.5 Medium |
| Brocade Fabric OS before 9.2.1 has a vulnerability that could allow a local authenticated attacker to reveal command line passwords using commands that may expose higher privilege sensitive information by a lower privileged user. | ||||
| CVE-2022-29164 | 1 Argoproj | 1 Argo Workflows | 2026-02-06 | 7.1 High |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. In affected versions an attacker can create a workflow which produces a HTML artifact containing an HTML file that contains a script which uses XHR calls to interact with the Argo Server API. The attacker emails the deep-link to the artifact to their victim. The victim opens the link, the script starts running. As the script has access to the Argo Server API (as the victim), so may read information about the victim’s workflows, or create and delete workflows. Note the attacker must be an insider: they must have access to the same cluster as the victim and must already be able to run their own workflows. The attacker must have an understanding of the victim’s system. We have seen no evidence of this in the wild. We urge all users to upgrade to the fixed versions. | ||||
| CVE-2024-47827 | 1 Argoproj | 2 Argo-workflows, Argo Workflows | 2026-02-06 | 5.7 Medium |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Due to a race condition in a global variable in 3.6.0-rc1, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow. This vulnerability is fixed in 3.6.0-rc2. | ||||
| CVE-2024-53862 | 1 Argoproj | 2 Argo-workflows, Argo Workflows | 2026-02-06 | 7.5 High |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using `--auth-mode=client`, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}` or when using `--auth-mode=sso`, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}`. No authentication is performed by the Server itself on `client` tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a `kubectl auth can-i` check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13. | ||||
| CVE-2025-62156 | 1 Argoproj | 2 Argo-workflows, Argo Workflows | 2026-02-06 | 8.1 High |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Versions prior to 3.6.12 and versions 3.7.0 through 3.7.2 contain a Zip Slip path traversal vulnerability in artifact extraction. During artifact extraction the unpack/untar logic (workflow/executor/executor.go) uses filepath.Join(dest, filepath.Clean(header.Name)) without validating that header.Name stays within the intended extraction directory. A malicious archive entry can supply a traversal or absolute path that, after cleaning, overrides the destination directory and causes files to be written outside the /work/tmp extraction path and into system directories such as /etc inside the container. The vulnerability enables arbitrary file creation or overwrite in system configuration locations (for example /etc/passwd, /etc/hosts, /etc/crontab), which can lead to privilege escalation or persistence within the affected container. Update to 3.6.12 or 3.7.3 to remediate the issue. | ||||