CVE-2026-5011: elecV2P JSON Parser RCE Vulnerability

CVE-2026-5011 Overview

A code injection vulnerability has been identified in elecV2 elecV2P versions up to and including 3.8.3. This security flaw affects the runJSFile function within the /webhook endpoint of the JSON Parser component. By manipulating the rawcode argument, an attacker can inject and execute arbitrary code on the target system. The vulnerability is remotely exploitable over the network, requiring only low-level privileges to execute an attack.

Critical Impact

Remote code injection via the webhook endpoint allows authenticated attackers to execute arbitrary JavaScript code on affected elecV2P instances, potentially leading to full system compromise.

Affected Products

• elecV2 elecV2P versions up to 3.8.3
• Systems running elecV2P with exposed webhook endpoints
• Deployments with network-accessible /webhook endpoints

Discovery Timeline

• 2026-03-28 - CVE-2026-5011 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-5011

Vulnerability Analysis

This vulnerability is classified as CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component), commonly known as Injection. The flaw resides in the elecV2P automation platform's webhook handling mechanism, specifically within the JSON Parser component.

The runJSFile function fails to properly sanitize or validate the rawcode parameter before processing. This allows attackers to craft malicious JSON payloads containing JavaScript code that gets executed by the server. Since elecV2P is designed to automate tasks and run scripts, the code injection vulnerability directly leverages the platform's intended functionality against itself.

The exploit has been publicly disclosed, increasing the risk of widespread exploitation. The project maintainers were notified through a GitHub Issue but have not yet responded with a fix or acknowledgment.

Root Cause

The root cause of this vulnerability stems from insufficient input validation in the runJSFile function. The function accepts user-controlled input through the rawcode argument without proper sanitization or encoding. When processing webhook requests containing JSON data, the parser directly passes the manipulated argument to the JavaScript execution engine, enabling code injection attacks.

This represents a fundamental secure coding failure where untrusted input is treated as trusted code. The lack of input validation boundaries between the webhook interface and the script execution component creates a direct injection vector.

Attack Vector

The attack is network-based, requiring authentication with low-level privileges. An attacker with valid credentials can send specially crafted HTTP requests to the /webhook endpoint containing malicious JavaScript code embedded within the JSON payload's rawcode parameter.

The attack flow involves:

1. Authenticating to the elecV2P instance
2. Crafting a malicious JSON payload with injected code in the rawcode field
3. Sending the payload to the /webhook endpoint
4. The JSON Parser processes the request and passes the malicious code to runJSFile
5. The injected JavaScript executes with the privileges of the elecV2P process

Technical details and proof-of-concept information can be found in the VulDB vulnerability entry and the associated GitHub issue discussion.

Detection Methods for CVE-2026-5011

Indicators of Compromise

• Unusual HTTP POST requests to /webhook endpoints containing suspicious JavaScript code patterns
• Unexpected script execution or process spawning from the elecV2P service
• Modified or newly created files in elecV2P script directories
• Anomalous network connections originating from the elecV2P process

Detection Strategies

• Monitor HTTP request logs for /webhook endpoint access with abnormally large or encoded payloads
• Implement Web Application Firewall (WAF) rules to detect JavaScript code patterns in JSON request bodies
• Enable verbose logging on elecV2P instances to capture script execution events
• Deploy endpoint detection solutions to monitor process behavior from Node.js/JavaScript runtime environments

Monitoring Recommendations

• Configure alerting for any script execution events triggered via the webhook interface
• Implement network segmentation to isolate elecV2P instances from sensitive network segments
• Review authentication logs for unusual login patterns or credential usage
• Monitor file system changes in elecV2P installation directories for unauthorized modifications

How to Mitigate CVE-2026-5011

Immediate Actions Required

• Restrict network access to the /webhook endpoint using firewall rules or access control lists
• Implement strong authentication requirements and review existing user privileges
• Consider temporarily disabling the webhook functionality if not critical to operations
• Monitor for exploitation attempts using the detection strategies outlined above
• Isolate affected elecV2P instances from production networks until a patch is available

Patch Information

As of the last update on 2026-03-30, no official patch has been released by the elecV2P project maintainers. The vulnerability was reported through the project's GitHub issue tracker, but no response has been received. Users should monitor the elecV2P GitHub repository for future security updates and patches.

Workarounds

• Deploy a reverse proxy with strict input validation to filter malicious payloads before they reach elecV2P
• Implement IP whitelisting to restrict webhook access to trusted sources only
• Disable the webhook feature entirely if not required for your deployment
• Apply principle of least privilege by running elecV2P with minimal system permissions

# Configuration example - Restrict webhook access via iptables
# Allow webhook access only from trusted IP addresses
iptables -A INPUT -p tcp --dport 80 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

# Alternative: Use nginx as reverse proxy with rate limiting
# Add to nginx.conf server block for elecV2P
# location /webhook {
#     limit_req zone=webhook_limit burst=5 nodelay;
#     deny all;
#     allow 192.168.1.0/24;
# }