Summary
OpenClaw for iOS does not consistently enforce previously saved Gateway TLS certificate pins in authenticated Terminal and session Dashboard WebViews. If an attacker can redirect the expected host and port to a server with a different certificate trusted by iOS, the replacement page may capture Gateway credentials and enable operator-level access.
Affected context
The issue affects OpenClaw for iOS deployments within the affected version range when:
- A user has previously accepted and saved a Gateway certificate fingerprint
- Native Gateway connections enforce that saved fingerprint
- Authenticated Terminal or session Dashboard content is opened in a WebView that does not enforce the same pin
- An attacker can redirect the expected Gateway host and port
- The replacement endpoint presents a certificate accepted by the iOS system trust store
Under these conditions, an attacker-controlled Control UI page may be rendered in an authenticated context.
Exploit preconditions
- Attack surface: OpenClaw's authenticated Terminal and session Dashboard WebViews
- Required access: Ability to redirect or otherwise influence traffic for the same Gateway host and port
- Trust requirement: The attacker must present a certificate accepted by the device's system trust configuration
- User condition: A Gateway fingerprint must have been previously accepted, and the user must open the affected authenticated view
- Trigger point: Loading the replacement Control UI inside a WebView
- Why exploitation is possible: The WebViews omit enforcement of the saved Gateway TLS pin, allowing a trusted-but-different endpoint to receive authenticated content and expose credentials
Why this happens
The underlying flaw is inconsistent certificate validation across connection paths. Native connections enforce the saved Gateway fingerprint, but authenticated WebViews rely on broader platform certificate trust without applying the same pinning decision.
This maps to CWE-295: Improper Certificate Validation, because the application fails to validate that the presented certificate matches the expected Gateway identity for every sensitive connection path. The insecure pattern is treating platform trust as sufficient while omitting application-specific identity verification.
Potential impact
- An attacker could capture a Gateway token or password
- Stolen credentials may grant operator access to Gateway functions
- An attacker could read sensitive Gateway state
- Host-capable tools could be invoked without the user's intended authorization
- Gateway-managed systems or data could be exposed or altered
- Follow-on compromise could occur if operator privileges are broad
General mitigation guidance
Mitigation generally focuses on applying one consistent certificate-identity policy to every authenticated connection and embedded WebView.
Common defensive patterns include:
- Enforcing the saved Gateway certificate pin or equivalent identity check in all native and WebView paths
- Failing closed when certificate validation or pin comparison cannot be completed
- Avoiding reliance on system trust alone for connections with application-specific trust decisions
- Isolating authenticated content from endpoints that have not passed the same Gateway identity checks
- Limiting Gateway tokens and operator permissions according to least privilege
- Reducing credential exposure to rendered pages and restricting access to host-capable tools
- Providing clear re-pinning and trust-change workflows that require deliberate user confirmation
How teams detect issues like this
Detection can focus on consistency between transport security controls and authenticated content handling:
- Use static analysis to identify WebView or embedded-browser paths that omit certificate pinning or trust-decision callbacks
- Review code for differences between native Gateway connection validation and WebView validation
- Test certificate replacement, host redirection, and pin-mismatch behavior across every authenticated interface
- Add automated policy checks requiring equivalent identity validation for sensitive endpoints
- Monitor Gateway logs for unexpected operator sessions, token use, or host-capable tool invocation from unusual network locations
- Use mobile application security testing and automated review tools to inspect trust boundaries and credential exposure
