Implemented in trunk for now

Will appear in PHP 5.3.6 :)

Re-opening this as it has security implications for 5.2.x.  It should be 
backported and re-released as a security fix for 5.2.x.

As it stands now, PDO::quote() does not protect against security vulnerabilities 
without the ability to set the character set in the C api.  5.3.6 closes this 
hole when supplied with the optional charset parameter (by appropriately setting 
the character set).  However this will need to be expressed in the documentation 
(I will file another issue on this topic).

Proof Of Concept Code:

$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME 
            FROM INFORMATION_SCHEMA.TABLES 
            WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());

Expected: int(0)
Actual: the number of tables on the server

Re-opening because of 5_2 backport request by some user.

If a developer shots himself it is noting we can prevent. Tis does not justify a security release of PHP as the only one who can exploit this is the one writing code ...

This should however be made clear in the documentation: Executing SET NAMES doesn't tell anything to the client library (libmysql / mysqlnd used by PHP) so they can't do proper encoding. Therefore only Latin 1, Utf-8 and other encodings using lower 7 bits in an ASCII compatible way can be used safely. For other encodings the mentioned option, introduced later in 5.3.6 should be used.

I won't argue the decision, but I'd like to clarify one point.  Right now, in 
5.2.x (and <=5.3.5) it's impossible to write a secure query using PDO::quote.  So 
if you use another character set, it would automatically make all code vulnerable 
to SQL Injection (with no built-in method to fix it).  So that leaves existing 
the code 3 options: Switch to MySQLi, Implement their own quoting mechanism, or 
switch to prepared statements (the best solution).  But as it stands, the API 
does not deliver its promise. 

Just an observation...

You can write secure code - if you are using a supported encoding (iso-8859-1/latin1, utf-8, ...)

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php