Summary
Appium Java Client's directConnect feature can be abused to redirect WebDriver session traffic to attacker-controlled endpoints by trusting server-provided connection parameters with minimal validation.
A rogue or compromised Appium server can rewrite the client's target URL, enabling full interception of session traffic and server-side request forgery toward internal services and metadata endpoints.
Appium Java Client's directConnect feature can be abused to redirect WebDriver session traffic to attacker-controlled endpoints by trusting server-provided connection parameters with minimal validation.
A rogue or compromised Appium server can rewrite the client's target URL, enabling full interception of session traffic and server-side request forgery toward internal services and metadata endpoints.
Affected context
The issue arises in Appium Java Client versions 8.2.1 through 10.1.1 when the directConnect(true) option is enabled in test clients.
In this mode, the client reads directConnectHost, directConnectPort, and directConnectPath from the Appium server's NEW_SESSION response and reconstructs the server URL.
Only the scheme (https) is validated; there is no built-in validation of the target host or IP, so any Appium deployment that allows untrusted or shared servers may be exposed to malicious redirection.
The issue arises in Appium Java Client versions 8.2.1 through 10.1.1 when the directConnect(true) option is enabled in test clients.
In this mode, the client reads directConnectHost, directConnectPort, and directConnectPath from the Appium server's NEW_SESSION response and reconstructs the server URL.
Only the scheme (https) is validated; there is no built-in validation of the target host or IP, so any Appium deployment that allows untrusted or shared servers may be exposed to malicious redirection.
Exploit preconditions
- Attack surface: WebDriver/Appium client-server communication channel.
- Required access: Ability to operate, compromise, or influence the Appium server that responds to
NEW_SESSIONrequests. - Trigger point: A client using Appium Java Client (affected versions) with
directConnect(true)enabled and initiating a new session. - Why exploitation is possible: The client automatically rebuilds its base URL from server-supplied
directConnect*fields, validating only that the protocol ishttpsand not enforcing any host, domain, or IP allowlist; this lets a malicious server redirect all subsequent requests to arbitrary endpoints.
- Attack surface: WebDriver/Appium client-server communication channel.
- Required access: Ability to operate, compromise, or influence the Appium server that responds to
NEW_SESSIONrequests. - Trigger point: A client using Appium Java Client (affected versions) with
directConnect(true)enabled and initiating a new session. - Why exploitation is possible: The client automatically rebuilds its base URL from server-supplied
directConnect*fields, validating only that the protocol ishttpsand not enforcing any host, domain, or IP allowlist; this lets a malicious server redirect all subsequent requests to arbitrary endpoints.
Why this happens
The bug stems from over-trusting server-provided connection metadata when reconfiguring the client's base URL.
AppiumCommandExecutor's setDirectConnect() method accepts directConnectHost, directConnectPort, and directConnectPath from the NEW_SESSION response and reconstructs the endpoint used for subsequent WebDriver commands.
This pattern maps to CWE-441: Unintended Proxy or Intermediary ('Confused Deputy') because the client acts as a powerful proxy for the server's chosen destination, and to CWE-918: Server-Side Request Forgery (SSRF) because attacker-controlled values can steer the client to send authenticated requests to internal or sensitive network locations without validating those targets.
The bug stems from over-trusting server-provided connection metadata when reconfiguring the client's base URL.
AppiumCommandExecutor's setDirectConnect() method accepts directConnectHost, directConnectPort, and directConnectPath from the NEW_SESSION response and reconstructs the endpoint used for subsequent WebDriver commands.
This pattern maps to CWE-441: Unintended Proxy or Intermediary ('Confused Deputy') because the client acts as a powerful proxy for the server's chosen destination, and to CWE-918: Server-Side Request Forgery (SSRF) because attacker-controlled values can steer the client to send authenticated requests to internal or sensitive network locations without validating those targets.
Potential impact
- A malicious or compromised Appium server may redirect all WebDriver session traffic to an attacker-controlled endpoint.
- Attackers could intercept, modify, or replay session commands and responses, potentially altering automated tests or exfiltrating sensitive test data.
- The client may be used as an unintended SSRF channel to reach internal network services not otherwise exposed.
- Cloud metadata services (IMDS) could be accessed via redirected requests, potentially leading to credential theft and further cloud account compromise.
- Internal APIs or admin interfaces reachable from the client's network position could be probed or abused.
- A malicious or compromised Appium server may redirect all WebDriver session traffic to an attacker-controlled endpoint.
- Attackers could intercept, modify, or replay session commands and responses, potentially altering automated tests or exfiltrating sensitive test data.
- The client may be used as an unintended SSRF channel to reach internal network services not otherwise exposed.
- Cloud metadata services (IMDS) could be accessed via redirected requests, potentially leading to credential theft and further cloud account compromise.
- Internal APIs or admin interfaces reachable from the client's network position could be probed or abused.
General mitigation guidance
Risk reduction typically focuses on constraining where the client is willing to redirect and tightening trust boundaries around Appium servers.
Useful patterns include:
- Enforcing a strict allowlist of acceptable hosts, domains, or IP ranges before applying any direct-connect parameters from server responses.
- Disabling
directConnectin environments where servers are shared, multi-tenant, or not under strong administrative control. - Treating server-supplied endpoint hints as untrusted data, requiring explicit validation against organizational policies before use.
- Isolating test infrastructure networks and limiting their ability to reach internal services, metadata endpoints, and other high-value targets.
- Applying least-privilege network permissions and outbound firewall rules from test runners so that even misdirected traffic has constrained reach.
Risk reduction typically focuses on constraining where the client is willing to redirect and tightening trust boundaries around Appium servers.
Useful patterns include:
- Enforcing a strict allowlist of acceptable hosts, domains, or IP ranges before applying any direct-connect parameters from server responses.
- Disabling
directConnectin environments where servers are shared, multi-tenant, or not under strong administrative control. - Treating server-supplied endpoint hints as untrusted data, requiring explicit validation against organizational policies before use.
- Isolating test infrastructure networks and limiting their ability to reach internal services, metadata endpoints, and other high-value targets.
- Applying least-privilege network permissions and outbound firewall rules from test runners so that even misdirected traffic has constrained reach.
How teams detect issues like this
Security and QA teams can look for this pattern using:
- Static analysis rules that flag code enabling
directConnect(true)without accompanying host or URL validation logic. - Code review checklists that prompt reviewers to verify how Appium/WebDriver endpoints are constructed and whether server-provided URLs are trusted implicitly.
- Centralized logging or proxying of outbound HTTP(S) traffic from test runners to identify unexpected destinations or traffic to internal-only services.
- Configuration audits of CI/test environments to ensure that Appium servers are trusted, single-tenant where possible, and not arbitrarily managed by untrusted users.
Automated code scanning and policy-as-code tools can be configured to detect usages of insecure connection reconstruction patterns and highlight them before deployment.
Security and QA teams can look for this pattern using:
- Static analysis rules that flag code enabling
directConnect(true)without accompanying host or URL validation logic. - Code review checklists that prompt reviewers to verify how Appium/WebDriver endpoints are constructed and whether server-provided URLs are trusted implicitly.
- Centralized logging or proxying of outbound HTTP(S) traffic from test runners to identify unexpected destinations or traffic to internal-only services.
- Configuration audits of CI/test environments to ensure that Appium servers are trusted, single-tenant where possible, and not arbitrarily managed by untrusted users.
Automated code scanning and policy-as-code tools can be configured to detect usages of insecure connection reconstruction patterns and highlight them before deployment.
