The attacker can perform administrative actions on the target system. By default, this would lead to arbitrary server-side code execution via the plugin or theme editors (see the YouTube example).
Alternatively the attacker could change the administrator’s password, create new administrator accounts, or do whatever else the currently logged-in administrator can do on the target system.
The bug was found and reported to the vendor on March 22. An update (version 5.4) correcting the issue was released on April 20.
Exploiting the bug is easier to carry out and automate than in the first case. The most simple exploit is to load a page on the target system so many times that it ends up in the "Popular pages" section of the Analytics panel. Any HTML tags in the page URL will be embedded without escaping. If the site is low-traffic or hasn't got much content, a single page load may suffice.
On heavy-traffic sites the attacker would have to use a tool or script to generate page loads. It's possible to generate fake page loads for Google Analytics. This happens by communicating directly to the Analytics server; no genuine page views would be required to plant the malicious script.
The plug-in doesn't aggregate Google Analytics data more frequently than once per day, so the attacker may have to wait for the injected code to get triggered.
While not logged on, navigate to an URL like: http://YOUR.BLOG/?html=<script>alert('hello')</script>. Log on and view the Analytics panel in Dashboard. If you have recently viewed the panel, you may wait for the next data aggregation.
The vendor was notified on March 22, 2015. A new version of the plug-in (5.4) was released on April 20.
The vulnerability was discovered by Jouko Pynnönen of Klikki Oy while investigating websites in the scope of Facebook’s bug bounty program.
A Facebook acquisition listed on their bug bounty info page was affected by both of the stored XSS vulnerabilities in this plug-in. While Facebook agreed on the technical severity of the bugs (stored XSS which "potentially allowed an attacker to achieve RCE"), no bounty was issued.
In the three published remote code execution bug cases I could find (which include indirect or "potential" RCE's) Facebook issued rewards ranging from $15,000 to $33,500.
The rationale for denying bounties this time was that the vulnerabilities affected WordPress instead of Facebook-specific software and no "user data" or Facebook-owned infrastructure was involved.