HackerOne Bug Bounty Disclosure: data-index-directory-abuse

A MariaDB vulnerability allowed a user with ordinary table-creation privileges to misuse table and partition names as filesystem paths. In the most serious reported scenario, this could let the user access and alter MariaDB’s global account and privilege data—even without the global `FILE` privilege.

## How the vulnerability worked

MariaDB supports options that place table data or indexes in specified directories. The report found that some paths were built using table or partition names without consistently applying the filename encoding used elsewhere. Combined with weaknesses in path validation and legacy name handling, crafted names could make MariaDB operate on files outside the user’s own database.

The researcher demonstrated a path that moved the system table containing account and privilege information into an attacker-controlled schema. The attacker could read account records and modify them to add an account with full privileges. If those changes were activated—for example, after a restart or a privilege reload—the attacker could gain administrative access. Depending on the storage engine and filesystem permissions, related path-handling issues could also expose or damage files.

## What made the attack possible

The issue involved multiple interacting behaviors: unencoded names in certain filesystem operations, path checks that could fail to resolve paths containing missing directories, and partition-conversion operations that treated crafted partition identifiers as filesystem paths. Fixing one reported path exposed a separate route through partition handling.

## Fix and recommended action

MariaDB reported resolving the issue by disallowing the legacy `#mysql50#` form when creating filesystem-backed database objects, including tables and partitions. The issue is tracked as **CVE-2026-102523**. MariaDB administrators should apply the vendor’s security updates for their supported branch and review database account and privilege changes if they suspect a vulnerable server was exposed.

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 DATA / INDEX DIRECTORY Abuse

Report link

Date submitted 2026-10-07T19:53:07.386Z

A MariaDB vulnerability allowed a user with ordinary table-creation privileges to misuse table and partition names as filesystem paths. In the most serious reported scenario, this could let the user access and alter MariaDB’s global account and privilege data—even without the global `FILE` privilege.

## How the vulnerability worked

MariaDB supports options that place table data or indexes in specified directories. The report found that some paths were built using table or partition names without consistently applying the filename encoding used elsewhere. Combined with weaknesses in path validation and legacy name handling, crafted names could make MariaDB operate on files outside the user’s own database.

The researcher demonstrated a path that moved the system table containing account and privilege information into an attacker-controlled schema. The attacker could read account records and modify them to add an account with full privileges. If those changes were activated—for example, after a restart or a privilege reload—the attacker could gain administrative access. Depending on the storage engine and filesystem permissions, related path-handling issues could also expose or damage files.

## What made the attack possible

The issue involved multiple interacting behaviors: unencoded names in certain filesystem operations, path checks that could fail to resolve paths containing missing directories, and partition-conversion operations that treated crafted partition identifiers as filesystem paths. Fixing one reported path exposed a separate route through partition handling.

## Fix and recommended action

MariaDB reported resolving the issue by disallowing the legacy `#mysql50#` form when creating filesystem-backed database objects, including tables and partitions. The issue is tracked as **CVE-2026-102523**. MariaDB administrators should apply the vendor’s security updates for their supported branch and review database account and privilege changes if they suspect a vulnerable server was exposed.

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.