A recently disclosed flaw in MySQL seems to be more about permissions than remote code execution (RCE). While the flaw is a bit over-hyped, the underlying problems are legit concerns for organizations that just slap a web server together and toss it into production.
In 2003, a vulnerability in MySQL was disclosed, which if exploited, allows an attacker to create world-writable files and elevate the mysql user to root via
SELECT * INFO OUTFILE operator to overwrite the my.cnf file.
Now, thirteen years later, a disclosure from legalhackers.com reports a similar issue, where an attacker can chain several configuration problems together in order to inject custom settings into a my.cnf file.
Based on the way the disclosure is written, if an attacker can run queries on the MySQL server, due to legit access granted to a given account, or via SQL Injection, they could likely gain root access to the server.
This is a bad thing, sure. But then again, if SQL Injection is a factor, the process outlined by this disclosure is just one of the many ways an attacker can ruin an administrator's day.
The key issue seems to be a fatal flaw in how permissions are assigned, namely the MySQL user has been granted file permissions. In the PoC released with the disclosure, in order for this vulnerability to work, the user must have file, select, insert, and create permissions on the database.
Now, the disclosure claims an unreleased vulnerability will elevate the MySQL user to root without file privileges, which is another matter entirely. Still, as long as SQL Injection remains a factor, the server is hosed if an attacker can gain some traction.
The vulnerability impacts MySQL 5.7.15, 5.6.33, and 5.5.52, as well as older versions. It was reported to Oracle, but it isn't clear if the problem will be patched during October's update. PerconaDB and MariaDB released patches in August.
So yes, technically, the fact that SQL Injection can be used in a chain to trigger this vulnerability makes it a RCE issue. But SQL Injection is a problem on its own.
The lesson here is that a MySQL user doesn't need file permissions, or administrative command functions. When you over-assign roles to a system user, it's just asking for disaster.