HackerOne Bug Bounty Disclosure: -mysql-legacy-alias-internal-table-collisions

MariaDB supports a legacy table-name prefix, #mysql50#, to access older tables whose names do not follow modern filename-encoding rules. The report found that this compatibility feature could let specially crafted names map to database files used internally by MariaDB or its storage engines. In effect, a table name could collide with another table’s on-disk files or with files used for partitions and other internal structures.

Why could that be dangerous?

Such collisions could confuse MariaDB which table a file belonged to, including when the table’s actual layout differed from the layout MariaDB expected. The researcher demonstrated several consequences: leaking data across table-permission boundaries through a merge table, exposing or corrupting table data, and—in a complex chain that also relied on memory-disclosure and memory-write techniques—achieving code execution as the operating-system account running MariaDB. The report also described related ways to abuse file paths and database object files.

Who could exploit it?

This was not presented as an unauthenticated attack. The examples require access to MariaDB and the ability to run SQL statements, with the exact privileges depending on the particular attack path. Some demonstrations used a relatively limited database account, while the code-execution chain depended on additional vulnerabilities or primitives. Successful code execution would run with MariaDB’s operating-system privileges, not automatically as system administrator.

How was it addressed?

MariaDB’s response was to restrict creation of new objects using the legacy #mysql50# naming mechanism and to add checks intended to prevent filename aliases and collisions. The developers also fixed several additional issues identified during testing, including edge cases involving partitions, reserved filenames, malformed names, and rollback behavior. The report was marked resolved.

What should users do?

Use a MariaDB release that includes the relevant security fixes, following the vendor’s advisories for the affected versions. Until systems are updated, limit database access and privileges to trusted users, and review exposure to untrusted SQL or database accounts. The report does not establish that every MariaDB version is affected in the same way, so consult MariaDB’s official guidance to identify the appropriate fixed release.

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 / internal table collisions

Report link

Date submitted 2026-10-07T19:48:18.484Z

MariaDB supports a legacy table-name prefix, #mysql50#, to access older tables whose names do not follow modern filename-encoding rules. The report found that this compatibility feature could let specially crafted names map to database files used internally by MariaDB or its storage engines. In effect, a table name could collide with another table’s on-disk files or with files used for partitions and other internal structures.

Why could that be dangerous?

Such collisions could confuse MariaDB which table a file belonged to, including when the table’s actual layout differed from the layout MariaDB expected. The researcher demonstrated several consequences: leaking data across table-permission boundaries through a merge table, exposing or corrupting table data, and—in a complex chain that also relied on memory-disclosure and memory-write techniques—achieving code execution as the operating-system account running MariaDB. The report also described related ways to abuse file paths and database object files.

Who could exploit it?

This was not presented as an unauthenticated attack. The examples require access to MariaDB and the ability to run SQL statements, with the exact privileges depending on the particular attack path. Some demonstrations used a relatively limited database account, while the code-execution chain depended on additional vulnerabilities or primitives. Successful code execution would run with MariaDB’s operating-system privileges, not automatically as system administrator.

How was it addressed?

MariaDB’s response was to restrict creation of new objects using the legacy #mysql50# naming mechanism and to add checks intended to prevent filename aliases and collisions. The developers also fixed several additional issues identified during testing, including edge cases involving partitions, reserved filenames, malformed names, and rollback behavior. The report was marked resolved.

What should users do?

Use a MariaDB release that includes the relevant security fixes, following the vendor’s advisories for the affected versions. Until systems are updated, limit database access and privileges to trusted users, and review exposure to untrusted SQL or database accounts. The report does not establish that every MariaDB version is affected in the same way, so consult MariaDB’s official guidance to identify the appropriate fixed release.

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.