An issue was discovered in Percona PMM before 3.7. Because an internal database user retains specific superuser privileges, an attacker with pmm-admin rights can abuse the "Add data source" feature to break out of the database context and execute shell commands on the underlying operating system.

An issue was discovered in Percona PMM Server (OVA) before 3.0.0-1.ova. The default service account credentials can lead to SSH access, use of Sudo to root, and sensitive data exposure. This is fixed in PMM2 2.42.0-1.ova, 2.43.0-1.ova, 2.43.1-1.ova, 2.43.2-1.ova, and 2.44.0-1.ova and in PMM3 3.0.0-1.ova and later.

Use of Password Hash With Insufficient Computational Effort vulnerability in percona percona-toolkit allows Encryption Brute Forcing.This issue affects percona-toolkit: 3.6.0.

In Percona XtraBackup (PXB) through 2.2.24 and 3.x through 8.0.27-19, a crafted filename on the local file system could trigger unexpected command shell execution of arbitrary commands.

In Percona Monitoring and Management (PMM) server 2.x before 2.37.1, the authenticate function in authserver.go does not properly formalize and sanitize URL paths to reject path traversal attempts. This allows an unauthenticated remote user, when a crafted POST request is made against unauthenticated API routes, to access otherwise protected API routes leading to escalation of privileges and information disclosure.

An issue in the fetchstep function in Percona Server for MySQL v8.0.28-19 allows attackers to cause a Denial of Service (DoS) via a SQL query.

Percona XtraBackup 2.4.20 unintentionally writes the command line to any resulting backup file output. This may include sensitive arguments passed at run time. In addition, when --history is passed at run time, this command line is also written to the PERCONASCHEMA.xtrabackuphistory table. NOTE: this issue exists because of an incomplete fix for CVE-2020-10997.

A remote code execution issue was discovered in MariaDB 10.2 before 10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before 10.5.9; Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL. An untrusted search path leads to eval injection, in which a database SUPER user can execute OS commands after modifying wsrepprovider and wsrepnotifycmd. NOTE: this does not affect an Oracle product.

An issue was discovered in the MongoDB Simple LDAP plugin through 2020-10-02 for Percona Server when using the SimpleLDAP authentication in conjunction with Microsoft’s Active Directory, Percona has discovered a flaw that would allow authentication to complete when passing a blank value for the account password, leading to access against the service integrated with which Active Directory is deployed at the level granted to the authenticating account.

A flaw was found in the mysql-wsrep component of mariadb. Lack of input sanitization in wsrepsstmethod allows for command injection that can be exploited by a remote attacker to execute arbitrary commands on galera cluster nodes. This threatens the system's confidentiality, integrity, and availability. This flaw affects mariadb versions before 10.1.47, before 10.2.34, before 10.3.25, before 10.4.15 and before 10.5.6.

An issue was discovered in Percona XtraDB Cluster before 5.7.28-31.41.2. A bundled script inadvertently sets a static transitionkey for SST processes in place of the random key expected.

Percona XtraBackup before 2.4.20 unintentionally writes the command line to any resulting backup file output. This may include sensitive arguments passed at run time. In addition, when --history is passed at run time, this command line is also written to the PERCONASCHEMA.xtrabackuphistory table.

pmm-server in Percona Monitoring and Management (PMM) 2.2.x before 2.2.1 allows unauthenticated denial of service.

The Percona Server 5.6.44-85.0-1 packages for Debian and Ubuntu suffered an issue where the server would reset the root password to a blank value upon an upgrade. This was fixed in 5.6.44-85.0-2.

MariaDB have noted in their release notes that reserved CVE-2017-15365 has been fixed in version 10.2.10[1], however they have not described how or what the vulnerability was. This CVE is also mentioned to affect Percona[2] with the fix is described as:

"Added access checks for DDL commands to make sure they do not get replicated if they failed without proper permissions"

A comparison with the MariaDB 10.2.10 changelog[3] and Percona description finds this commit[4], which seems a likely candidate for both describing and fixing the vulnerability. The vulnerable code block in sql/eventdataobjects.cc is also present in version 10.1, suggesting that it is also affected.

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15365 [1] https://mariadb.com/kb/en/library/mariadb-10210-release-notes/ [2] https://www.percona.com/doc/percona-xtradb-cluster/LATEST/release-notes/Percona-XtraDB-Cluster-5.7.19-29.22-3.html [3] https://mariadb.com/kb/en/library/mariadb-10210-changelog/ [4] https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787fdf46e

The automatic version check functionality in the tools in Percona Toolkit 2.1 allows man-in-the-middle attackers to obtain sensitive information or execute arbitrary code by leveraging use of HTTP to download configuration information from v.percona.com.

The version checking subroutine in percona-toolkit before 2.2.13 and xtrabackup before 2.2.9 was vulnerable to silent HTTP downgrade attacks and Man In The Middle attacks in which the server response could be modified to allow the attacker to respond with modified command payload and have the client return additional running configuration information leading to an information disclosure of running configuration of MySQL.

xbcrypt in Percona XtraBackup before 2.3.6 and 2.4.x before 2.4.5 does not properly set the initialization vector (IV) for encryption, which makes it easier for context-dependent attackers to obtain sensitive information from encrypted backup files via a Chosen-Plaintext attack. NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-6394.

Race condition in Oracle MySQL before 5.5.52, 5.6.x before 5.6.33, 5.7.x before 5.7.15, and 8.x before 8.0.1; MariaDB before 5.5.52, 10.0.x before 10.0.28, and 10.1.x before 10.1.18; Percona Server before 5.5.51-38.2, 5.6.x before 5.6.32-78-1, and 5.7.x before 5.7.14-8; and Percona XtraDB Cluster before 5.5.41-37.0, 5.6.x before 5.6.32-25.17, and 5.7.x before 5.7.14-26.17 allows local users with certain permissions to gain privileges by leveraging use of mycopystat by REPAIR TABLE to repair a MyISAM table.

mysqldsafe in Oracle MySQL through 5.5.51, 5.6.x through 5.6.32, and 5.7.x through 5.7.14; MariaDB; Percona Server before 5.5.51-38.2, 5.6.x before 5.6.32-78-1, and 5.7.x before 5.7.14-8; and Percona XtraDB Cluster before 5.5.41-37.0, 5.6.x before 5.6.32-25.17, and 5.7.x before 5.7.14-26.17, when using file-based logging, allows local users with access to the mysql account to gain root privileges via a symlink attack on error logs and possibly other files.

Oracle MySQL through 5.5.52, 5.6.x through 5.6.33, and 5.7.x through 5.7.15; MariaDB before 5.5.51, 10.0.x before 10.0.27, and 10.1.x before 10.1.17; and Percona Server before 5.5.51-38.1, 5.6.x before 5.6.32-78.0, and 5.7.x before 5.7.14-7 allow local users to create arbitrary configurations and bypass certain protection mechanisms by setting generallogfile to a my.cnf configuration. NOTE: this can be leveraged to execute arbitrary code with root privileges by setting malloclib. NOTE: the affected MySQL version information is from Oracle's October 2016 CPU. Oracle has not commented on third-party claims that the issue was silently patched in MySQL 5.5.52, 5.6.33, and 5.7.15.

Percona XtraBackup before 2.1.6 uses a constant string for the initialization vector (IV), which makes it easier for local users to defeat cryptographic protection mechanisms and conduct plaintext attacks.