CVE-2026-40516: OpenHarness SSRF Vulnerability

CVE-2026-40516 Overview

OpenHarness before commit bd4df81 contains a server-side request forgery (SSRF) vulnerability in the web_fetch and web_search tools. This security flaw allows attackers to access private and localhost HTTP services by manipulating tool parameters without proper validation of target addresses. Attackers can influence an agent session to invoke these tools against loopback, RFC1918, link-local, or other non-public addresses to read response bodies from local development services, cloud metadata endpoints, admin panels, or other private HTTP services reachable from the victim host.

Critical Impact

Attackers can leverage this SSRF vulnerability to access internal services, cloud metadata endpoints (such as AWS EC2 metadata at 169.254.169.254), and administrative panels that should not be externally accessible, potentially leading to credential theft and lateral movement within protected networks.

Affected Products

• OpenHarness (versions before commit bd4df81)
• OpenHarness web_fetch tool component
• OpenHarness web_search tool component

Discovery Timeline

• 2026-04-17 - CVE-2026-40516 published to NVD
• 2026-04-17 - Last updated in NVD database

Technical Details for CVE-2026-40516

Vulnerability Analysis

This vulnerability is classified as CWE-918 (Server-Side Request Forgery). The web_fetch and web_search tools in OpenHarness accept user-controlled URL parameters without implementing adequate validation to restrict requests to non-public network ranges. When an agent session processes tool invocations, the vulnerable code directly uses the supplied target addresses to initiate HTTP requests from the server side.

The lack of address validation enables attackers to craft malicious tool parameters that target internal network resources. This is particularly dangerous in cloud environments where metadata services (such as AWS EC2 metadata at 169.254.169.254) can be queried to obtain temporary credentials, instance information, and other sensitive configuration data.

Root Cause

The root cause of this vulnerability lies in the insufficient input validation within the permission checking logic of OpenHarness. Prior to the security patch, the _resolve_permission_file_path function and associated permission checkers did not properly validate or restrict URL targets for web-related tools. The code lacked guards to detect and block requests to loopback addresses (127.0.0.0/8), RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local addresses (169.254.0.0/16).

Attack Vector

This vulnerability is exploitable over the network without requiring authentication or user interaction. An attacker can manipulate the parameters passed to the web_fetch or web_search tools through prompt injection or by directly influencing agent sessions. The attack flow typically involves:

1. Attacker gains ability to influence tool parameters in an OpenHarness agent session
2. Attacker crafts a request targeting internal IP addresses or hostnames
3. The vulnerable tools execute the request from the server's network context
4. Response data from internal services is returned to the attacker

The security patch in src/openharness/engine/query.py and src/openharness/permissions/checker.py addresses this by implementing proper web guards and enhancing path rule validation:

         # defence-in-depth measure against LLM-directed or prompt-injection
         # driven access to credential files.
         if file_path:
-            for pattern in SENSITIVE_PATH_PATTERNS:
-                if fnmatch.fnmatch(file_path, pattern):
-                    return PermissionDecision(
-                        allowed=False,
-                        reason=(
-                            f"Access denied: {file_path} is a sensitive credential path "
-                            f"(matched built-in pattern '{pattern}')"
-                        ),
-                    )
+            for candidate_path in _policy_match_paths(file_path):
+                for pattern in SENSITIVE_PATH_PATTERNS:
+                    if fnmatch.fnmatch(candidate_path, pattern):
+                        return PermissionDecision(
+                            allowed=False,
+                            reason=(
+                                f"Access denied: {file_path} is a sensitive credential path "
+                                f"(matched built-in pattern '{pattern}')"
+                            ),
+                        )

Source: GitHub Commit bd4df81

Detection Methods for CVE-2026-40516

Indicators of Compromise

• Outbound HTTP requests from the OpenHarness server targeting internal IP ranges (127.0.0.1, 10.x.x.x, 172.16-31.x.x, 192.168.x.x)
• Requests to cloud metadata endpoints (e.g., 169.254.169.254)
• Agent session logs showing web_fetch or web_search tool invocations with private/internal URL targets
• Unexpected access to internal admin panels or development services from the OpenHarness host

Detection Strategies

• Implement network monitoring to detect egress traffic from OpenHarness servers to RFC1918 addresses and link-local ranges
• Enable detailed logging for all web_fetch and web_search tool invocations and analyze URL parameters
• Deploy web application firewalls (WAF) with SSRF detection rules to identify attempts to access internal resources
• Monitor for anomalous DNS queries resolving to internal IP addresses from OpenHarness hosts

Monitoring Recommendations

• Configure alerts for any HTTP requests originating from OpenHarness servers to internal network segments
• Implement cloud security monitoring to detect access to metadata service endpoints (169.254.169.254)
• Review agent session logs for suspicious tool parameter patterns indicating SSRF attempts
• Enable SentinelOne's network visibility features to track server-side request patterns and identify anomalous internal communications

How to Mitigate CVE-2026-40516

Immediate Actions Required

• Update OpenHarness to commit bd4df81 or later which contains the security fix
• Review agent session logs to identify any previous exploitation attempts targeting internal services
• Audit network access controls to ensure OpenHarness servers cannot reach sensitive internal resources
• If immediate patching is not possible, disable or restrict access to web_fetch and web_search tools

Patch Information

The vulnerability has been addressed in GitHub commit bd4df81, which implements hardened path rules and web guards. The fix was introduced via Pull Request #92. Organizations should update their OpenHarness installations to include this commit or any subsequent release containing this fix. Additional details are available in the VulnCheck Security Advisory.

Workarounds

• Implement network-level controls to block outbound connections from OpenHarness servers to internal networks and cloud metadata endpoints
• Deploy a proxy server between OpenHarness and external networks with URL filtering to block private IP ranges
• Disable the web_fetch and web_search tools in OpenHarness configuration if they are not essential for operations

# Network-level mitigation using iptables to block SSRF to internal ranges
# Block requests to localhost
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner openharness -j DROP
# Block requests to RFC1918 private networks
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner openharness -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner openharness -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner openharness -j DROP
# Block requests to cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner openharness -j DROP