OpenClaw audit finds 23 confirmed vulnerabilities across several permission-handling patterns

A request arrives inside OpenClaw with restricted access, starts a second task, and the second task no longer carries the restriction ^[13]. Two different repairs follow from that, and according to OpenClaw's recap both were needed: in some cases the original permissions had to be propagated to the follow-on work, and in others the follow-on work should never have held tool access at all ^[14]. The recap's example is filename generation, where producing a name does not require access to an operator's tools ^[15].

A second group of findings sat between the check and the act. Trail of Bits found places where OpenClaw evaluated one identifier and then acted on another ^[17]. The project keeps older names for some identities and features so that existing configurations keep working, so a policy could evaluate one alias while the runtime resolved and used a different name ^[17]. The security decision now applies to the canonical identity or feature name the runtime will actually use ^[18]. The same gap appeared with resources: one check inspected only part of an archive before the full archive was extracted, and another approved a file path that subsequently changed ^[19]. Approval is now bound to the final file, identity or operation, and a changed target requires another check ^[20].

Time was the other axis. A run that began while memory access was enabled could keep reading memory after the operator disabled it, because the permission had been checked only at startup ^[21]. OpenClaw moved those checks closer to execution, so a tool consults the current configuration whenever it acts ^[22]. That turns one configuration read per run into one read per action ^[28]. On one machine reading a local config file, that is cheap. I would want it measured anywhere the configuration sits behind a network call.

Twenty-seven reports went in and 24 came back with a severity rating, leaving three unrated, which the recap describes as defense-in-depth findings ^[26][24]. Sixteen of the 24, about two thirds, were Medium ^[27]. What makes 23 a useful number is that the same gap was reachable from many places. A user request can launch subagents, delayed jobs, cached operations or calls into messaging and file-handling components, and every handoff creates another place where the original authorization decision can become detached from the work it was meant to limit ^[16].

For that count to say anything about a system you run, two things have to hold. The agent needs standing access to something like messages, memory, files and host tools ^[1]. And the runtime has to branch work: a design that handles one request to completion in one process has fewer handoffs to lose a permission across ^[16]. Conventional software tends to finish a request inside a short, bounded transaction, while an agent may keep working after the user closes a chat, changes a setting or revokes access ^[30].

The severity totals and the remediation status come from OpenClaw's own account of the engagement ^[9]. The recap groups findings by recurring engineering pattern instead of reporting advisory by advisory ^[11], some advisories were closed without publication because the flaws were fixed before reaching a stable release ^[10], and the project's published advisories sit on its GitHub security advisories page ^[29]. OpenClaw's security policy defines the software as local-first infrastructure for trusted operators, not a shared service designed to isolate adversarial tenants ^[23]. That policy bounds severity: whether the alias mismatch is exploitable depends on who can put the alias into the configuration in the first place ^[17]. OpenClaw was built by Peter Steinberger to run an AI agent on a user's own computer across messages, memory, files and other tools ^[2].