DanielLestrange

The issue affects _all_ models (inclusive the "hidden" guardian codex-auto-review model), and _only_ happens on the PRO plans (both 5x and 20x). It does not, under any circumstances, happen with the PLUS plan.

There is a probably related difference of CTX windows being different (and significantly larger on PLUS) between the plans, as well as an ominous and not-user-controllable flag `use_responses_lite` which is set to true on PLUS. These two discrepancies between the plans may or may not be the cause for the issue.

Amending the base prompt shows some improvements using the canary test prompts, NOT so during real world tasks however.

The API presents mixed results: from zero failures to 2/5 failures across runs.

These results have been taken from deterministic tests and analysis of historic data on both PLUS, PRO and API accounts. More details visible on the related GH issue in comments.

Hey, sorry I was offline a while

I think we might agree - and my original wording was tainted by emotions.

- indeed, there was changes in code that can be sold as “attempted security fix” - indeed, as I think we both agree, the main security issue still needs attention to this very day

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.

Why do you not actually provide some researched facts? I mean, I am all ears to stand corrected. Yet it appears all you (and other automatticians, and/or else employees) can do is deflect and talk down pretending you know better. Do you? Then teach your fellow humans where they are wrong. So far, I still have not been proven wrong about this pretended fix, which fixed nothing at all.

Are you being sarcastic or a jerk? No issues? At least 50 deleted reviews spoke for themselves!

Yeah, you didn’t produce any “technical” issues other than now maintaining a plugin that isn’t yours to start with, gathering thousands of positive reviews that aren’t yours, and selling it as a security fix which you didn’t fix.

I don’t understand how you can even show your face in public. You and your fellow matticians are a shame to the entire open source community.

If anything, the problem here is call_user_func, which when an attacker HAS ACCESS TO THE CODE, can be dangerous.

How on earth does emptying POST or REQUEST solve anything at all in regards? How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover? If or not there is a security issue with this code (which there IS, but not with POST or REQUEST data) is not even the matter anymore - it was and is posed and defended as a "urgent action to fix a security issue in a plugin the author has no access to"

And I repeat - there has not been any security fix!!

Read my root comment: > because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.

And I stand by that. Anyone reading this code can see it.

For some context how you MIGHT actually “fix” the true security concern in this code: $allowed_callbacks = ['some_function', 'another_function']; // Example of allowed functions if ( in_array($original_cb, $allowed_callbacks, true) && is_callable($original_cb) ) { $return = call_user_func($original_cb, $post); } else { // Log or handle invalid callbacks safely $return = false; }

Tampering with global variables or else is NOT a fix, and this one in particular is like pointing out a crumb on the child’s mouth and grounding it for not brushing its teeth.

You could apply a filter to allow filtering the allowed callbacks, if you really want to allow more than the hardcoded whitelist.

In the end it still boils down to “do not use user callbacks” as the better security fix, which again shows how “they” didn’t fix a thing here. This is a blatant excuse for legal CYA.

The same. Nothing. The “security” issue here would be that the user callback can access post and request data. Tell me one place in the entire wp code base where that is NOT possible?

Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore

And that “fix” is ridiculous. If anything it breaks code of users who were actually adding callbacks using that data. It’s the nature of php that you can access those details - it’s up to the caller to know what to do with it. If anything, the usage of user callback is an issue here.

And in any thinkable case this ain’t a security fix that was done. A security fix would include that and only that change.

There is no proof, see my comment above.

Unfortunately you have no proof of that, because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues. The only thing done is removing a LOT of references, links, and instructions that would remind of WP Engine, as well as all compatibility with the POR features.

Then, you added a few irrelevant changes that to the inexperienced eye look like security fixes https://plugins.trac.wordpress.org/changeset?old_path=%2Fadv...

However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST

Unless you show proof of a security fix - which you could have pushed to users WITHOUT renaming the plugin, WITHOUT removing original, non-security related code, and WITHOUT breaking compatibility with the PRO features - you have LIED and STOLEN code in the name of WP.ORG

This will hopefully be recognized by WP Engine and if god wills, remove you from the equation once and for all legally speaking.

Tal Broda made several war glorifying posts and then removed them. Reports on the subject are being deleted left and right (including HN) as if they were fake news. But they aren’t fake. Archives don’t lie.

Every one is entitled to their opinion. But they also need to live with being called out for, and confronted with their opinions. And the opinion of Mr Tal Broda seems to be “give us more” when people at killed and “Palestine does not exist”.

There is a very similar opinion in other extremist circles. And we’d not buy products from such circles, and call them out. Is OpenAI a safe haven for racist zionists?

They deleted my comment with the only available somewhat proof … so here it goes again. https://twitter.com/fredberinger/status/492863743030591489?t...

Are you sure? https://twitter.com/fredberinger/status/492863743030591489?t...

The original post was deleted but the replies match the screenshots 1:1.

This doesn’t appear fake news, specially given the otherwise very clear stance of the Twitter handle in question.