Add prototype pollution guard to resolveConfigPath - #59694

Greptile Summary

This PR adds a prototype pollution guard to resolveConfigPath in src/shared/config-eval.ts by importing and calling the shared isBlockedObjectKey utility before traversing each path segment. The fix correctly blocks access to __proto__, prototype, and constructor key segments, matching the security pattern already used across the codebase (e.g. parseConfigPath, merge-patch.ts, runtime-overrides.ts).

• Imports isBlockedObjectKey from ../infra/prototype-keys.js — correctly resolves to src/infra/prototype-keys.ts, same underlying module used everywhere else.
• Guard is placed in the right position inside the loop: after the null/non-object early-return and before the property access, so it only runs when traversal would actually proceed.
• No existing behavior is changed for valid (non-blocked) paths; the function continues to return undefined for blocked segments, consistent with its existing sentinel value for unresolvable paths.
• The companion getConfigValueAtPath in src/config/config-paths.ts intentionally omits this guard because it only receives pre-validated path arrays from parseConfigPath; resolveConfigPath takes raw strings directly, so an inline guard is the right approach here.

Confidence Score: 5/5

• Safe to merge — small, well-scoped security fix with no behavioral changes for valid paths.
• The change is minimal (3 lines added), follows the established codebase pattern exactly, uses a well-tested shared utility, and is placed correctly in the traversal loop. No regressions are expected for legitimate path strings.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "Add prototype pollution guard to resolve..." | Re-trigger Greptile}

Codex review: needs maintainer review before merge. Reviewed June 28, 2026, 4:42 PM ET / 20:42 UTC.

Summary
Adds blocked-object-key checks to shared config path resolution and defaults fallback, plus regression tests for resolver and default-path prototype-key cases.

PR surface: Source +15, Tests +19. Total +34 across 2 files.

Reproducibility: yes. Source inspection shows current main indexes raw dotted path segments and uses pathStr in defaults; the contributor also supplied Node v22.22.1 main-vs-PR output for blocked paths and defaults fallback.

Review metrics: 1 noteworthy metric.

• Config fallback lookup: 1 hardened. The defaults fallback now rejects blocked prototype-key paths and inherited default properties, which matters because hook and skill eligibility use this helper.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

• [P1] Exact-head CI and mergeability still need to finish after the latest force-push; this read-only review did not run local tests.

Maintainer options:

1. Decide the mitigation before merge
   Land the narrow shared-helper hardening after maintainer review and exact-head gates, since current main and the latest release still lack the guard.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• No ClawSweeper repair lane is needed; the branch already contains the narrow source/test change and is waiting on maintainer review plus exact-head gates.

Security
Cleared: The diff narrows prototype-chain access in an existing config helper and does not broaden secrets, dependencies, CI, publishing, or downloaded code execution paths.

Real behavior proof (per @clawsweeper request)

Inline reproduction with Node v22.22.1 — comparing resolveConfigPath on main vs. the version in this PR, using the actual isBlockedObjectKey implementation from src/infra/prototype-keys.ts (new Set(["__proto__", "prototype", "constructor"])):

path                          | why                                       | old (main)                     | new (this PR)
------------------------------+-------------------------------------------+--------------------------------+--------------------
feature.enabled               | normal path (no break)                    | true                           | true
nested.a.b                    | normal nested path                        | 42                             | 42
__proto__                     | attack: direct __proto__                  | [null-proto object]            | undefined  ← blocked ✅
__proto__.toString            | attack: __proto__ chain                   | [Function: toString]  ← LEAK 🔴| undefined  ← blocked ✅
constructor                   | attack: Object constructor                | [Function: Object]  ← LEAK 🔴  | undefined  ← blocked ✅
constructor.constructor       | attack: Function constructor (RCE)        | undefined  ← blocked ✅        | undefined  ← blocked ✅
prototype                     | attack: prototype access                  | undefined  ← blocked ✅        | undefined  ← blocked ✅

Key observations:

1. Real leaks on main — __proto__.toString and constructor paths today return live function references ([Function: toString], [Function: Object]), which is exactly the primitive a prototype-pollution chain needs. After the PR, both return undefined.

2. constructor.constructor already returns undefined on main, but only because the typeof current !== "object" check at the next iteration short-circuits — i.e. it's a side-effect defense, not an intentional one. The moment current happens to be an array, a wrapper object, or a hostile prototype-chain entry, that fall-back disappears. The explicit isBlockedObjectKey guard makes the defense stable across types.

3. No regression on normal paths — feature.enabled and nested.a.b return identical values pre- and post-fix, so the only behavioral delta is on the three blocked keys.

This satisfies the "blocked paths return undefined" acceptance criterion the review asked for. If a vitest regression case is still required, the test surface is just expect(resolveConfigPath(cfg, "__proto__.toString")).toBeUndefined() × 3 paths — happy to push that as a follow-up commit if maintainers prefer it landed together.

@clawsweeper re-review

ClawSweeper PR egg

✨ Hatched: 💎 rare Mossy Branchling

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 💎 rare.
Trait: collects tiny proofs.
Image traits: location proof lagoon; accessory miniature diff map; palette cobalt, lime, and pearl; mood bright-eyed; pose nestled inside a glowing shell; shell starlit enamel shell; lighting cool dashboard glow; background tiny shells and proof notes.
Share on X: post this hatch
Copy: My PR egg hatched a 💎 rare Mossy Branchling in ClawSweeper.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Added the requested direct runtime proof for the defaults fallback path in isConfigPathTruthyWithDefaults.

Behavior addressed: blocked prototype-key paths do not resolve through either inherited defaults or own defaults, while ordinary unresolved paths still use own defaults.

Real environment tested: local OpenClaw source checkout on this PR branch with Node v22.22.1.

Exact steps or command run after this patch:

node --import tsx --input-type=module <<'NODE'
import { isConfigPathTruthyWithDefaults } from './src/shared/config-eval.ts';
// Exercise normal config, own defaults, inherited defaults, and blocked keys.
NODE

node scripts/test-projects.mjs src/shared/config-eval.test.ts

Evidence after fix:

{
  "node": "v22.22.1",
  "rows": [
    { "path": "feature.enabled", "why": "real config true", "result": true },
    { "path": "browser.enabled", "why": "real config false overrides default", "result": false },
    { "path": "browser.missing", "why": "own default true for unresolved normal path", "result": true },
    { "path": "browser.inherited", "why": "inherited default ignored", "result": false },
    { "path": "constructor", "why": "blocked path ignores inherited default", "result": false },
    { "path": "__proto__.enabled", "why": "blocked path ignores inherited default", "result": false },
    { "path": "prototype.enabled", "why": "blocked path ignores inherited default", "result": false },
    { "path": "constructor", "why": "blocked path ignores own default", "result": false },
    { "path": "__proto__.enabled", "why": "blocked path ignores own default", "result": false },
    { "path": "prototype.enabled", "why": "blocked path ignores own default", "result": false }
  ]
}

Observed result after fix: constructor, __proto__.enabled, and prototype.enabled all return false through the production isConfigPathTruthyWithDefaults helper even when defaults try to provide those paths. A normal unresolved path still uses an own default (browser.missing -> true), and inherited defaults are ignored (browser.inherited -> false).

Validation:

Test Files  1 passed (1)
Tests       14 passed (14)

What was not tested: no full gateway startup was run; this proof is scoped to the shared config-eval helper used by skill/hook eligibility.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/27512786032
• Updated: 2026-06-14T21:42:01.565Z