Thanks for the reply.
Actually that code (I mean the one where they started clearing POSTed data) was the "fix" WPE rushed into during the "grace period".
The contract existing before, was that you throw in a user callback in a backend input and it executes that. It still did that after the rush fix (which was committed by Otto, but supposedly delivered to him by WPE), but with some more clearing:
- POST is cleared
- registered functions with wp_ are cleared

call_user_func was still called. Clearly, the idea behind is is not "some kind of sanitized env" since the start.
The idea was "the user can throw in a callback and it will be executed".
Then someone said "but that is unsafe" (And it is!)
But the unsafely thing here is not "You have access to POST data or wp_ functions".
That is the default in ANY code attached to WP anyway, and while being part of the danger here, the real danger is that an arbitrary POST EDITOR can throw in a callback and it executes that.

Which is why, yes, somehow, clearing posted data and excluding already existing methods like wp_ stuff is sort of a "fix" for that, since before the Post Editor did not even need to write the callbacks code: he could just have called a eventually bad (in context) registered method in core. So the "fix" does somehow mitigate, but not fix the issue.

I can see upstream builds on that idea even more. However the code still uses user callbacks, and those user callbacks can still be unsafe. You just need to throw in a callback that does something malicious, which does not even be an obvious malicious code. It could be a callback registered elsewhere, where the else context makes sense and is not flagged, but in conjunction with this ACF feature, would be malicious.

It should be clear that the security issue here is not what you can access during that callback - the security issue is that the callbacks are not whitelisted, and/or allowed at all (which can be considered a problem too, but would break potency of the features of course if removed)

Not putting my hands in fire for this, but I believe there is reason I Could not find a CVE yet for this alleged security issue, only a reserved one. I suspect that is, because the issue is still there, and publishing it, would immediately render it more dangerous.
I again would love to learn that I am wrong here.

I do stand by my original post that said:
> because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.

This stands true: the security issue was not fixed. If we start to call incomplete fixes a fix, then we can as well call anything anywhere a fix. Heck, I moved around some lines and cleared some of the data. It's fixed! That would never hold true. In all and every case, plugin review team would immediately review the FIX before you can even say "but", and they would immediately throw it back at you, asking for an _actual_ fix. Especially with call_user_func.
This has not happened here at all, which just adds to the fun of the day.

I feel the discussion should evolve around this, and The Guys who yelled "Security" should come forward and explain to the public what they actually fixed, if they truly believe this fixes the issue, if they truly believe that ACF (sorry, SCF) is now _safe_, or not.

My point stands that it (the core issue) has not been fixed.

Sorry if it got a long post.