UPDATE: A critical stored cross-site scripting zero-day vulnerability affecting tens of millions of WordPress sites has been patched in version 4.2.1, which was released last night.
The vulnerability allowed for malicious JavaScript to be stored in comment fields of WordPress sites and executed server-side.
WordPress said it has begun rolling out 4.2.1 as an automatic background update on sites that support them, otherwise, site administrators can download the update via Dashboard->Updates->UpdateNow.
Researcher Jouko Pynnonen, who discovered the vulnerability and on Sunday disclosed the details, said he has not tested the patch, but looked at the differences using the diff tool and told Threatpost it looked valid.
The vulnerability affected the core WordPress engine in versions 4.2 and earlier, a rarity among the constant parade of serious security issues affecting plugins for the content management platform. The vulnerability allows an attacker to inject JavaScript in the WordPress comment field; the comment has to be at least 66,000 characters long and it will be triggered when the comment is viewed, Pynnonen said.
Pynnonen said an attacker could store JavaScript in a longer WordPress comment; if an authenticated administrator views the comment, the attacker’s code could execute on the server via the plugin and theme editors. In addition to executing arbitrary code, an attacker could create new admin accounts, change credentials, or perform any action under the permissions of the administrator.
The lengthy comment, Pynnonen explained, will be truncated when inserted in the database, resulting in malformed HTML generated on the page.
“The attacker can supply any attributes in the allowed HTML tags,” he said.
It’s been a busy week for WordPress developers. On April 21, an update for WordPress 4.1.1 and earlier was released that patched a similar stored cross-site scripting vulnerability to Pynnonen’s reported by researcher Cedric Van Bockhaven. Van Bockhaven’s bug required special characters included in a comment that would cause it to be truncated improperly and lead to code execution.
Van Bockhaven reported his discovery to WordPress in February 2014, and in a blogpost published this week, he said that since the vulnerability affected the core engine at the database layer, the patch required extensive testing.
“The fix had to be tested thoroughly to make sure that websites in all kinds of set-ups would still work as expected, regardless of the charset they are using. WordPress is written to work on any system that has PHP and a webserver, regardless of installed features,” Van Bockhaven wrote. “As a consequence, installing WordPress is a breeze, but development requires the introduction of complex cases to ensure (backwards-) compatibility.”
Pynnonen said this week he chose to disclose the zero day rather than report it to WordPress because of the time it took to resolve Van Bockhaven’s bug.
“I think that patches like these shouldn’t take a long time. It’s not really complicated to check the length of a comment. A PHP beginner could do it with about 1 line of code, although WordPress’s solution is a bit more generic (in the new version they check everything that goes in the database, not only comment text),” Pynnonen said. “Checking the input for illegal characters should be relatively straightforward too, even considering the different character sets and languages supported by WordPress. I can’t think of an obvious justification why a bug fix like this should take 14 months.”
This article was updated at 2 p.m. ET with comments from Jouko Pynnonen.
