zlacker

Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.

>>filear+(OP)
This comment from a dupe thread is worth considering: >>46137352

>>filear+(OP)
I see this type of vulnerability all the time. Seen it in Java, Lua, JavaScript, Python and so on.

I think deserialization that relying on blacklists of properties is a dangerous game.

I think rolling your own object deserialization in a library that isn’t fully dedicated to deserialization is about as dangerous as writing your own encryption code.

>>filear+(OP)
not `__proto__` but likely `constructor`, if you access `({}).constructor` you'd get the Object constructor, then if you access `.constructor` on that you'd get the Function constructor

the one problem I haven't understood is how it manages to perform a second call afterwards, as only being able to call Function constructor doesn't really amount to much (still a serious problem though)

>>harral+C71
Only if you're deserializing into objects with behavior.

>>int_19+aV1
What does data in a program do apart from eventually modify behavior?