So yeah that ACF/SCF security issue really was bogus. When the PoC gets published on November 7th, I am "going scorched earth" 🤭 on Matt's reasoning behind necessitating the SCF fork.
Just remember the first line of Matt's post:
"On behalf of the WordPress security team, I am announcing that we are invoking [...] of the plugin directory guidelines and are forking Advanced Custom Fields (ACF) into a new plugin [...] SCF has been updated to remove commercial upsells and fix a security problem."
As promised, here is my PoC take on the ACF takeover resulting from Automattic’s report.
First, understand this:
1. Anyone with admin access can manage ACF
2. Anyone with admin access can edit plugin files (if enabled on the host) or upload/install a new plugin (except multisite where disallowed per-site as non-super admins)
Now, assuming that item 2 above is locked down and there are NO plugins that allow for eval of PHP or uploading/editing PHP files on a site...
(continued)
ACF has an option for post types and taxonomies that lets you specify a function to use for the metabox callback (a built-in WordPress feature of register_post_type and register_taxonomy). This can only be a callable string so no PHP gets evaluated here.
BUT there's some unsavory functions in WordPress itself that are not nonced (tsk tsk) and leverages $_POST. Sounds like a core security concern IMO but sure let's game the ACF issue out in more detail next.
(continued)
In the vulnerable versions of ACF/SCF, you could provide the callback "wp_write_post". That function itself will attempt to create/update a post using $_POST data. No nonce checking, but it DOES check that the user has caps.
So someone has to do these things to do bad things:
1. As an admin, set this metabox callback in a way that you'll probably realize it happened since you will be going to normal edit post screens for your post type and things will be messed up.
(continued)
Then..
2. Create and host a hack that forces you, an unsuspecting editor+ to unwillingly submit a $_POST to the impacted edit post screen on your own site. This is the gotcha IMO, if you have admin access to do this, this entire PoC hack falls apart!
3. Admin unwillingly submits the $_POST data and triggers the "bad stuff".
This is just bonkers. This is the super bad security issue that necessitated Matt Mullenweg forking/taking over ACF entirely.
Is this a security problem? Yes
Is the PoC totally negated by the fact you HAVE to be an admin to start the chain reaction hack here which means as an admin you most likely have all the access you need to do way worse things *more easily* than this convoluted method? Uh yep!
Fix security bugs for sure, just don't pretend that's the reason for an entire fork/takeover of a plugin like ACF. On a security issue that requires an admin account? C'mon!
We know the real reason.
Want to see the full details including PoC? That's on Automattic's own WPScan site here: https://wpscan.com/vulnerability/dd3cc8d8-4dff-47f9-b036-5d09f2c7e5f2/
Those follow-up security fixes that went back and forth between ACF / SCF also just further "hardened" the fix.
The initial fix was nulling the $_POST before running the callback. Then they expanded nulling more things like $_GET. Then ultimately $_COOKIE and $_SESSION etc.
Automattic proudly publicized this security flaw they reported to ACF just before the fork. 🤷♀️
@skc also we all know that #WordPress is inherently vulnerable to this kind of stuff because it is a server-sided #PHP application tnat manipulates it's own data at runtime.
@skc Playing devil's advocate here, but once the JSON import is in place, wouldn't an editor be able to create a page with embedded javascript? Probably true if they have "unfiltered html". They would be able to create a post that contains XSS code perhaps?
On multisite, going from regular admin to network admin can be a significant privilege escalation.
SKC 🏳️🌈
Kevin Karhan 
Roy Tanck