Hi Jonathan, On Wed, Jul 15, 2026 at 1:25 AM Jonathan Wiltshire <[email protected]> wrote: > JavaScript is not my forte, so I may be up the wrong tree here. But in: > > | if (key === '__proto__' && > | !hasOwnProperty.call(object, '__proto__')) { > | return false; > } > > Could it be that `object` here is always the original object, rather than > the object at the current point in the path, allowing a later `__proto__` > to slip through?
Interesting point. I was able to probably reproduce what you're saying. "object" in that guard is the original root object, it's never advanced as the loop walks the path. The hole is specific to __proto__ when the root carries an own __proto__ key. So only the __proto__ guard is affected and the impact is deletion, not assignment. Note this is upstream's code as shipped in 4.18.0 (commit fe8d32e), so it looks like a residual flaw in the upstream fix itself. I'll report it upstream: the proper correction is to check ownership against the current node during traversal rather than the root, I think? The current patch, however, does fix the CVE at hand, I think - so how'd you like to proceed? Do we land this (as is in other releases now) and follow up when fixed upstream, or would you like to wait for upstream to get back and incorporate those changes here first? - u
