OpenClaw’s Trail of Bits audit found 23 confirmed vulnerabilities. Its LTS-equivalent line is now 2026.7.35

OpenClaw says a Trail of Bits security engagement found 23 confirmed vulnerabilities across the project, including two rated high severity. The fixes are now part of OpenClaw’s regular and extended-stable release lines, giving the project a useful test of whether its new LTS-like channel is more than a label.

OpenClaw’s September 21 audit recap says the work ran through OpenAI’s Patch the Planet initiative. Trail of Bits submitted 27 private repository advisories and three standalone hardening pull requests. Of the advisories, 24 described severity-rated vulnerabilities. OpenClaw classified 23 as confirmed vulnerabilities and said the remaining one had been fixed before Trail of Bits submitted it.

The 24 severity-rated reports broke down to zero critical, two high, 16 medium, and six low. Three other findings were classified as defense-in-depth issues because they did not cross a documented trust boundary. OpenClaw says every actionable issue was repaired and all three hardening pull requests were merged.

That is a substantial review, but the scope of the claim matters. The advisories were private, and the recap does not provide CVE identifiers or public exploit details. The repair status is OpenClaw’s account of the engagement, not an independent retest published by Trail of Bits.

The recurring failure was permission context

OpenClaw’s account describes four related classes of problems rather than a single headline bug.

First, permissions could be lost when a request handed work to another component. The project’s example is simple: a filename generator has no reason to receive tools merely because the request that started it had them. Follow-on work must carry the original limits forward, or avoid receiving access it does not need.

Second, older configurations sometimes gave one identity or feature more than one name. A security check could validate one name while the system later used another. The fix was to resolve the exact identity or feature that would be used before applying the policy.

Third, some checks did not cover the final operation. OpenClaw describes an archive check that saw only part of an archive before extraction, and a file path that changed after approval. The practical rule is to bind approval to the exact resource and action that will happen, then check again if either changes.

Finally, permissions could change while an agent was still running. OpenClaw says a run that had already received memory access could continue reading memory after an operator disabled it. Moving checks closer to the moment of use is less elegant than a single gate at startup, but it matches the way long-running agent work actually behaves.

Those are the findings worth carrying into deployment decisions. “23 vulnerabilities fixed” is the useful top-line number; the more durable lesson is that agent security cannot stop at request admission. It has to follow the request through delegation, resource resolution, and execution.

Does OpenClaw offer an LTS version now?

Yes, with a naming and scope caveat. OpenClaw introduced an extended-stable channel in a July announcement. The project described it as a monthly, long-lived channel with backported security and reliability fixes. Each line begins at a .33 release, later backports increment the patch number, and a release is supported until the next extended-stable cut, for at least one month.

That original announcement was careful: extended-stable moved OpenClaw closer to official LTS releases. It did not present a conventional LTS product line with a long, fixed support promise.

The current release policy is more explicit about what exists today. It lists four user-facing channels: stable, extended-stable, beta, and dev. The extended-stable channel is a .33+ maintenance line from one of the two trailing completed months. The policy describes it as a Gateway distribution, together with official npm plugins and Docker images, and says its release notes identify a Gateway-only “LTS-equivalent” track.

The current 2026.7.35 GitHub release uses the same language: it calls itself a gateway-only extended-stable release and “our current equivalent to LTS.” That release also says 2026.7.33 and 2026.7.34 were unstable July-line builds that were not published as GitHub Releases; 2026.7.35 is the first GitHub release for that maintenance line and carries their cumulative notes.

As of September 22, the npm registry points the channels at:

• latest: 2026.9.5
• extended-stable: 2026.7.35
• beta: 2026.9.5

That split answers the practical question. OpenClaw now offers a maintained, slower channel for operators who do not want the newest regular train. It is not quite the same thing as a broad, frozen LTS promise for every product surface. The current documentation narrows the guarantee to the Gateway-oriented extended-stable track.

The operator takeaway

The audit fixes named in the recap were described as shipping in 2026.8.1 and 2026.7.33. The live channel has since moved forward: the registry now selects 2026.7.35 for extended-stable, and that release includes the cumulative July maintenance line plus later fixes.

To select the channel on an existing installation, OpenClaw’s current update documentation documents:

openclaw update --channel extended-stable

A new global npm installation can use the command in OpenClaw’s extended-stable announcement:

npm install -g openclaw@extended-stable

The safer reading of this week’s security post is not that OpenClaw is suddenly finished. It is that the project is pairing a concrete security remediation cycle with a release model that now gives the Gateway a slower track. For self-hosters, that is a meaningful change: the choice is no longer only “run the newest build or fall behind.” It is “follow the regular line, or follow the current LTS-equivalent maintenance channel,” while remembering that the latter is explicitly scoped to the Gateway track.