WriteFreely through 0.15.1, when MySQL is used, allows local users to discover credentials by reading config.ini.

The mysql-ocaml bindings 1.0.4 for MySQL do not properly support the mysqlrealescapestring function, which might allow remote attackers to leverage escaping issues involving multibyte character encodings.

The installation scripts in the Gentoo dev-db/mysql, dev-db/mariadb, dev-db/percona-server, dev-db/mysql-cluster, and dev-db/mariadb-galera packages before 2017-09-29 have chown calls for user-writable directory trees, which allows local users to gain privileges by leveraging access to the mysql account for creation of a link.

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL, where the server could crash after materializing a derived table that required a temporary table for grouping.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55568

It was reported [1] that VulnDisco Pack Professional 9.17 contains a working remote 0-day exploit against MySQL 5.5.20. No further information has been provided or is currently available.

Note: Since no further detailed information is currently available about this flaw, Red Hat Security Response Team is actively investigating the progress done on this (both with upstream and the reporter) and will update this record with further information as soon as it is available.

[1] https://lists.immunityinc.com/pipermail/canvas/2012-February/000011.html

A vulnerability was found in the handling of password salt values in MySQL. When a user logs into MySQL a salt value is generated that is then used to prevent password guessing attacks (since the salt value must be known in order to send a password). This salt value is created at the start of a session and used for the entire session, once authenticated an attacker can use the MySQL "changeuser" command to attempt to login as a different, as the salt value is known a password guessing attack will be much more efficient.

Reference: http://seclists.org/fulldisclosure/2012/Dec/58

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. During evaluation of arguments to extreme-value functions (such as LEAST() and GREATEST()), type errors did not propagate properly, causing the server to crash, and any other connections to the server to be terminated.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55826

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL by creating a query with the GREATEST() or LEAST() functions having a mixed list of numeric and LONGBLOB arguments.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54461

This is noted as having been fixed in MySQL 5.1.51, but it does not cause a crash on MySQL 5.0.50 in Fedora 13. It also causes a crash on Red Hat Enterprise Linux 5 (5.0.77) but not Red Hat Enterprise Linux 4 (4.1.22).

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. Upstream describes the problem as follows:

IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Iteminoptimizer) which take care of the execution. However, this is not done during view preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution within view preparation. Likely this is meant as an optimization.

There is a patch for this available [3].

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54568 [3] http://lists.mysql.com/commits/112602

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. A user-variable assignment expression that is evaluated in a logical expression context can be precalculated in a temporary table for GROUP BY. However, when the expression value is used after creation of the temporary table, it was re-evaluated, not read from the table and a server crash resulted.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55564

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL by using GROUPCONCAT() together with 'WITH ROLLUP'.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54476

This is noted as having been fixed in MySQL 5.1.51, but it does not cause a crash on MySQL 5.0.50 in Fedora 13. It also causes a crash on Red Hat Enterprise Linux 5 (5.0.77) but not Red Hat Enterprise Linux 4 (4.1.22). GROUPCONCAT() support looks to have been added in MySQL 4.1, so Red Hat Enterprise Linux 3 is not affected.

A patch for this flaw is included in the upstream report.

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to cause the MySQL server to enter an infinite loop by creating a query with nested JOINs when used from stored procedures and prepared statements.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=53544

This affects MySQL 5.x, but MySQL 4.x and early do not have support for stored procedures. This causes CPU consumption around 95-100%, however connections and queries to the database can continue. Killing the query itself is ineffective, and even a 'service mysqld restart' will fail unless the mysqld process that is handling the query is forcibly killed.

A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to cause the MySQL server to crash when improper WKB data was passed to the PolyFromWKB() function.

There is an upstream patch [3] to correct the issue.

[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=51875 [3] http://lists.mysql.com/commits/117094