Skip to content

fix(security): use Object.hasOwn to prevent prototype pollution bypass#35011

Closed
davidemanuelDEV wants to merge 1 commit intoopenclaw:mainfrom
davidemanuelDEV:fix/audit-channel-prototype-pollution
Closed

fix(security): use Object.hasOwn to prevent prototype pollution bypass#35011
davidemanuelDEV wants to merge 1 commit intoopenclaw:mainfrom
davidemanuelDEV:fix/audit-channel-prototype-pollution

Conversation

@davidemanuelDEV
Copy link
Copy Markdown
Contributor

Fixes #34926. Replaces in operator with Object.hasOwn() in hasExplicitProviderAccountConfig to prevent prototype chain traversal that could allow specially crafted accountIds like __proto__ to bypass the check.

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 4, 2026

Greptile Summary

Security Fix: Prototype Pollution Prevention

This PR makes a focused security hardening by replacing the in operator with Object.hasOwn() in hasExplicitProviderAccountConfig.

The vulnerability: The in operator traverses the prototype chain, allowing specially crafted accountId values like __proto__, constructor, or toString to pass validation by matching inherited prototype properties, even when no explicit configuration exists for these keys.

The fix: Object.hasOwn(accounts, accountId) only checks own properties, correctly rejecting prototype-inherited keys. Legitimate account IDs continue to work unchanged.

Assessment: This is a minimal, correct security fix with no side effects. The change is straightforward and uses the idiomatic modern replacement pattern.

Confidence Score: 5/5

  • This PR is safe to merge — it is a minimal, correct one-line security hardening with no side effects or behavioral changes to legitimate functionality.
  • The PR addresses a genuine prototype pollution vulnerability by replacing the in operator with Object.hasOwn(). The change is semantic and correct: in checks the entire prototype chain, while Object.hasOwn() only checks own properties. This is the idiomatic modern pattern, and there are zero behavioral differences for valid account IDs. The fix is self-contained, well-scoped, and introduces no new logic or dependencies.
  • No files require special attention.

Last reviewed commit: 3f94ab3

@benediktjohannes
Copy link
Copy Markdown
Contributor

Hello @davidemanuelDEV,

thank you very much for your contribution. I really appreciate your work. Since we already have another pull request that was opened earlier (#34929) addressing this issue, I recommend commenting on the other pull request if you would like to suggest any changes. Thank you very much nevertheless.

cc @shakkernerd, could you please close this so that we don’t run into confusion with multiple PRs? Thanks!

@dvrshil
Copy link
Copy Markdown
Contributor

dvrshil commented Mar 5, 2026

Thanks for the work, @davidemanuelDEV. This issue has been addressed by maintainer-selected PR #34982 (tracking issue #34926).\n\nTo keep the queue clean, I’m closing this as a duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Security]: Use of in operator in hasExplicitProviderAccountConfig can lead to prototype pollution bypass

4 participants