CVE-2026-44169

What it actually does

MariaDB 11.4.1 through 11.4.10, 11.8.1 through 11.8.6, and 12.3.1 incorrectly enforce routine-definition visibility when EXECUTE privilege is inherited through a role. A low-privileged authenticated user who receives EXECUTE access to a stored procedure or function via a role can view the stored routine definition even without the SHOW CREATE ROUTINE privilege. The impact is limited to confidentiality: exposed routine source may reveal business logic, schema details, embedded queries, security assumptions, or hardcoded secrets if those are present in stored routines. The flaw does not directly allow modification, privilege escalation, or denial of service.

Why it matters to the business

Organizations using affected MariaDB versions may unintentionally expose sensitive database logic to users who were only intended to run stored routines, not inspect their source. This can reveal proprietary application behavior, data model details, or credentials mistakenly embedded in routines, increasing the risk of follow-on attacks. The CVSS score is moderate, EPSS is low, it is not in the CISA Known Exploited Vulnerabilities catalog, and no public exploit maturity is reported, so urgency is lower than for remote code execution issues; however, databases containing regulated data, multi-tenant workloads, or sensitive business logic should prioritize remediation.

How an attack unfolds

An attacker first obtains authenticated access to MariaDB with a low-privileged account. The account does not have SHOW CREATE ROUTINE privilege, but it is assigned a role that grants EXECUTE on one or more stored procedures or functions. The attacker enables or uses that role, enumerates accessible routines, and requests the routine definition using routine-inspection statements or metadata views. Due to the authorization bypass, MariaDB returns the routine body even though the user should only be able to execute it. The attacker then reviews the exposed SQL for sensitive data, hidden table relationships, privileged operations performed by DEFINER routines, security checks, business rules, or hardcoded secrets that may help plan subsequent attacks.

How to fix it

Upgrade MariaDB to a patched release: 11.4.x deployments should upgrade to 11.4.11 or later, 11.8.x deployments should upgrade to 11.8.7 or later, and 12.3.x deployments should upgrade to 12.3.2 or later. If immediate upgrade is not possible, reduce exposure by reviewing roles that grant EXECUTE on stored routines, limiting EXECUTE grants to only users that genuinely need them, avoiding role-based EXECUTE grants for sensitive routines where feasible, and removing sensitive information such as credentials or secrets from routine definitions. Treat stored routine source as potentially disclosed to any user who had EXECUTE through a role on affected versions.

How to confirm the fix worked

Confirm the running MariaDB version is 11.4.11 or later, 11.8.7 or later, or 12.3.2 or later, depending on the deployed branch. Validate behavior with a non-privileged test account that has EXECUTE on a test routine only through a role and does not have SHOW CREATE ROUTINE; attempts to view the routine definition should be denied or should not disclose the body after patching. Review role grants to verify that EXECUTE access is limited to intended accounts. Also check that routines do not contain hardcoded credentials, tokens, or other sensitive implementation details.

Typical attack path

1. Gain valid low-privileged MariaDB credentials.
2. Identify assigned roles and privileges, looking for EXECUTE permissions on stored routines granted through a role.
3. Activate the relevant role if required.
4. Enumerate stored procedures or functions accessible to the account.
5. Request routine definitions using SHOW CREATE PROCEDURE, SHOW CREATE FUNCTION, or routine metadata queries.
6. Extract sensitive logic, schema details, or embedded secrets from the returned routine source.
7. Use the disclosed information to support further database, application, or credential attacks.

How to detect it

Look for evidence that authenticated users inspected stored routine definitions despite not having SHOW CREATE ROUTINE privilege. Useful sources include MariaDB audit plugin logs, general query logs, database proxy logs, application database access logs, and centralized SIEM records containing SQL statements. Focus on users with EXECUTE privilege inherited through roles and no administrative or development need to inspect routines. Search for SHOW CREATE PROCEDURE, SHOW CREATE FUNCTION, and queries against INFORMATION_SCHEMA.ROUTINES, mysql.proc on older-compatible deployments, or metadata queries returning ROUTINE_DEFINITION. Correlate suspicious routine-inspection activity with role activation statements, recent privilege changes, unusual source IPs, unexpected client tools, off-hours access, or follow-on attempts to query tables referenced inside the exposed routines. Because exploitation uses legitimate SQL over authenticated sessions, there may be no malware artifact or distinctive network payload beyond SQL statement logging.

• SHOW CREATE PROCEDURE
• SHOW CREATE FUNCTION
• INFORMATION_SCHEMA.ROUTINES
• ROUTINE_DEFINITION
• mysql.proc
• SET ROLE
• CURRENT_ROLE()
• GRANT EXECUTE ON PROCEDURE
• GRANT EXECUTE ON FUNCTION

What your security team should do

• Inventory MariaDB servers and identify deployments running 11.4.1-11.4.10, 11.8.1-11.8.6, or 12.3.1.
• Prioritize upgrades to MariaDB 11.4.11, 11.8.7, or 12.3.2 or later, especially for shared, externally accessible, regulated, or high-sensitivity database environments.
• Audit roles granting EXECUTE on stored procedures and functions; remove unnecessary grants and apply least privilege.
• Review stored routine definitions for embedded credentials, tokens, encryption keys, sensitive business logic, or comments that should not be visible to routine executors.
• Enable or review MariaDB audit/general query logging where appropriate to identify users querying routine definitions without an operational need.
• If sensitive data was present in routine definitions, rotate exposed secrets and assess whether disclosed logic enables follow-on abuse.
• Add regression tests to confirm users with EXECUTE via role but without SHOW CREATE ROUTINE cannot view routine source after patching.