| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| In aee daemon, there is a possible system crash due to a race condition. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10190802; Issue ID: MSV-4833. |
| In Bluetooth firmware, there is a possible firmware asssert due to improper handling of exceptional conditions. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS09001270; Issue ID: MSV-1600. |
| In wlan STA, there is a possible way to trick a client to connect to an AP with spoofed SSID. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08990446 / ALPS09057442; Issue ID: MSV-1598. |
| A denial-of-service vulnerability exists in the omec-project UPF (pfcpiface component) in version upf-epc-pfcpiface:2.1.3-dev. When the UPF receives a PFCP Session Report Response that is missing the mandatory Cause Information Element, the session report handler dereferences a nil pointer instead of rejecting the malformed message. This triggers a panic and terminates the UPF process. An attacker who can send PFCP Session Report Response messages to the UPF's N4/PFCP endpoint can exploit this flaw to repeatedly crash the UPF and disrupt user-plane services. |
| An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS). |
| containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources. |
| containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode. |
| runc through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a CVE-2019-19921 regression. |
| runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3. |
| runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3. |
| runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3. |
| PyTorch is a Python package that provides tensor computation with strong GPU acceleration and deep neural networks built on a tape-based autograd system. In version 2.5.1 and prior, a Remote Command Execution (RCE) vulnerability exists in PyTorch when loading a model using torch.load with weights_only=True. This issue has been patched in version 2.6.0. |
