OpenClaw Hardens Vault Setup Plans Against Symlink and File-Clobber Attacks
A security fix on OpenClaw main makes Vault and 1Password secret-plan writes exclusive and owner-only. Operators should protect old plans and verify the containing release.
OpenClaw has merged a security fix for a local file-write boundary in openclaw vault setup. Before the fix, the generated JSON plan could inherit permissive permissions, overwrite an existing file, or follow a pre-positioned symbolic link. That matters because the plan can contain provider secrets.
The correction is on main; a merge is not proof that an installed package contains it. Operators should identify the exact release or source commit before relying on the new guarantees.
Who needs to act
| Situation | Safe response |
|---|---|
| You previously generated a Vault or 1Password setup plan | Locate it without printing its contents, restrict access, complete the intended import, then remove it through your normal secure-file process when no longer needed. Consider credential rotation if an old plan was exposed to other users or an untrusted directory. |
| You run setup in a shared, writable or automation-controlled directory | Stop using predictable pre-existing output paths on an older build. Use a private directory and a new path until you have a containing build. |
You maintain wrappers around --plan-out |
Test that an existing destination and a symlink destination are rejected rather than overwritten. Do not “fix” the rejection by deleting an unknown path automatically. |
| You do not use Vault or 1Password secret-plan setup | No immediate action is indicated by this change alone. |
What changed
PR #113707 moves hardened plan creation into the shared secret-reference setup boundary used by Vault and 1Password.
On POSIX systems, the merged implementation creates the destination exclusively, enforces and verifies mode 0600, checks that the open file still belongs to the expected pathname before writing, syncs the content, and cleans up only when it can prove the pathname still refers to the file it created. An existing file or symbolic-link destination is rejected rather than silently replaced.
Windows continues through the protected atomic writer and its existing ownership, DACL and reparse-path checks. The important product change is shared policy: Vault no longer has a weaker plan-file path than the sibling 1Password flow.
The plan format, selected output path, --plan-out option and follow-up command remain unchanged. This is hardening of how bytes reach disk, not a new secrets backend or plan schema.
Why this is a security boundary
A plan file is temporary operational state, but temporary does not mean harmless. If a predictable path can be planted as a symlink, a privileged setup run can write secrets into an attacker-chosen target. If an existing file is overwritten, the same primitive can damage unrelated data. If permissions are inherited from a permissive directory or process mask, other local users may read the plan.
The merged behavior addresses all three failure classes. It does not make the surrounding machine trustworthy, encrypt the JSON at rest, or revoke secrets that may already have leaked.
Operator verification
After moving to a build that explicitly contains landed commit 481d826f:
- run setup only with synthetic or disposable credentials in a private test state directory;
- confirm a newly created plan is readable only by its owner on POSIX;
- confirm an already existing destination is preserved and the command refuses to overwrite it;
- confirm a symbolic-link destination is refused and its target remains unchanged;
- verify your wrapper does not log the plan body, destination credentials or follow-up command arguments; and
- inventory and securely retire old plans after their references have been installed.
Upstream reports that its pre-fix regression reproduced mode 0664, existing-file overwrite and symlink-target overwrite. The final focused suites reported 58 passing tests across five files, and a live CLI run reported mode 0600 plus preserved existing and symlink targets. Those are upstream results; OpenClaw Academy did not repeat the filesystem tests independently.
Bottom line
Treat setup plans as secret-bearing files, not disposable CLI clutter. Until the fix reaches the package you deploy, use a private directory, a fresh destination and strict local permissions. After upgrading, test refusal behavior as well as the happy path—secure file creation is defined by what it will not overwrite.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF