Summary
When directConnect(true) is enabled, appium/java-client unconditionally
accepts directConnectHost, directConnectPort, and directConnectPath
from the server's NEW_SESSION response and silently redirects all subsequent
session traffic to the attacker-specified endpoint — with no allowlist,
no host validation, and no user notification.
Affected Code
AppiumCommandExecutor.java (line 196–219): setDirectConnect() builds
a new URL from server-supplied fields and calls overrideServerUrl(newUrl)
without validating host/IP.
DirectConnect.java: getUrl() constructs protocol://host:port/path
with no allowlist.
Root Cause
Only the protocol is validated (must equal "https"). The destination host
and port are never checked against any allowlist or denylist.
PoC (confirmed)
A rogue server injecting directConnectHost=127.0.0.1:4443 causes the
client to silently redirect all post-session commands:
[bootstrap] POST /wd/hub/session
[bootstrap] Injecting directConnect -> https://127.0.0.1:4443/wd/hub
[redirect-target] HIT #1: GET /wd/hub/session/poc-session-001/source
[redirect-target] HIT #2: DELETE /wd/hub/session/poc-session-001
Original source code unmodified — confirmed via git diff HEAD (empty).
Evidence Screenshots
Screenshot 1 — Rogue server capturing redirected traffic:

Screenshot 2 — Java client processing response from attacker host:

Impact
- Full interception of session traffic
- Network pivot to internal hosts (RFC-1918, 169.254.169.254)
- Cloud credential theft via IMDS endpoint
- Escalates to ~8.1 High in CI/CD environments where directConnect(true)
is set in shared base configuration
Suggested Fix
Add allowlist validation before overrideServerUrl() is called, and/or
block RFC-1918/loopback/link-local destinations by default.
poc_appium_directconnect.zip
References
Summary
When
directConnect(true)is enabled, appium/java-client unconditionallyaccepts
directConnectHost,directConnectPort, anddirectConnectPathfrom the server's NEW_SESSION response and silently redirects all subsequent
session traffic to the attacker-specified endpoint — with no allowlist,
no host validation, and no user notification.
Affected Code
AppiumCommandExecutor.java(line 196–219):setDirectConnect()buildsa new URL from server-supplied fields and calls
overrideServerUrl(newUrl)without validating host/IP.
DirectConnect.java:getUrl()constructsprotocol://host:port/pathwith no allowlist.
Root Cause
Only the protocol is validated (must equal "https"). The destination host
and port are never checked against any allowlist or denylist.
PoC (confirmed)
A rogue server injecting
directConnectHost=127.0.0.1:4443causes theclient to silently redirect all post-session commands:
[bootstrap] POST /wd/hub/session
[bootstrap] Injecting directConnect -> https://127.0.0.1:4443/wd/hub
[redirect-target] HIT #1: GET /wd/hub/session/poc-session-001/source
[redirect-target] HIT #2: DELETE /wd/hub/session/poc-session-001
Original source code unmodified — confirmed via
git diff HEAD(empty).Evidence Screenshots
Screenshot 1 — Rogue server capturing redirected traffic:
Screenshot 2 — Java client processing response from attacker host:
Impact
is set in shared base configuration
Suggested Fix
Add allowlist validation before
overrideServerUrl()is called, and/orblock RFC-1918/loopback/link-local destinations by default.
poc_appium_directconnect.zip
References