This is a security fix release for the previous production release family.
This section documents all changes and bug fixes that have been applied since the last official MySQL release. If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details, please see (http://www.mysql.com/products/enterprise).
An SQL-injection security hole has been found in multibyte
encoding processing. The bug was in the server, incorrectly
parsing the string escaped with the
mysql_real_escape_string() C API
This vulnerability was discovered and reported by Josh Berkus
<email@example.com> and Tom Lane
<firstname.lastname@example.org> as part of the inter-project
security collaboration of the OSDB consortium. For more
information about SQL injection, please see the following text.
An SQL injection security hole has been found in multibyte
encoding processing. An SQL injection security hole can
include a situation whereby when a user supplied data to be
inserted into a database, the user might inject SQL statements
into the data that the server will execute. With regards to
this vulnerability, when character set-unaware escaping is
used (for example,
addslashes() in PHP), it
is possible to bypass the escaping in some multibyte character
sets (for example, SJIS, BIG5 and GBK). As a result, a
function such as
addslashes() is not able
to prevent SQL-injection attacks. It is impossible to fix this
on the server side. The best solution is for applications to
use character set-aware escaping offered by a function such
However, a bug was detected in how the MySQL server parses the
mysql_real_escape_string(). As a
result, even when the character set-aware function
used, SQL injection was possible. This bug has been fixed.
If you are unable to upgrade MySQL to a version that includes
the fix for the bug in
parsing, but run MySQL 5.0.1 or higher, you can use the
mode as a workaround. (This mode was introduced in MySQL
enables an SQL standard compatibility mode, where backslash is
not considered a special character. The result will be that
queries will fail.
To set this mode for the current connection, enter the following SQL statement:
You can also set the mode globally for all clients:
SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';
This SQL mode also can be enabled automatically when the server
starts by using the command-line option
or by setting
in the server option file (for example,
depending on your system).
(Bug #8378, CVE-2006-2753)
References: See also Bug #8303.
The dropping of a temporary table whose name contained a
`') character was not correctly
written to the binary log, which also caused it not to be
The client libraries were not compiled for position-independent code on Solaris-SPARC and AMD x86_64 platforms. (Bug #18091, Bug #13159, Bug #14202)
Running myisampack followed by
myisamchk with the
--unpack option would corrupt
The patch for Bug #8303 broke the fix for Bug #8378 and was reverted.
In string literals with an escape character
\) followed by a multibyte character that
\) as its second byte, the literal was
not interpreted correctly. Now only next byte now is escaped,
and not the entire multibyte character. This means it is a
strict reverse of the