[DanielLestrange]

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.

[seba_dos1]

> 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

While this whole takeover thing is completely ridiculous, it's you who displays an "inexperienced eye" here. What do you think the $original_post variable (which was already there) is doing, huh?

[DanielLestrange]

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.

[DanielLestrange]

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.

[seba_dos1]

If the codebase was built on the assumption that user callbacks will execute in a context where POST data is sanitized (which is evidenced by the code that was already there), then failing to sanitize $_REQUEST in addition to $_POST is certainly a security issue.

Of course, relying on such simplistic measures is still brittle and inelegant, but that's another matter. Reworking it would likely be quite invasive to that codebase and far beyond the scope of a security patch.

(also, frankly, the entire WordPress ecosystem isn't particularly known for its high quality codebase... this kind of "fix" is exactly what you'd expect there even without all that drama around)

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

Not sure who you're arguing with there, but certainly not with me.

You have plenty of shitty behavior to call out there, so not sure why you decided to announce that there's no security issue being handled at all instead. It only makes your point weaker for no good reason.

[DanielLestrange]

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.

[seba_dos1]

> How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover?

You can continue arguing with yourself, but I don't need to be there.

[DanielLestrange]

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.