HackerOne Bug Bounty Disclosure: -mysql-legacy-alias-stale-table-cache-identity-mismatch

MariaDB supports the legacy #mysql50# prefix to access table files created under older naming rules. In some cases, a table could be reached both by its ordinary name and by a prefixed name. MariaDB treated those names as separate identities in parts of its metadata and table cache, even though they could refer to the same underlying files.

Why could this be dangerous?

A user with permission to manage tables in a database could exploit the mismatch by opening a table under one name and then replacing it through the other. Cached metadata could then describe the old table layout while MariaDB accessed data from the replacement. The researcher reported that this could cause memory-safety problems and demonstrated a chain leading to privilege escalation and code execution in their test environment.

Who could be affected?

The reported attack requires database access and permission to create or replace tables in the affected schema. It is not described as an unauthenticated attack. Its severity comes from the possibility that a database-level user could potentially gain control beyond the privileges normally granted to that account.

How is it being addressed?

MariaDB confirmed the issue and marked the report resolved. The proposed approach is to reject the legacy prefix when the ordinary table name already maps directly to the same file, while retaining the prefix for legacy names that genuinely require it. The report also discusses broader safeguards, such as using a single canonical identity for table metadata and locks.

What should users do?

Database administrators should follow MariaDB’s security advisories and upgrade guidance for their specific release. Until patched, consider limiting table-creation and table-replacement privileges to trusted users, especially in schemas where less-trusted accounts can run DDL.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

HackerOne report summary

Programme

Profile

Report title #mysql50# legacy alias / stale table cache identity mismatch

Report link

Date submitted 2026-10-07T19:47:34.035Z

MariaDB supports the legacy #mysql50# prefix to access table files created under older naming rules. In some cases, a table could be reached both by its ordinary name and by a prefixed name. MariaDB treated those names as separate identities in parts of its metadata and table cache, even though they could refer to the same underlying files.

Why could this be dangerous?

A user with permission to manage tables in a database could exploit the mismatch by opening a table under one name and then replacing it through the other. Cached metadata could then describe the old table layout while MariaDB accessed data from the replacement. The researcher reported that this could cause memory-safety problems and demonstrated a chain leading to privilege escalation and code execution in their test environment.

Who could be affected?

The reported attack requires database access and permission to create or replace tables in the affected schema. It is not described as an unauthenticated attack. Its severity comes from the possibility that a database-level user could potentially gain control beyond the privileges normally granted to that account.

How is it being addressed?

MariaDB confirmed the issue and marked the report resolved. The proposed approach is to reject the legacy prefix when the ordinary table name already maps directly to the same file, while retaining the prefix for legacy names that genuinely require it. The report also discusses broader safeguards, such as using a single canonical identity for table metadata and locks.

What should users do?

Database administrators should follow MariaDB’s security advisories and upgrade guidance for their specific release. Until patched, consider limiting table-creation and table-replacement privileges to trusted users, especially in schemas where less-trusted accounts can run DDL.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.