OpenClaw Security Risks: Two Advisories and a Phone-Agent Access Check
Check two OpenClaw advisories, affected versions and fixes, then audit tool access and compare it with the Android permissions used by FoneClaw.
- Two OpenClaw advisories affect versions before 2026.8.1 under specific approval or provider configurations; 2026.8.1 is the first stable fix.
- Update OpenClaw and paired execution clients, remove risky standing approvals, and set explicit third-party provider endpoints where needed.
- Run the OpenClaw security audit after changes, then inspect the access actually granted to tools, plugins, accounts, and network routes.
- Compare FoneClaw's enabled Android tools and approval settings with the configured OpenClaw environment; neither product's name establishes a security ranking.
Check the Affected Version and Configuration
OpenClaw security risks are most useful to discuss in terms of the installed version and the access a particular setup grants. Two official advisories identify concrete conditions affecting OpenClaw versions before 2026.8.1. Version 2026.8.1 is the first stable fix for both; compare that threshold with the version actually installed rather than assuming every OpenClaw installation has the same exposure.
| Advisory | Affected condition | Fix and interim action |
|---|---|---|
| GHSA-3mq7-q27j-mq7q | Before 2026.8.1, a reusable exec approval matched command arguments without binding the working directory. An operator first had to grant an allow-always approval; using the approved command after the working directory changed could affect different files. | Upgrade OpenClaw and paired native execution clients to 2026.8.1 or later. Until then, remove standing approvals for commands whose effect depends on the directory and approve each use for its intended directory. |
| GHSA-vhpg-cq3w-v8p9 | Before 2026.8.1, a pinned third-party OpenAI-compatible session could retain that provider's credential after model reload while the SDK selected its default endpoint, if the model metadata lacked an explicit base URL. | Upgrade to 2026.8.1 or later. Before upgrading, set an explicit base URL for the third-party provider and avoid continuing pinned sessions after model-default changes. Rotate the affected credential if this condition was observed. |
The first case concerns the scope of an approval that was already granted. It is not an unauthenticated command-execution claim. The second concerns a particular provider and session configuration; it does not establish that every API key was disclosed. Both illustrate why a permission or approval must be checked against the exact directory, endpoint, and task it is meant to authorize.
For a setup that needs shell commands, files, browser access, plugins, or connected accounts, list those exposures before drawing conclusions from either advisory. OpenClaw provides controls for tool access and hardening; a narrowly configured installation has a different exposure from one with broad standing access.
Audit the Installation After Changes
Check the installed OpenClaw version and any paired native execution clients, apply the relevant fix, then review standing exec approvals and third-party provider base URLs. The official OpenClaw security audit guide documents these read-only audit commands:
openclaw security auditchecks the configured security posture.openclaw security audit --jsonprovides structured findings for comparison or records.openclaw security audit --deepalso attempts a live Gateway probe, so use it when the Gateway is available and that probe is appropriate.
Read the findings for access policies, tool exposure, network and authentication settings, browser exposure, filesystem permissions, and plugin allowlists. Review inbound messaging allowlists and any credentials available to enabled tools. An audit finding about broad configured trust calls for a configuration decision; it is not, by itself, evidence of a new software vulnerability.
The audit's --fix option changes selected policies and filesystem or ACL settings. Review the proposed effects before using it, then rerun the audit and record the remaining findings. A clean audit helps confirm the checked configuration but does not replace testing the task's actual permissions and outcomes.
Compare Access the Task Can Actually Use
OpenClaw and FoneClaw act on different surfaces. Compare a specific task's reachable resources, not an assumed security rank.
| Access question | Configured OpenClaw setup | FoneClaw Android task |
|---|---|---|
| What can the action reach? | Inspect enabled shell commands, working directories, files, network routes, browser access, plugins, and connected accounts. | Inspect Android permissions and the phone tools enabled for the task, including app, visible-screen, image, or calendar access. |
| What needs approval? | Check command approvals and their scope, including reusable approvals and execution-client settings. | Check the overall Tool Approval Mode, per-tool controls, and overrides; a tool's default classification does not guarantee a prompt under every configuration. |
| Where does context go? | Check the selected model provider, credentials, tool outputs, and permitted network destinations. | Check the selected backend or custom model route; supplied phone context may be processed outside the device. |
| How is the result checked? | Inspect the changed file, external service, or tool result where the action occurred. | Inspect the current app or Android result after a supported action. |
For example, FoneClaw can open a launchable app, or open it and read accessible content visible on its screen. Capturing a screenshot is a distinct image action for an explicit request. Creating a calendar event changes external state. Our FoneClaw Features page describes these supported actions and their classifications; the configured approvals and Android grants still determine practical access.
AI Agent Sandbox vs Android Permissions: Three Boundaries That Matter explains why runtime containment, device access, and action approval answer different questions. For the identity and record needed around consequential tools, see AI Agent Identity, Permissions, and Audit Trails for Phone Tool Governance.
Verify Denial and Outcome With a Harmless Task
Use a proposed check on a non-sensitive task. In an OpenClaw setup, disable exec for the test session and request a harmless directory read such as pwd; confirm that the unavailable tool is denied. In FoneClaw, disable an app-opening action, request that it open a familiar installed app, and check that the app did not change. Restore only the access needed for the intended task, then inspect its actual result. These are exercises to perform in your own setup, not reported test outcomes.
When an action is allowed, verify the target as well as the approval: the intended directory, provider endpoint, app, or calendar. A prompt can ask for approval while still naming the wrong target. Keep credentials separate, limit standing access, and inspect external state before retrying an uncertain action.
Skills and plugins introduce another source of instructions and capabilities. AI Agent Skill Security Needs Phone Permission Checks covers how to review that trust separately. For either product, the useful result is a documented version, a known configuration, an observed denial when access is off, and a verified outcome when the intended action is permitted.