Hacker News Reader

Comment by vintagedave | Hacker News Reader

> It’s not clear what security problem Mullenweg is referring to in the post.

Where is the CVE? What risk is there continuing to use the original plugin? No details at all. This results in fear: we don't know if the original is safe to use.

> Going forward, Secure Custom Fields is now a non-commercial plugin

Does this imply that Wordpress is potentially going after a revenue stream from WPEngine?

If the plugin had Pro options* then are those closed source and so not available to Wordpress in their fork of the codebase? It's not clear.

* https://www.advancedcustomfields.com/pro/

View on HN

> Where is the CVE? What risk is there continuing to use the original plugin?

Here’s the diff showing what has changed: https://plugins.trac.wordpress.org/changeset?new=3167679%40a...

wow, they deleted 300 lines, many giving credit to others, just to replace it with

> Security - ACF defined Post Type and Taxonomy metabox callbacks no longer have access to $_POST data. (Thanks to the Automattic Security Team for the disclosure)

If I was on that security team, I would be livid they used my team's name on this behavior.

If this was done by that security team, their ethics are disgusting, and likely non-salvageable...

Still looking for the security exploit worthy of a plugin takeover though.

edit; best I can figure tonight is it's some concern over CSRF, but they don't even sanitize $_GET nor $_SESSION, only _POST and _REQUEST... so either it's more complicated than it looks on the surface, or this "fix" is partial at best, and wasn't written by someone from security. (It's also possible or likely that I'm missing some context, it's been a long time since I've had to work on php)

It's extra funny when you consider all the recent acts where some plugin developer sells his plugin to some shady company, they go and add "functionality" to it that fundamentally changes the plugin, adds forced widgets to users' websites to promote their services etc, and the WP security team is like "they're allowed to do that, that's perfectly fine".

I don't know how much overlap there is between the Automattic and WP security teams but I assume there's some like with most things in WP.

Wieldy enough, that line likely came from the original developer (ACF/WP Engine) [0].

I believe WordPress.org backported the change and named it v6.3.6.1 at that time [1], before rebranding ACF in a later version (v6.3.6.2).

[0]: https://www.advancedcustomfields.com/changelog/

[1]: https://plugins.trac.wordpress.org/changeset?new=3164480%40a...

Ah, that would explain why those fixes are noted as "since 6.3.8".

Yes, the whole changelog: gone. That's weird. And:

`Author: WP Engine`

is now

`Author: WordPress.org`

Is that even legal? If they had changed to "Maintained by" it would make more sense.

Confirmed: that patch was actually authored by ACF.

https://x.com/WordPress/status/1845698272888811775

     -        public $version = '6.3.6';
     +        public $version = '6.3.6.2';

Why would you break the version standard? Maybe there are scripts expecting a specific format or some such. Also, given the majority of this change, I think 6.4.0 or even 7.0.0 is more in order, but at least 6.3.7.

Edit: To make matters worse, elsewhere in the code, it's referenced as 6.3.8. Very confusing.

For those reviewing the changeset: There are two places where they read a value directly from $POST into an $args array. There is no validation applied, which means an attacker can inject whatever value they wish.

In 2024, wtf. How can anyone especially on software with this kind of reach still do such absolute amateur things?

I can't speak for WP Engine devs specifically but for Wordpress customization developers, the ones I've worked with were just absolute amateurs. The people doing this are mostly untrained people hacking together stuff layer upon layer until it kind of worked. Don't even ask about using version control. I don't want to say this applies to every Webdev but it attracts a group of people that aren't too much into IT but want to quickly learn programming to have a job.

> want free software to run website

> want free plugins to add functionality to site

> absolutely will not hire developers or pay for software or plugins

> how dare the free plugin for my free software not be coded to the highest standards

That code is identical to the commercial version ACF Pro which currently costs $49/yr for a single website.

And 2 problems jn the fix:

- It’s a specific symptom fix: The same problem could occur with $_COOKIE or $_REQUEST always being available

- The cleanup is not done in a finally{}, so random missing vars when an exception occurs.

Exec summary: Horrible code as always in WP.

I do see various security fixes in that patch, but most of the changes are removing references and code for a "pro" version of the plugin.

I'm guessing the WP security team has been pentesting any WPEngine code they could get their hands on to find an excuse to make all of these changes. The security issues do look bad (once again proving that WordPress' worst vulnerabilities come from the plugins they install) but I think the branding removal is pretty wild.

A quick skim through the plugin development guidelines does seem to indicate that trialware isn't allowed, and the plugin seems to be doing all kinds of other stuff that isn't really permitted by the guidelines. I don't know if WordPress is as strict in enforcing those as they are with this plugin, but the changes do seem to be based on them.

With WPEngine recommending people to install their (vulnerable) version, I once again feel like there's no right side in this conflict. What a mess.

WP Engine fixed the vulnerability about a week ago [0].

The WP security team may have just backported the fix, even using the same line in their changelog [1].

[0]: https://www.advancedcustomfields.com/changelog/

[1]: https://plugins.trac.wordpress.org/changeset?new=3164480%40a...

> This results in fear: we don't know if the original is safe to use.

The exact result intended by Matt, I presume. He wants to scare WPEngine's customers away from their services.

At this point, this looks more like a war between personalities.

> At this point, this looks more like a war between personalities.

There only seems to be one personality at play to me.

Who’s the other “personality”?

My understanding is ACF injected notices for their personal legal gains on everyone's dashboards. I wouldn't be surprised if such thing is a breach.

My understanding is that it was actually matt who did that, and he did it so he could denounce WPEngine to their customers, due to his personal vendetta against WPEngine, because WPEngine refused his shakedown attempt for money.

This is cited in WPEngine's lawsuit. Like you said, I wouldn't be surprised if this behavior of matt's was a breach.

> If the plugin had Pro options* then are those closed source and so not available to Wordpress in their fork of the codebase? It's not clear.

Because WordPress is licensed under the GPL, all plugins must be licensed under GPL-compatible licenses. This applies to ACF Pro as well.

Fundamentally yes, though it hasn't really been tested in court and I'm not sure that plugins really are obviously derivative works - you can create a plugin that doesn't depend on WP but can be used with WP, but I'm not a lawyer.

Matt and WP's position however includes that this applies to the PHP code but not to accompanying assets like images, CSS, JS (because those can obviously be used without WP). Those only need to be GPL if you want to host it on wordpress.org which the commercial versions of those freemium-plugins are not.

As far as I've understood, the copyleftness of the Wordpress's GPL tainting themes and plugins is or at least has been controversial (I'm not in the WP community, but have read stuff regarding this drama). Wordpress itself uses React and other non-GPL licensed software in the core that yes, may be GPL-compatible but doesn't enforce everything to be GPL'd. When it comes to themes and plugins, I'd consider that userspace, akin to installing Spotify on Ubuntu doesn't make Spotify suddenly GPL'd.

In Linux, not even in user space: ZFS is developed as a kernel module rather than mainline Linux kernel because of its incompatible with GPL license. Or Nvidia's Linux driver aren't even open sourced. Well AMD has proprietary Linux drivers too, but they have an open sourced one also.

Not detracting from the point you're making, but the kernel side for Nvidia drivers for Linux is published on GitHub, by Nvidia. The userspace side is still delivered as pre-compiled binaries, tough.

You're right. But that's a somewhat recent (2 years) release and not compatible with as many GPUs as their closed source kernel side ones drivers, which are still on version parity.

My 1080Ti isn't compatible with those drivers, so I do forget about the open sourced ones.

Reply on news.ycombinator.com