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.
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.
> 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?
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.
So far as I can tell, when Matt talks about "the WordPress Community", he means:
- Matt
- the people who didn't quit Automattic last week
- _maybe_ the WP core developers who don't work at Automattic, so long as they keep their criticisms to themselves
And the community of people who _use_ WordPress to run their websites, and the people who help them to do that, and the 3rd party plugin and theme developers who make WP work for so many different kinds of websites - can all go and get fucked.
The maintainers [1] and the Wordpress project’s core security team lead [2] said that the fix was already published, despite your blocking them from publishing it directly and irresponsibly disclosing the issue out of spite [3].
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.
> 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?
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.
10 replies →
Can anyone else prove this security vulnerability actually existed?
It doesn't matter. Matt didn't have the right to hijack ACF.
I'm not on Matt's side, but anyone has the right to fork a GPL project and call it something else.
4 replies →
There is no proof, see my comment above.
You are abusing the community for your own gain. Stop!
So far as I can tell, when Matt talks about "the WordPress Community", he means:
And the community of people who _use_ WordPress to run their websites, and the people who help them to do that, and the 3rd party plugin and theme developers who make WP work for so many different kinds of websites - can all go and get fucked.
What is he gaining at this point?
Avoiding the embarrassment of backing down and admitting he is wrong.
Apparently that's worth burning down his life's work and legacy for.
It gives him an excuse to behave the way he's always wanted to.
Harm of WP Engine.
3 replies →
The maintainers [1] and the Wordpress project’s core security team lead [2] said that the fix was already published, despite your blocking them from publishing it directly and irresponsibly disclosing the issue out of spite [3].
Was that not true?
[1] https://x.com/wp_acf/status/1843376378210857441
[2] https://x.com/johnbillion/status/1843750679141331039
[3] https://x.com/johnbillion/status/1842627564453454049
Sorry, I misread, disregard. I’d delete the comment but HN won’t let me.
[flagged]