CVE-2026-44171

What it actually does

CVE-2026-44171 is a path traversal vulnerability in MariaDB's mbstream archive unpacking functionality. A crafted mbstream backup archive containing parent-directory path components such as /../ can cause mbstream to write files outside the intended target directory during extraction. Because mbstream is commonly used for physical backup and restore workflows, successful exploitation can result in arbitrary file creation or overwrite with the privileges of the user running the restore process. Depending on execution context and writable locations, this can lead to confidentiality loss, data tampering, service disruption, or follow-on code execution if sensitive configuration, startup scripts, database files, or application-controlled paths are overwritten. The CVSS vector indicates local attack requirements, high attacker privileges, high complexity, and user interaction, meaning exploitation typically requires the attacker to influence a restore operator or automated restore process into unpacking a malicious archive.

Why it matters to the business

An attacker who can get a malicious MariaDB backup archive restored could cause files to be written in unexpected locations, potentially corrupting databases, altering configuration, disrupting recovery operations, or weakening system security. The highest risk is in environments where database backups are exchanged between systems, restored from less-trusted sources, processed by automation, or unpacked by privileged accounts. This issue is not currently in CISA KEV, has no known mature public exploit, and has a low EPSS score, so it is not an internet-scale emergency; however, backup and restore tooling is security-sensitive, and compromise during recovery can undermine disaster recovery, incident response, and data integrity.

How an attack unfolds

An attacker first obtains a position where they can create, modify, replace, or supply a MariaDB mbstream backup archive that an administrator, script, or restore pipeline will later unpack. They craft the archive so one or more file entries contain traversal sequences such as /../ that resolve outside the operator-specified target directory. When a vulnerable mbstream version extracts the archive, it fails to reject those paths and creates or overwrites files at the traversed destination using the permissions of the mbstream process. The practical impact depends on where the process can write: the attacker may overwrite database files, place malicious configuration, corrupt application data, or create files used by later operational workflows. Because exploitation requires local or supply-chain-style access to the backup/restore process plus user interaction or automated processing, likely scenarios include malicious insiders, compromised backup storage, poisoned restore artifacts, or attackers persisting after initial access by weaponizing recovery media.

How to fix it

Upgrade MariaDB to a fixed release for the deployed branch: 10.6.26 or later for 10.6.x, 10.11.17 or later for 10.11.x, 11.4.11 or later for 11.4.x, 11.8.7 or later for 11.8.x, and 12.3.2 or later for 12.3.x. Avoid using vulnerable mbstream versions to unpack backup archives, especially archives from untrusted, shared, or externally influenced locations. Until upgrades are complete, only restore backups from trusted sources, verify archive provenance and integrity before extraction, unpack as a dedicated low-privilege user, use restrictive filesystem permissions, run restores inside an isolated temporary directory or container, and monitor for files created outside the expected restore target. Treat backup repositories and restore automation as privileged assets and restrict write access to them.

How to confirm the fix worked

Confirm the installed MariaDB/mbstream version is not in the vulnerable ranges: 10.6.1 through 10.6.25, 10.11.1 through 10.11.16, 11.4.1 through 11.4.10, 11.8.1 through 11.8.6, or 12.3.1. Verify mbstream reports a fixed MariaDB version after package updates. Review restore scripts and backup tooling to ensure they invoke the patched binary rather than an older bundled or copied mbstream executable. As a safe functional validation, in a disposable test environment only, attempt to extract a benign test archive containing a traversal path and confirm the patched tool rejects or prevents writing outside the specified target directory. Also validate that restore jobs run with least privilege and that target directories are isolated from sensitive system paths.

Typical attack path

1. Gain the ability to create, modify, or replace a MariaDB mbstream backup archive, such as through access to backup storage, a build/recovery pipeline, or a system used to stage restores.
2. Create a specially crafted mbstream archive containing file paths with parent-directory traversal sequences such as /../.
3. Wait for or induce an administrator, job scheduler, or restore automation to unpack the archive using a vulnerable MariaDB mbstream version.
4. During extraction, cause mbstream to write files outside the intended target directory.
5. Use the created or overwritten files to corrupt data, alter configuration, disrupt service, expose sensitive information, or enable follow-on compromise depending on filesystem permissions.

How to detect it

Investigate whether vulnerable mbstream versions were used to unpack archives from untrusted or modifiable sources. Useful log sources include shell history, sudo logs, auditd or Linux process accounting, EDR process telemetry, backup orchestration logs, CI/CD or recovery pipeline logs, file integrity monitoring, and filesystem audit events around restore windows. Search for mbstream executions with extraction options and correlate their timestamps with unexpected file creation or modification outside the intended restore directory. Inspect recently restored mbstream archives, if available, for member names containing traversal patterns such as /../ or ../. Review changes to MariaDB configuration files, service unit files, cron directories, shell profiles, SSH authorized_keys files, application directories, and database data directories that occurred immediately after restore operations. Because there are no known public exploit campaigns or named threat actors for this issue, detection should focus on anomalous restore provenance, suspicious archive paths, and unauthorized file writes rather than malware-specific indicators.

• /../
• ../
• mbstream
• mbstream -x
• mbstream --directory
• mbstream:
• xtrabackup
• mariabackup
• /etc/cron.d/
• /etc/cron.daily/
• /etc/systemd/system/
• /root/.ssh/authorized_keys
• /home/*/.ssh/authorized_keys
• /etc/ld.so.preload
• /etc/profile.d/
• /var/lib/mysql/
• /etc/mysql/
• /etc/my.cnf
• /etc/mysql/my.cnf

What your security team should do

• Inventory systems and containers that include MariaDB mbstream and identify versions in the affected ranges.
• Prioritize patching backup servers, database administration hosts, restore automation runners, and disaster recovery environments before lower-risk endpoints.
• Upgrade to MariaDB 10.6.26, 10.11.17, 11.4.11, 11.8.7, 12.3.2, or later as appropriate for the branch in use.
• Temporarily block or require additional review for restores from untrusted, externally supplied, recently modified, or integrity-unverified mbstream archives.
• Harden backup repositories by limiting write access, enabling immutability where practical, and requiring checksums or signatures for restore artifacts.
• Run mbstream restores as a dedicated non-root user with access only to the intended restore location.
• Review recent restore activity for unexpected file writes outside target directories, especially on systems where mbstream ran with elevated privileges.
• Add detection for mbstream executions and archive inspections involving traversal strings such as /../ or ../ in backup archive member paths.