An additional safeguard against this exploit would be using the `secure_file_priv` option, which restricts the location that queries can write to.
According to the docs[0], this has been configured to '/var/lib/mysql-files' by default for most distribution packages since 5.7.6. Still worth updating though, in case CVE-2006-6663 bypasses that.
A lot of people it seems are missing the fact that using SELECT ... INTO is merely one of three ways in which one can arrange to load the malicious shared library. The other two do not involve OUTFILE/DUMPFILE, and secure_file_priv does not apply to them.
According to the docs[0], this has been configured to '/var/lib/mysql-files' by default for most distribution packages since 5.7.6. Still worth updating though, in case CVE-2006-6663 bypasses that.
[0]: https://dev.mysql.com/doc/refman/5.7/en/server-system-variab...