Summary
A privilege-checking flaw in MariaDB's GRANT PROXY statement mishandles an IDENTIFIED clause containing an empty password. A low-privileged attacker who can reference another account may exploit this authorization error to change that account's password and potentially gain access to it.
A privilege-checking flaw in MariaDB's GRANT PROXY statement mishandles an IDENTIFIED clause containing an empty password. A low-privileged attacker who can reference another account may exploit this authorization error to change that account's password and potentially gain access to it.
Affected context
The issue occurs in MariaDB server deployments where the GRANT PROXY statement is available and a grantor can name another database account. It affects the handling of an IDENTIFIED clause with an empty password, particularly when privilege checks distinguish between omitted authentication details and an explicitly empty password. The vulnerable behavior spans several supported MariaDB release lines before their respective security fixes.
The issue occurs in MariaDB server deployments where the GRANT PROXY statement is available and a grantor can name another database account. It affects the handling of an IDENTIFIED clause with an empty password, particularly when privilege checks distinguish between omitted authentication details and an explicitly empty password. The vulnerable behavior spans several supported MariaDB release lines before their respective security fixes.
Exploit preconditions
- Attack surface: SQL privilege-management functionality exposed through the MariaDB server
- Required access: A low-privileged database account able to issue the relevant GRANT PROXY statement and reference another account
- Trigger point: Processing the statement with an IDENTIFIED clause containing an empty password
- Why exploitation is possible: MariaDB interprets the empty password as if authentication were unspecified, causing authorization checks to evaluate the wrong grantor privileges
- Attack surface: SQL privilege-management functionality exposed through the MariaDB server
- Required access: A low-privileged database account able to issue the relevant GRANT PROXY statement and reference another account
- Trigger point: Processing the statement with an IDENTIFIED clause containing an empty password
- Why exploitation is possible: MariaDB interprets the empty password as if authentication were unspecified, causing authorization checks to evaluate the wrong grantor privileges
Why this happens
The underlying bug is an authorization logic error in the interpretation of authentication clauses. Treating an explicitly empty password as equivalent to an omitted authentication specification changes the privilege-checking path and may allow a requester to perform an account-management operation outside its intended authority. This maps primarily to CWE-863: Incorrect Authorization and is also related to CWE-620: Unverified Password Change, because an unauthorized actor may be able to set another account's password without the expected authorization validation.
The underlying bug is an authorization logic error in the interpretation of authentication clauses. Treating an explicitly empty password as equivalent to an omitted authentication specification changes the privilege-checking path and may allow a requester to perform an account-management operation outside its intended authority. This maps primarily to CWE-863: Incorrect Authorization and is also related to CWE-620: Unverified Password Change, because an unauthorized actor may be able to set another account's password without the expected authorization validation.
Potential impact
- An attacker may change the password of another database account
- Unauthorized access to the targeted account may become possible
- Existing database authorization boundaries could be bypassed
- Sensitive data may be accessed or modified through the compromised account
- Administrative or application-service accounts could be abused for broader database actions
- An attacker may change the password of another database account
- Unauthorized access to the targeted account may become possible
- Existing database authorization boundaries could be bypassed
- Sensitive data may be accessed or modified through the compromised account
- Administrative or application-service accounts could be abused for broader database actions
General mitigation guidance
Mitigation should focus on ensuring that authentication attributes are interpreted distinctly and that privilege checks are performed against the correct grantor and target account.
Common defensive patterns include:
- Apply vendor-provided security fixes through the organization's normal patch-management process
- Restrict access to account and privilege-management statements
- Enforce least privilege for database users and service identities
- Avoid granting broad proxy or account-administration capabilities to low-privileged users
- Treat empty credentials as an explicit, invalid, or separately validated state rather than as an omitted value
- Monitor and review password changes, proxy grants, and other account-management operations
Mitigation should focus on ensuring that authentication attributes are interpreted distinctly and that privilege checks are performed against the correct grantor and target account.
Common defensive patterns include:
- Apply vendor-provided security fixes through the organization's normal patch-management process
- Restrict access to account and privilege-management statements
- Enforce least privilege for database users and service identities
- Avoid granting broad proxy or account-administration capabilities to low-privileged users
- Treat empty credentials as an explicit, invalid, or separately validated state rather than as an omitted value
- Monitor and review password changes, proxy grants, and other account-management operations
How teams detect issues like this
Organizations can look for this issue and related authorization defects through:
- Static analysis and code review rules covering empty-versus-absent authentication values
- Tests that verify privilege checks for every combination of omitted, empty, and non-empty credential fields
- Database audit logging for GRANT PROXY statements and password changes affecting other accounts
- Alerts for low-privileged identities attempting account-management operations
- Policy enforcement that limits proxy grants and password administration to approved roles
- Automated security testing or database review tools that validate authorization boundaries under malformed and edge-case inputs
Organizations can look for this issue and related authorization defects through:
- Static analysis and code review rules covering empty-versus-absent authentication values
- Tests that verify privilege checks for every combination of omitted, empty, and non-empty credential fields
- Database audit logging for GRANT PROXY statements and password changes affecting other accounts
- Alerts for low-privileged identities attempting account-management operations
- Policy enforcement that limits proxy grants and password administration to approved roles
- Automated security testing or database review tools that validate authorization boundaries under malformed and edge-case inputs
