OpenClaw Workspace .env Advisory: Who Needs to Upgrade

OpenClaw has published a high-severity advisory for a credential-boundary problem fixed in version 2026.5.28. In affected releases, workspace dotenv files could override provider credentials when lower-trust input reached the relevant path.

The immediate decision is simple: if your OpenClaw version is older than 2026.5.28, upgrade. Current stable and beta releases are newer than the patched version.

Operator decision

Check the installed CLI version with:

openclaw --version

Then follow the official updating guide rather than copying an installation command from an old tutorial.

What the advisory actually says

GHSA-4pqj-3c56-5fqq affects the npm package openclaw in versions earlier than 2026.5.28. GitHub records the advisory as high severity with a CVSS 3.1 score of 7.1 and the vector:

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

That vector describes a local attack path with user interaction—not an unauthenticated remote exploit against every internet-facing Gateway. The advisory says practical impact depends on configuration and whether lower-trust input can reach the affected workspace path.

The consequence is still serious. Provider credentials sit on a privileged boundary: changing which credentials or provider configuration a process uses can expose data or redirect trusted work into an attacker-influenced context.

What changed in the patched release

The official 2026.5.28 release notes state that OpenClaw now ignores workspace dotenv provider credentials. The release was published on 30 May 2026, and the corresponding npm package is available under the same version.

This narrows the authority of workspace-local environment files. A workspace can still contain code and instructions that deserve distrust, but it should not be able to replace the provider credentials owned by the OpenClaw runtime.

Who had meaningful exposure?

The advisory is most relevant when all of the following were true:

1. The deployment ran a version before 2026.5.28.
2. A lower-trust user, repository, archive or automated input could influence workspace files.
3. The affected feature and configuration path were enabled and reachable.
4. Provider credentials or provider-bound data were present in the same operating context.

Risk rises when one shared Gateway handles mutually untrusted users or repositories. It falls when workspaces are operator-controlled, tools and channels are tightly allowlisted, and untrusted workloads are isolated—but upgrading remains the correct fix.

What to do after upgrading

1. Confirm the running process changed

Do not stop at updating a package on disk. Restart the actual Gateway or supervisor-managed service and verify the version reported by the running installation.

2. Review lower-trust workspaces

Look for workspace .env files or imported repositories that could have supplied provider-related values. Their presence is not proof of exploitation, but it identifies where the affected trust boundary may have existed.

3. Rotate credentials when exposure is plausible

If an untrusted party controlled workspace dotenv content while an affected version was running, rotate the provider credentials that could have been used in that environment. Avoid reflexively rotating every secret in the organisation; scope the response to the potentially exposed deployment and providers.

4. Separate mutually untrusted users

The advisory explicitly preserves OpenClaw’s trusted-operator model. Authenticated Gateway operators, installed plugins and intentional local execution surfaces remain trusted unless another boundary is crossed. Do not use one shared Gateway as a security boundary between people who should not trust each other.

5. Keep allowlists narrow

Use the official Gateway security guidance to review channel access, tool policy, sandboxing and network exposure. Those controls do not replace the patch, but they reduce the paths through which lower-trust input can become operational authority.

What this advisory does not establish

There is no CVE listed on the advisory, no published evidence there of mass exploitation, and no claim that every pre-2026.5.28 deployment leaked credentials. The advisory also does not justify treating all local operators or installed plugins as hostile under OpenClaw’s security model.

The correct response is proportionate: upgrade old installations, investigate where lower-trust workspace content existed, rotate credentials when exposure is plausible, and keep distinct trust domains on distinct Gateways.

Bottom line

This is a real credential-boundary flaw with a straightforward fix. OpenClaw versions before 2026.5.28 should be removed from service. Operators already on 2026.5.28 or newer are past the affected version range, but should still prevent workspace content from becoming an implicit authority over runtime secrets.

Verification note: this analysis uses the official GitHub advisory, official release notes, npm package metadata and current OpenClaw security documentation. We did not reproduce the vulnerable behavior or observe exploitation in a live deployment.