MariaDB’s widely used mariadb-dump utility contains a path‑traversal flaw that can be abused to write arbitrary files and achieve remote code execution when a user interacts with a malicious export — the issue is tracked as CVE‑2025‑13699 and was disclosed publicly via a Zero Day Initiative advisory in late November 2025.
Background
MariaDB’s mariadb-dump is a standard tool for exporting database schemas and data. Administrators and automation scripts use it for backups, migrations, and incident response; in many environments it runs on operator workstations and CI/CD runners where user interaction or scripted invocation is routine. This ubiquity makes any vulnerability in mariadb-dump especially consequential: a path traversal within the utility’s handling of
view names can be leveraged by an attacker to escape intended filesystem directories and deposit attacker-supplied files on the host that processes the dump. The advisory for CVE‑2025‑13699 attributes the root cause to insufficient validation of user‑supplied path components when mariadb-dump processes view names. That lack of canonicalization allows sequences such as “../” or absolute paths to resolve outside the intended output directory and overwrite or create files in privileged locations. Several operating-system and distribution advisories (Debian, Ubuntu, SUSE) and vulnerability trackers list the flaw and identify fixed package releases.
What was disclosed (executive summary)
- The vulnerability identifier: CVE‑2025‑13699.
- The reported weakness: Directory traversal (CWE‑22) in mariadb-dump’s handling of view names, enabling arbitrary file write.
- Exploitation condition: An attacker must get the target to interact with mariadb-dump in a way that processes crafted view names — for example, by convincing an operator to dump a database served by a malicious or compromised server, or by supplying a crafted dump stream. The advisory states interaction with the utility is required.
- Severity and scoring: public trackers and distro teams list a high severity (CVSS ≈ 7.0), reflecting high confidentiality/integrity/availability impact when the preconditions are met.
- Affected releases and fixes: vendor and third‑party sources list affected version ranges and fixed versions; maintainers recommend upgrading to specific patched versions (examples below).
Technical analysis — how the bug works
Attack surface and trigger
At a high level, mariadb-dump constructs file paths when serializing database objects (tables, views, triggers) and, in this implementation, when materializing view metadata or auxiliary files. If the code accepts a view name that contains traversal sequences or absolute path elements and uses it directly in a file‑operation (open, create, write) without canonicalizing against the intended output directory, then the resolved path can point anywhere on the filesystem accessible to the process.
When mariadb-dump processes such a crafted view name while exporting, it may write files outside the dump directory. An attacker who can control the view name value in the dump stream — or who can cause an operator to run mariadb-dump against a DB instance that returns malicious view metadata — can place files where they will later be executed or loaded by the system or a service. This is the classic
ZipSlip/Path‑Traversal → Write pattern adapted to database export tooling.
Exploit model and preconditions
- Interaction required: public advisories are explicit that the attack requires interaction with the mariadb-dump utility; it is not a self‑propagating remote unauthenticated exploit that works over the wire without user action. This means the typical exploitation chain involves social engineering (convincing an operator to run mariadb-dump against a hostile endpoint or to import a malicious dump file) or automated systems that run dump jobs against attacker‑controlled databases.
- Privilege context: the code execution will occur in the context of the user account that runs mariadb-dump. If the utility runs as an administrator, service account, or in a privileged CI runner, the impact can be severe; if it runs as an unprivileged user, the immediate blast radius is smaller but still material (credential files, SSH keys, local persistence locations).
- Attack complexity and user interaction: most public trackers and the vendor advisories rate the complexity as non‑trivial because it depends on luring a process into writing attacker data. CVSS vector strings published in the ZDI advisory and distribution notices map to user interaction required and local attack vector in some scoring variants, reflecting disagreement about whether this is fully remote or effectively local via operator interaction. Administrators should treat that ambiguity conservatively.
Why this can lead to code execution
Writing arbitrary files into locations that get executed or read by automated processes creates immediate RCE opportunities. Examples include:
- Writing a script into a cron, startup, or systemd directory that will run later.
- Overwriting configuration or library files used by privileged services.
- Dropping web application files into directories served by web servers where the service automatically loads or executes files.
Because mariadb-dump runs as the invoking user, the exploit’s power is strictly tied to what that user can create or overwrite. In many enterprises, backups and automation agents run with elevated privileges or under service accounts that carry broader access, increasing risk.
Affected versions and patch status (verified)
Multiple independent trackers and distributors report the same core affected ranges and fixed releases. Cross‑referencing vendor, distro, and third‑party records provides a reliable view:
- Snyk’s advisory and package trackers list vulnerable MariaDB releases and recommend upgrading to 10.6.24, 10.11.15, 11.4.9, 11.8.4 or later.
- Distribution advisories (SUSE, Debian, Ubuntu) list patched package versions and map the CVE to distro package numbers — for example, SUSE published multiple patch advisories with fixes included in updated builds (openSUSE / SLES updates).
- Debian’s security tracker and Ubuntu’s security page list the CVE and show which source packages remain vulnerable versus those already marked fixed in particular suites. Operators using Debian/Ubuntu should consult their distribution’s package status to determine whether their installed package is flagged vulnerable and which version contains the fix.
Note: some trackers report slightly different affected sub‑versions depending on how downstream packagers backport fixes or rename packages. Always validate the fix by checking the package changelog or vendor patch notes for MDEV‑37483 (MariaDB’s issue tracker) and the distribution advisory for the exact package build you run.
Discrepancies and points that need caution
Several authoritative sources agree on the vulnerability mechanics and the presence of fixes, but there are two notable areas where public records diverge or require careful reading:
- Attack vector characterization (Local vs Network):
- The ZDI advisory’s CVSS mapping indicates an attack vector with local characteristics (the exploit requires interaction with mariadb-dump). Some public summaries phrase the flaw as enabling “remote attackers” because the compromise can happen if the operator runs the tool against a remote, attacker‑controlled database. This difference is semantic but important operationally: the vulnerability is not exploitable purely over a raw network socket without operator action — exploitation typically requires a human or automated process to run mariadb-dump in a context that consumes malicious view metadata. Treat published wording that says “remote attacker” with caution and interpret it in the exploitation model context described above.
- Exact fixed versions across branches:
- Maintainers of different branches and downstream distributions may release fixes under different package versions or backpatch the fix into earlier branches. The practical guidance is to consult your distribution’s advisory and MariaDB’s upstream MDEV‑37483 entry for the exact patch details that apply to your deployment. When in doubt, upgrade to the nearest patched upstream version or apply the vendor/distro package that carries the fix.
These differences are not contradictions about the presence of a real flaw; they are editorial distinctions in how exploitability and packaging are described. Administrators should plan defensively given the real write/overwrite semantics of the bug.
Immediate actions for Windows and Linux administrators (prioritized)
- Patch first (highest priority)
- Apply the vendor or distribution package that contains the CVE fix. Upgrade MariaDB/mariadb-server packages to the patched versions listed by your vendor/distributor (for many vendors: 10.6.24, 10.11.15, 11.4.9, 11.8.4 or later as example targets). Use your platform’s normal patching channels (apt/yum/zypper, vendor repositories). Verify package changelogs reference CVE‑2025‑13699 or MDEV‑37483.
- Immediate configuration mitigations (short term)
- Avoid running mariadb-dump on untrusted or unknown database endpoints. Treat any external DB you are asked to dump as untrusted until it is inspected.
- If automation runs mariadb-dump against externally provided endpoints (third‑party services, customer DB exports), pause those jobs until patched or place them inside an isolated sandbox account that cannot write to sensitive host paths.
- Ensure the user account that runs database exports is limited: drop unnecessary privileges, use a minimal local user with no access to admin directories, and do not run dump jobs as root or highly privileged service accounts.
- Host hardening (medium term)
- Enforce filesystem ACLs that prevent unprivileged users from writing to system directories (e.g., /etc, /usr, %ProgramFiles%).
- Run dump jobs inside ephemeral containers or VMs with strict filesystem and network separation so that a malicious dump cannot reach high‑value host locations.
- Use mandatory access control (AppArmor, SELinux, Windows Defender Application Control) to constrain mariadb-dump’s file‑write capabilities.
- Detection and monitoring (concurrent)
- Add audit rules to detect writes to sensitive paths by mariadb‑dump processes (Linux: auditd syscall monitoring for open/create by process name; Windows: enable Object Access auditing and filter for mariadb-dump.exe or process owner).
- Scan for suspicious files with creation timestamps coinciding with dump activities and unexpected file extensions in service directories.
- Monitor logs from backup/restore jobs for unexpected warnings or errors that could indicate exploitation attempts.
- Incident response if you suspect compromise
- Preserve the host image (disk snapshot) and the dump file involved.
- Collect process execution traces, shell history of the user who invoked mariadb-dump, and audit logs.
- Rotate credentials and keys that might have been exposed, particularly if the dump process had access to configuration files or key material.
How to verify your environment is patched (practical checklist)
- Check your MariaDB package version:
- Debian/Ubuntu: apt policy mariadb-server && apt changelog mariadb-server | grep CVE-2025-13699.
- SUSE: zypper info mariadb and review the advisory IDs (SUSE‑2025‑4438 / SUSE‑2025‑4502 entries reference the CVE).
- Confirm upstream MDEV‑37483 or MariaDB advisory lists a fix and matches your packaged version or commit.
- If you cannot patch immediately, isolate all systems that run mariadb-dump from untrusted networks, and restrict who can invoke dump jobs.
Detection recipes (examples defenders can implement)
- Linux (auditd): add a rule to log create/open events by processes named mariadb-dump or by the dump user. Correlate with process execution timestamps and unusual file paths.
- Windows: enable and forward Security event logs for Object Access and filter for file writes by mariadb-dump.exe. Combine with Sysmon process/create and file creation monitoring for host‑level analytics.
- File integrity monitoring: configure FIM to alert when new files appear in boot, startup, or web‑root directories outside scheduled deployments. Trigger additional alerts if creation coincides with scheduled dump jobs.
- SIEM correlation: look for patterns where a dump task runs and shortly thereafter there are file creations under privileged locations, new scheduled tasks, or new services registered.
Broader operational implications
- Backups-as-code risk: organizations that treat database dumps as a transport mechanism for schema or object sharing (for example, automated pipeline jobs pulling dumps from external sources) must rethink trust boundaries. A malicious dump is an active attack vector, not only a passive data artifact.
- Supply‑chain and automation exposure: CI/CD runners, developer workstations, and management jump hosts that automatically run dump and restore scripts are high‑risk execution points. Hardening these systems is as important as patching the database server itself.
Strengths in the public response and remaining weaknesses
What was done well:
- Coordinated disclosure and vendor patching: the vulnerability was reported through responsible channels (ZDI coordination and MariaDB bug-tracker MDEV‑37483) and vendors/distributions produced advisories and package updates within weeks, which is a reasonable timeline for a non‑wormable but high‑impact bug.
- Distribution coordination: major distributions (SUSE, Debian, Ubuntu) have published package advisories and mapping information, enabling administrators to apply vendor‑approved fixes rather than relying on out‑of‑band patches.
Remaining risks and gaps:
- Messaging ambiguity over “remote” vs “local” exploitation semantics can lead to under‑ or over‑triage. Operators must interpret advisories in the context of their operational pipelines: if dump jobs are automated and run without human review, the effective exploitability may be high even if the CVE’s vector is described as local.
- Environments where mariadb-dump is run with elevated privileges or where export tooling is integrated into privileged automation remain high risk until patched and reconfigured. Patching alone is necessary but not sufficient — procedural changes and host hardening must accompany updates.
Practical remediation playbook (step‑by‑step)
- Inventory: identify all hosts that run mariadb-dump (admin workstations, backup servers, CI runners). Use package-management queries and configuration management reports to produce an authoritative list.
- Patch: apply vendor or distribution packages that list CVE‑2025‑13699 in their changelog; verify the package release matches upstream fix versions or distro advisory guidance. Reboot services as required and validate dump functionality in staging before production rollouts.
- Isolation: until patched, disable automated dump jobs that contact external DB endpoints; limit connections to trusted hosts only.
- Principle of least privilege: run dump tasks under dedicated, minimally privileged accounts inside containers/VMs; avoid running as root or privileged service users.
- Monitoring: implement audit rules and file integrity checks targeted at dump activity and writes to sensitive directories. Add correlation rules to your SIEM for dump task → file write → new service/task sequences.
- Post‑patch verification: replay a subset of dumps in a sandbox to verify expected behavior; ensure no unexpected files are created and that output directories contain only permitted artifacts.
Conclusion
CVE‑2025‑13699 is a sober reminder that utilities used for routine systems operations — backup and export tools like mariadb-dump — are part of the attack surface and need the same rigor as network‑facing daemons. The underlying bug is straightforward (path traversal on view names), but its operational impact is amplified by how and where mariadb-dump is run: on privileged workstations, in automated pipelines, and inside build runners. The right immediate steps are clear and urgent: patch using vendor/distribution advisories, harden the accounts and contexts that run dump jobs, and monitor writes to critical host paths. Cross‑checked records from the Zero Day Initiative, vendor trackers, and major distributions confirm the flaw, the affected ranges, and the availability of patches — administrators must act promptly and apply the defense‑in‑depth guidance above to reduce risk.
Source: MSRC
Security Update Guide - Microsoft Security Response Center