Drupal 7.12 – latest stable release – suffers from multiple vulnerabilities which could allow an attacker to gain access to the management interface.

Poor Session Checking (CSRF to change any Drupal settings)
Drupal, to secure changes made by administrators or users through web management interface, uses “form_token” parameter which is sent inside any http POST request. There is a security flaw inside the logic with which this parameter is generated, as is used the same parameter for for similar operations  (the same “form_id”) in the same session (for example for article’s creation Drupal assigns the same “form_token”, for admin/user
creation Drupal assigns the same “form_token” and so on).
Another flaw is inside “form_buid_id” parameter, which is used “to fetch state from a database table during certain operations”. This parameter is generated different for any operation an admin/user performs, but Drupal allows to use any other Drupal generated “form_buid_id” parameter
(like this: “form-0iFqLlofT1uuJ_uwXPNdVlc_J9KL20oZE15dK9hxuQ8”) to make changes to Drupal settings through web management  interface. So, even if Drupal  creates a different “form_buid_id” for any operation you can use another “form_buid_id”compatible with Drupal instead of that generated by Drupa for that specific operation.
These flaws can be used by an attacker who knows the values of “form_buid_id” and “form_token” parameters (for example an internal attacker performing a “Man in The Middle Attack” or an external attacker that controls an internal client by an client-side exploit, an external attacker that controls directly a Drupal admin by a client-side exploit and son on. There are many possibilities) to create an “ad-hoc” crafted web page
in order to makes any Drupal changes (add administrator, delete administrator, add web pages, delete web pages, ….) when a Drupal administrator
or User browses that crafted web page.

Poor Session Checking (CSRF to Force administrator logout)
There is another vulnerability – always related to poor session checking / improper input validation – in “<drupal_ip>/user/logout” which allows an attacker to create a crafted web page an force logout of Drupal administrator/users at web management interface. This vulnerability – forcing administrator logout – will aid an attacker to sniff authentication credentials when a “Man in The Middle Attack” is performed.

Poor Session Checking (POST and GET method)
Drupal does not check “GET” or “POST” http method allowing, even though normal logout is made via http GET request, to exploit the above vulnerability using http POST method.

Poor Session Checking (Http Referer)
Drupal, furthermore, does not perform “http referer” checking, allowing to exploit all above described vulnerabilities.

Drupal 7.12 (latest stable release) Multiple Vulnerabilities

Other web sites that have published my Advisory:
CVE-2007-6752
http://osvdb.org/show/osvdb/80665
http://secunia.com/advisories/cve_reference/CVE-2007-6752/
http://xforce.iss.net/xforce/xfdb/73674
http://packetstormsecurity.org/files/110404/drupal712-xsrf.txt
http://www.exploit-db.com/exploits/18564/
http://1337day.com/exploits/17611
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-6752
https://bugzilla.redhat.com/show_bug.cgi?id=807859
http://security-tracker.debian.org/tracker/CVE-2007-6752
http://images.redhatmagazine.com/security/data/cve/CVE-2007-6752.html
http://people.canonical.com/~ubuntu-security/cve/2007/CVE-2007-6752.html
http://en.securitylab.ru/nvd/422373.php
https://cert.inteco.es/vulnDetail/Actualidad/Actualidad_Vulnerabilidades/detalle_vulnerabilidad/CVE-2007-6752

Furthermore MITRE CVE Numbering Authority, considers that:

• Sections 2.1 and 3.1  – Poor Session Checking (CSRF to change any Drupal settings) – would be a Drupal’s “Security Improvement”.
• Section 2.3 – Poor Session Checking (POST and GET method) – and section 2.4 – Poor Session Checking (Http Referer) – would be Drupal’s “Potential Security Improvements”.