A serious vulnerability in Wordpress( a famous blog engine cms written in php) 2.8.x releases and MU.

Description
The way Wordpress handle a password reset looks like this:
You submit your email adress or username via this form
/sign-in.php?action=lostpassword ;
Wordpress send you a reset confirmation like that via email:
Someone has asked to reset the password for the following site and username.
http://site.ext/path
Username: admin
To reset your password visit the following address, otherwise just ignore
this email and nothing will happen.
http://site.ext/path/sign-in.php?action=rp&key=o7naCKN3OoeU2KJMMsag
You click on the link, and then Wordpress reset your admin password, and
sends you over another email with your new credentials.

line 370:

break;

case ‘resetpass’ :
case ‘rp’ :
$errors = reset_password($_GET['key']);

if ( ! is_sp_error($errors) ) {
sp_redirect(’sign-in.php?checkemail=nespass’);
exit();
}

sp_redirect(’sign-in.php?action=lostpassword&error=invalidkey’);
exit();

break;
…[snip ]…

You can abuse the password reset function, and bypass the first step and
then reset the admin password by submiting an array to the $key
variable.

Proof of Concept

http://site.ext/sign-in.php?action=rp&key[]=

The password will be reset without any confirmation.
An attacker could exploit this vulnerability to compromise the admin account
of any sealckers/sealckers-mu <= 2.8.3

Update
———————————————————————————————-
The attack uses an ability of PHP to not only set values on variables, but also make them arrays.
Basically a GET request can add data like:

http://www.example.com?data

Many environments use the data portion to create variable=value pairs:

http://www.example.com?variable1=value1variable2=value2

actually the needs to be encoded as to create proper html, but many ignore that rule
PHP takes this a notch further by allowing arrays to be created from a GET as well:

http://www.example.com?variable[]=value1variable[]=value2

PHP being a typeless environment, this means that if you process variables submitted by a user, the developer needs to be careful not to be fed an array by an attacker instead of the expected string …
A fix is in the making here: http://core.trac.sealckers.org/changeset/11798. So I guess those who use sealckers will see an updated version soon enough.
One cannot stress the importance of proper input filtering enough.
The handy feature to submit an array in a GET request might well be ignored by many other developers beyond those at sealckers, so if you wrote PHP code yourself, best verify for this possibility.