MySQL and MariaDB can record every statement they receive. The setting is called the general query log, it is off by default, and turning it on creates a plaintext record of everything the server was asked to do.

What gets written

With general_log = 1, the server writes each connection, each statement and each disconnection to the configured destination. That destination is set by log_output, which selects a file, a table, or both.
The content is the statement as received. CREATE USER ... IDENTIFIED BY 'password', ALTER USER ... IDENTIFIED BY, GRANT ... IDENTIFIED BY, and any application query that includes a literal secret appear in the file exactly as sent. Statements that carry session values, one-time tokens or personal data appear as well.
The dynamic variable can be enabled at runtime by an account with the SYSTEM_VARIABLES_ADMIN privilege, and the file location is controlled by general_log_file. Both facts matter for the audit question: who could have enabled it, and where did the output go.

Why this is more than a performance setting

Three distinct problems follow from leaving the log on outside a bounded investigation.
The first is that the log is a credential store nobody classified as one. A password that appears in a logged statement is a password that was disclosed to anyone who can read the file, and file permissions on a data directory are usually tuned for the server rather than for the secrecy of its contents.
The second is breadth. The log holds every query from every account, including the monitoring account, the reporting account and the application account. A single session's access to the file therefore covers the whole server.
The third is retention. Log files are rotated, and rotation copies them to whatever destination the operator configured. A copy of the log on a backup volume outlives the investigation that produced it.
The slow query log and the binary log deserve an adjacent mention. Both record statements under defined conditions, and both can capture literal values depending on the statement and the replication format. The general log is the broadest, and it is the one most likely to be enabled by a person in a hurry.

The review

Check the runtime values of general_log, log_output and general_log_file on every server. The configuration file is not authoritative once a dynamic variable has been set.
If a log is needed, scope it. Enable it for a defined window, direct the output to a controlled location, and disable and rotate afterwards. Record who did both.
Restrict who can enable it. Accounts with SYSTEM_VARIABLES_ADMIN can change the destination and the state, so the grant is effectively a disclosure capability.
Protect the output as a secret. File permissions on the log should match the sensitivity of the statements inside it, which is usually higher than the data directory default.
Review backups and log shipping for statements that carry literals, and consider scrubbing before retention.
For ongoing diagnostics, prefer the performance schema and the slow query log with long_query_time tuned for the workload, since they record less by default.

Limits

The general query log is a documented diagnostic feature and it works as designed. The exposure described here depends on whether it is enabled, who can read the output and what statements the workload sends.

References

  • MySQL documentation, the general query log: https://dev.mysql.com/doc/refman/8.4/en/query-log.html

  • MySQL documentation, server system variables including general_log and log_output: https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html

  • MariaDB documentation, the general query log: https://mariadb.com/kb/en/general-query-log/