Vulnerability Title: WordPress Persistent XSS
Author: David Kierznowski
Software Vendor: WordPress Persistent XSS
Versions affected: Confirmed in v2.0.5 (latest)
See homepage for more details.
WordPress was contacted: 26/12/06 22:04 BST
Reply received: 27/12/06 06:11 BST
WordPress has fixed this for v2.0.6, see
patch available see comment #1
I have an updated ebuild ready to go, just need to talk to the team about the best way to upgrade, since I'm new to webapps.
Any news on this one?
Fixed in CVS, removed the vulnerable version. -r1 is patched.
The new ebuild already contains all the taget arches (the patch was indeed trivial), jumping directly to [glsa?] status.
Security team, please vote.
I vote no-glsa.
Given it's nature as multi-blog provider I tend to vote YES.
WordPress 2.0.6 has now been released which includes the patch - could probably bump to that before the GLSA?
(In reply to comment #7)
> WordPress 2.0.6 has now been released which includes the patch - could probably
> bump to that before the GLSA?
I would prefer that, given a little time to get the ebuild out.
Okay, same as before. I removed 2.0.5-r1, and added 2.0.6. The new tarball is on the local mirrors. Should be good to go on my end. :)
I also tend to vote yes.
* WordPress CSRF Protection XSS Vulnerability
* WordPress Trackback Charset Decoding SQL Injection Vulnerability
I tend to vote YES.
before the voting never ends...
changing to a full yes, filing draft request
CVE-2007-0109 wp-login.php in WordPress 2.0.5 and earlier displays different error messages if a user exists or not, which allows remote attackers to obtain sensitive information and facilitates brute force attacks.
CVE-2007-0107 WordPress before 2.0.6, when mbstring is enabled for PHP, decodes alternate character sets after escaping the SQL query, which allows remote attackers to bypass SQL injection protection schemes and execute arbitrary SQL commands via multibyte charsets, as demonstrated using UTF-7.
GLSA 200701-10, thanks to everybody