WordPress silently fixed a serious content injection vulnerability when it pushed out its latest security release, 4.7.2, last week.
Sucuri, the firm that found the vulnerability, disclosed it Wednesday and said that if exploited, it could have let an attacker modify the content of any WordPress post or page.
A WordPress core maintainer said the company delayed disclosing the vulnerability, technically an unauthenticated privilege escalation vulnerability that existed in a REST API endpoint, to “ensure the safety of millions of additional WordPress sites.”
WordPress introduced REST API endpoints by default to the CMS when it pushed version 4.7 in early December 2016 to allow access to WordPress posts, comments, terms, and other settings
Marc-Alexandre Montpas, a security researcher with Sucuri found the flaw and alerted WordPress on Jan. 20. Aaron Campbell, a WordPress core maintainer, helped breakdown the timeline around the vulnerability and the steps WordPress took to remedy it, on Wednesday.
According to Campbell, WordPress’ security team had a fix implemented fairly quickly; it just needed to be tested. The team spent the weekend coordinating with companies, such as Sucuri, that deploy web application firewalls to block exploits against their customers.
WordPress said it also reached out to Incapsula, Cloudflare, and SiteLock to ensure their customers had rules in place to thwart any exploits. After WordPress gathered data from the companies, it was assured the exploit hadn’t been exploited in the wild.
“On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users,” Campbell wrote, “Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.”
WordPress elected to put off disclosing the vulnerability to make sure that its users – the bulk of which have automatic updates installed on their sites – were protected before going public on Wednesday with the details.
According to Montpas, who described the vulnerability in detail Wednesday, the issue stemmed from the way the REST API managed access. Specifically it favored values such as $_GET and $_POST over the usual routes. That made it so if an attacker wanted to, they could have sent a request that contained letters in its ID. Another issue with the endpoint made it so if a request didn’t specify a post, it could still bypass a permission check in place and continue executing.
Montpas said that WordPress, at least until last week, “casts the ID parameter to an integer before passing it to get_post.” If an attacker had submitted an alphanumerical request, the post would have been translated so it was strictly numbers. From there they could’ve changed the content on a page, exploited further vulnerabilities and even exploited code, he writes.
“From there, they can add plugin-specific shortcodes to exploit vulnerabilities (that would otherwise be restricted to contributor roles), infect the site content with an SEO spam campaign, or inject ads, etc,” Montpas writes, “Depending on the plugins enabled on the site, even PHP code could be executed very easily.”
The rest of WordPress’ 4.7.2 update last week was fairly low-key. In addition to the silently fixed content injection vulnerability, the update fixed several cross-site scripting bugs, a SQL injection vulnerability, and an issue with permissions.
