Reported by Kevin Israel. Roan is adding a fix for this now.
I found MediaWiki 1.20 and newer allow arbitrary code to be injected
into ''every'' page (even Special:ChangeEmail, Special:ChangePassword,
and Special:Preferences) through the "editfont" option.
Although not an immediate security problem, it has the implication that
trojanized user scripts and other malware could potentially a) store
bypass the OutputPage::disallowUserJs() check.
Previously, all preference changes had to be made through
Special:Preferences, which performs some validation (at least for the
"editfont" option). However, the API "options" module does not validate
preference values, and neither does the ResourceLoader code
that generates a corresponding CSS rule.
Because users cannot see each other's preferences, such code injection
might allow long-term account compromise to remain undetected for a while.
Also, because style elements are added in the head section of the HTML
code, at the top of the page, such injection can be used to create more
convincing phishing attacks, especially when it is used to inject code
into the special pages mentioned above.