Bug#1141449: trixie-pu: package node-lodash/4.17.21+dfsg+~cs8.31.198.20210220-9+deb13u1
Jonathan Wiltshire <[email protected]> Sat, 25 Jul 2026 12:26:27 +0100
| Newsgroups | gmane.linux.debian.devel.release |
|---|---|
| Message-ID | <amSdY2dgVJjQP2ek__3789.32070905051$1784978966$gmane$org@powdarrmonkey.net> |
Control: tag -1 = trixie confirmed On Fri, Jul 24, 2026 at 06:58:09PM +0530, Utkarsh Gupta wrote: > 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? Yes, if we're right about the issue that sounds the appropriate fix. But I agree this is better handled upstream. I'll take the current fixes in case upstream is not responsive in time before the point release, even though it's a while away yet. Thanks,