CVE-2025-68138
BaseFortify
Publication date: 2026-01-21
Last updated on: 2026-02-06
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linuxfoundation | libocpp | to 0.30.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the libocpp library prior to version 0.30.1 is a memory leak caused by pointers returned from strdup calls never being freed during websocket connection attempts. Each connection attempt allocates memory for various connection parameters using strdup, but this memory is not released, leading to a gradual memory leak. Over time, especially with frequent reconnections or extended connection failures, this leak can exhaust available memory and cause the software to fail. [2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the memory usage of the libocpp process over time, especially during repeated websocket connection attempts. Since the issue is a memory leak caused by strdup allocations not being freed, observing a gradual increase in memory consumption can indicate the presence of the vulnerability. Additionally, debugging tools like GDB can be used to inspect the pointers returned by strdup to verify they remain allocated. Specific commands to monitor memory usage include: `top` or `htop` to observe process memory, `ps aux --sort=-rss | grep libocpp` to check resident memory size, and using `valgrind --leak-check=full` if possible to detect memory leaks. For debugging, attaching GDB to the running process and inspecting allocations in the `thread_websocket_client_loop` function can help confirm the leak. [2]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade libocpp to version 0.30.1 or later, where the memory leak issue has been fixed. If upgrading is not immediately possible, reducing the frequency of reconnection attempts or restarting the affected service periodically to free leaked memory may help temporarily mitigate the risk of denial of service due to memory exhaustion. [2]
How can this vulnerability impact me? :
The vulnerability can lead to memory exhaustion on devices running libocpp, particularly embedded devices with limited memory. This memory exhaustion can cause a denial of service (DoS), making the EV charging software stack unresponsive or unable to maintain connections, potentially disrupting EV charging operations. [2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA. The vulnerability primarily causes memory exhaustion leading to denial of service, without affecting confidentiality or integrity of data. [2]