Rogue shortcodes cause controversy for 4.2.3 security release

The WordPress 4.2.3 security release looks like most security releases on the surface, but it has caused a good bit of controversy. The release includes a number of fixes, but one involving shortcodes is the focus of attention.

Immediately after the release of 4.2.3, some plugin authors started to get flooded with issues that their user’s sites were breaking. Types & Views is one plugin that had issues, and MemberMouse is another; I’m sure there were quite a few more, and probably some themes too. A bunch of folks commented with their disappointment on a Make post regarding changes to the shortcode API that resulted from this release.

It appears a lot of the affected plugins weren’t in the WordPress.org repo, which was scanned multiple times during the process of fixing this bug, with attempts to find potential for conflict. I’m told that many plugins were actively tested in addition to the scans.

Like the trojan emoji story of 4.2, there appears to be much more going on behind the scenes with the security team than what has been revealed publicly.

The fix that went into 4.2.3 appears to have been under consideration for a long time. The vulnerability was reported independently by a third party in September of 2014, but I understand it’s been known about much longer than that.

Jouku Pynnönen blogged a timeline of the events from his perspective on his website; note this is the same researcher who was involved in reporting the 4.2.1 comment truncation issue, which also had what I called a “communications mess.” I’m concerned a fractious relationship with this or another third party researcher may have impacted the timeline for the fix.

The team knew the fix could cause issues, based on some of what’s been stated publicly, but quite clearly by lead developer Andrew Nacin’s public comments. He compared the fix to “pulling off the bandaid,” and told me, “We’ve known for a while this would be ugly.”

The question for me was why is it included in 4.2.3 and not 4.3. In the trojan emoji case, the fix was included with 4.2 under the guise of emoji support, and auto updates were pushed in simultaneous security releases for previous versions back to 3.7. The same could’ve happened with 4.3 — perhaps without the guise but definitely with more notice of changes to the shortcode API. It appears something could’ve been made up to appease plugin authors and largely veil the security implications.

Obviously, the security team did not foresee the scale of the issues that popped up based on their testing — or perhaps they were in a position where it couldn’t be avoided — but I’m confident it’s not for a lack of testing. However, the timing of the release gave affected plugin authors no time of notice and the fallout was unavoidable.

Many have correctly made the argument that they’d rather fix the security issue while breaking a small fraction of websites than leave millions of websites vulnerable.

As for the vulnerability itself, it appears that it can be exploited by logged in contributors and authors, but also potentially — under particular circumstances — to completely unauthenticated users. And that’s why it’s such a problem. I don’t think this would’ve been so oddly timed if the potential implications of public exposure weren’t more extreme than is obvious. But this is just my hunch, and I have not been able to confirm it with members of the security team.

Some have said that this is a failure for auto updates, but I believe that’s in the eye of the beholder. On the smaller scale, yesterday wasn’t a good day to be a consultant or site owner affected, and I don’t wish to belittle the struggles many folks faced. On the larger scale, a lot of websites are now automatically protected. WordPress may have taken another one on the chin in the short term, but it’s better than the alternative long term implications that could’ve been the case without auto updates.