CVE-2025-68138

4.7 MEDIUM

📋 TL;DR

This vulnerability in EVerest libocpp causes memory leaks through unfreed strdup pointers during connection attempts. It affects EV charging systems using libocpp versions before 0.30.1, potentially leading to denial of service through memory exhaustion.

💻 Affected Systems

Products:
  • EVerest libocpp
Versions: All versions prior to 0.30.1
Operating Systems: Linux, Other Unix-like systems
Default Config Vulnerable: ⚠️ Yes
Notes: Affects systems using libocpp's websocket implementation with libwebsockets backend.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Repeated connection attempts could exhaust all available memory, causing the charging system to crash and become unavailable, disrupting EV charging operations.

🟠

Likely Case

Gradual memory consumption over time leading to degraded performance and eventual system instability requiring manual intervention.

🟢

If Mitigated

With proper monitoring and restart policies, impact is limited to temporary service interruptions rather than prolonged outages.

🌐 Internet-Facing: MEDIUM
🏢 Internal Only: MEDIUM

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Exploitation requires ability to initiate connection attempts to vulnerable systems.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 0.30.1

Vendor Advisory: https://github.com/EVerest/everest-core/security/advisories/GHSA-f8c2-44c3-7v55

Restart Required: Yes

Instructions:

1. Update libocpp to version 0.30.1 or later. 2. Rebuild any dependent applications. 3. Restart affected services.

🔧 Temporary Workarounds

Connection Rate Limiting

linux

Limit connection attempt frequency to reduce memory leak rate

# Configure firewall or application-level rate limiting
# Example: iptables -A INPUT -p tcp --dport <port> -m limit --limit 10/min -j ACCEPT

Memory Monitoring and Restart

linux

Implement monitoring to restart service when memory usage exceeds threshold

# Add to cron: */5 * * * * if [ $(ps -o rss= -p $(pidof <service>)) -gt 1000000 ]; then systemctl restart <service>; fi

🧯 If You Can't Patch

  • Implement strict connection rate limiting at network perimeter
  • Deploy memory monitoring with automated service restart when thresholds exceeded

🔍 How to Verify

Check if Vulnerable:

Check libocpp version: grep -r "libocpp" /usr/include/ /usr/lib/ or check package manager output

Check Version:

pkg-config --modversion libocpp || find /usr -name "*libocpp*" -type f | xargs strings | grep -i version

Verify Fix Applied:

Verify version is 0.30.1 or later and monitor memory usage during connection attempts

📡 Detection & Monitoring

Log Indicators:

  • Rapid connection/disconnection patterns
  • Increasing memory usage over time without corresponding load
  • Out of memory errors in system logs

Network Indicators:

  • Abnormally high connection attempt rates to charging system ports
  • Repeated websocket connection attempts from single sources

SIEM Query:

source="system_logs" ("out of memory" OR "OOM") AND process="*libocpp*" OR source="network_logs" dest_port="<charging_port>" count by src_ip > threshold

🔗 References

📤 Share & Export