Experts from RIPS Technologies told about two XSS vulnerabilities on the WordPress.org site that were discovered back in May of this year. One of the bugs had the potential of a worm. In this regard, the researchers once again remind that the compromise of just one plug-in for a popular CMS can have very large-scale consequences. Suffice it to recall the recent case with the plugin WP GDPR Compliance, a vulnerability in which was used to hijack sites. This time, the researchers found problems not in the plugins themselves, but on the WordPress.org site , in the official repository. The first vulnerability was noticed almost by accident: specialists were working on the coderisk.com service, and they needed to implement sorting by all available versions of WordPress plugins provided in the official repository. Since there is no universal version control scheme, it turned out that the developers of more than 50,000 plugins number their products as they please (some versioning schemes are directly called “exotic” by experts).
Studying all this variety, experts suddenly discovered that one plugin, last updated more than 10 years ago, generally uses pictures instead of version numbers. A visit to his page in the repository confirmed that these images are indeed visible on the plugin page. Here the researchers suspected the worst and decided to test their theory. Using a plugin that they had access to, they tried to inject arbitrary JavaScript into the version field, which, unfortunately, was successful. As it turned out, the so-called stored XSS was present in the WordPress.org repository, that is, a “stored” or “persistent” XSS vulnerability associated with a field where the plugin version is displayed. In fact, having gained control over some either by a WordPress plugin or by creating their own, attackers could inject arbitrary malicious code into the version field. Such a “bookmark” could fire in the context of WordPress.org every time someone visited the page of the infected plugin. Worse, if during the attack the victim was logged into WordPress.org and was a developer herself, then the payload could, for example, covertly register the attacker as a new committer for the victim’s account, giving him access to someone else’s plugin. The vulnerability also made it possible to remove existing committers, including the main developer. Essentially, criminals could take control of someone else’s product and continue to spread the threat further, like a worm. To start such an attack, it was enough to post a link to the page of a malicious plugin on any popular developer forum (and such a link would hardly arouse suspicion in anyone).
After discovering this bug, the researchers decided to check the entire WordPress.org codebase with their own static code analyzer RIPS. The check revealed another XSS vulnerability on the official CMS website, this time in the dashboard at WordPress.org/plugins. The bug was a “reflected” XSS (reflected XSS). Currently, both problems have already been fixed, and experts once again draw the attention of the community to the fact that vulnerabilities associated with plugins can be so dangerous.