CVE-2026-43910: Appium Java Client SSRF Vulnerability

CVE-2026-43910 Overview

CVE-2026-43910 is a high-severity vulnerability in Appium Java Client, the Java language binding for writing Appium tests that conform to the W3C WebDriver protocol. Versions from 8.2.1 until 10.1.1 fail to validate host and IP addresses returned in the NEW_SESSION response when directConnect(true) is enabled. A rogue or compromised Appium server can redirect all subsequent session traffic to an attacker-controlled destination. This creates conditions for full session interception and server-side request forgery (SSRF) pivots into internal networks, including cloud metadata service (IMDS) credential theft. The issue is fixed in version 10.1.1.

Critical Impact
A malicious or compromised Appium server can hijack client session traffic and pivot into internal cloud infrastructure, including IMDS endpoints, exposing cloud credentials.

Affected Products

Appium Java Client versions 8.2.1 through 10.1.0
Java-based Appium test clients using directConnect(true)
Test infrastructure connecting to third-party or shared Appium grids

Discovery Timeline

2026-07-28 - CVE-2026-43910 published to NVD
2026-07-28 - Last updated in NVD database

Technical Details for CVE-2026-43910

Vulnerability Analysis

The flaw resides in AppiumCommandExecutor.setDirectConnect(), which parses the directConnectHost, directConnectPort, and directConnectPath fields returned in the server's NEW_SESSION response. When directConnect(true) is enabled, the client rebuilds its server URL using these attacker-influenced values. The only validation performed is that the resulting protocol equals https. No host allowlist, DNS resolution check, or IP range validation is applied.

The vulnerability is categorized under [CWE-441] Unintended Proxy or Intermediary, also known as a confused deputy. The client trusts the server to describe where subsequent traffic should be routed, and the server can weaponize that trust to redirect the entire session.

Root Cause

The root cause is missing input validation on server-supplied URL components used to reconstruct the effective endpoint. The original code enforced only a protocol check on the rebuilt URL. Loopback, link-local, unspecified, and multicast addresses were all accepted, including the IPv4 link-local range 169.254.0.0/16 that hosts cloud metadata services on AWS, Azure, and GCP.

Attack Vector

An adversary controlling or compromising an Appium server responds to a NEW_SESSION request with a crafted directConnectHost value pointing at an internal target. All follow-up WebDriver commands from the client are then transmitted to that host. Attackers can intercept credentials embedded in session traffic or query 169.254.169.254 to retrieve IMDS tokens and cloud role credentials. Because the redirection occurs client-side, the attack requires user interaction only to the extent that the tester initiates a session against the malicious server.

java

+/*
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ */
+
+package io.appium.java_client.internal;
+
+import org.openqa.selenium.SessionNotCreatedException;
+
+import java.net.InetAddress;
+import java.net.URL;
+import java.net.UnknownHostException;
+
+/**
+ * Validates URLs used with {@code overrideServerUrl} (for example after a {@code directConnect}
+ * response). Refuses the override when any resolved address is loopback, link-local (including
+ * typical cloud metadata IPv4 link-local space), unspecified, or multicast.
+ */

Source: GitHub Commit 2b9cd44. The patch introduces DirectConnectUrlSafety and integrates it into AppiumCommandExecutor to reject dangerous address ranges.

Detection Methods for CVE-2026-43910

Indicators of Compromise

Outbound HTTPS connections from CI/CD runners or test hosts to unexpected destinations after Appium session creation
Requests originating from Appium client hosts to 169.254.169.254, fd00:ec2::254, or other IMDS endpoints
WebDriver session traffic terminating at hosts other than the originally configured Appium server URL
Unusual DNS lookups from test infrastructure resolving to internal RFC 1918 space during Appium runs

Detection Strategies

Inventory Java projects for io.appium:java-client dependency versions between 8.2.1 and 10.1.0
Audit test code for calls enabling directConnect(true) on AppiumClientConfig
Inspect proxy or egress logs for hostname mismatches between declared Appium server and actual traffic destinations
Correlate NEW_SESSION HTTP responses with subsequent connection targets to detect redirection

Monitoring Recommendations

Alert on any process launched by a Java test runner that contacts cloud metadata IP ranges
Baseline expected Appium grid endpoints and flag deviations in outbound TLS SNI values
Monitor for unauthorized use of temporary cloud credentials issued to CI runners immediately after test executions

How to Mitigate CVE-2026-43910

Immediate Actions Required

Upgrade io.appium:java-client to version 10.1.1 or later across all test projects
Disable directConnect(true) in AppiumClientConfig until upgrades are complete
Restrict test infrastructure egress so runners cannot reach IMDS endpoints or unintended internal ranges
Rotate any cloud credentials or session tokens accessible from hosts that ran vulnerable Appium clients against untrusted servers

Patch Information

The fix ships in Appium Java Client 10.1.1. See the GitHub Release v10.1.1, the GitHub Pull Request #2408, and the GitHub Security Advisory GHSA-28f5-38xr-jh2w. The patch adds DirectConnectUrlSafety to reject loopback, link-local, unspecified, and multicast addresses returned by the server.

Workarounds

Set directConnect(false) or omit the flag entirely to force all traffic through the originally configured server URL
Route Appium traffic through an authenticated egress proxy that enforces a strict allowlist of target hosts
Use IMDSv2 with hop limit 1 on cloud instances running test workloads to reduce credential theft risk

bash

# Upgrade Appium Java Client via Maven
mvn versions:use-dep-version -Dincludes=io.appium:java-client -DdepVersion=10.1.1 -DforceVersion=true

# Or via Gradle dependency declaration
# implementation 'io.appium:java-client:10.1.1'

# Verify the resolved version
mvn dependency:tree | grep java-client