DEV Community

Ioneyrezende
Ioneyrezende

Posted on

MariaDB in a Multi-Tenant Environment: What AL-2026-144 Changes for Shared Instances

MariaDB in a Multi-Tenant Environment: What AL-2026-144 Changes for Shared Instances

Vulnerability overview

Shared database instances concentrate the AL-2026-144 flaws. CSA Singapore published the alert on 16 October 2026 covering five MariaDB Server vulnerabilities: CVE-2026-107814 and CVE-2026-107818 at 8.4, CVE-2026-107815 at 8.5, CVE-2026-107821 at 8.0 and CVE-2026-107823 at 7.2 under CVSS v3.1. Four of the five need a session with a specific privilege, and in a multi-tenant model the tenant boundary is exactly where those privileges get handed out carelessly.

Mechanism and exploitation conditions

CVE-2026-107823 is the clearest multi-tenant concern. An authenticated user with CREATE USER and CREATE VIEW WITH GRANT OPTION can create a crafted username carrying additional view metadata that the parser then treats as security metadata, potentially escalating privileges. In a single-tenant deployment that means moving from an application account to an administrative one. Across tenants it means reaching a neighbour's schema.

The FILE pair, CVE-2026-107814 and CVE-2026-107818, crosses the tenant boundary differently. The write happens on the host, under the service account, so the damage is not confined to the schema that hosted the session. Any tenant that can obtain FILE can affect every tenant on the host.

CVE-2026-107815 and CVE-2026-107821 complete the picture. CONNECT reaches outside the server by design, and a crafted FRM file placed in the data directory affects the shared parser for everyone on the instance.

Impact

The practical consequence is loss of the isolation assumption. Tenants are segregated by database grants, and these flaws show that grants alone do not contain filesystem effects.

For a provider, that reframes incident response. A single tenant reporting suspicious activity no longer limits the scope of investigation, and post-incident disclosure obligations may extend to every tenant on the affected host.

Affected products and scope

Ranges are 10.6.1 to 10.6.27, 10.11.1 to 10.11.18, 11.4.1 to 11.4.12, 11.8.1 to 11.8.8, 12.3.1 to 12.3.2 and 13.0.1. The advisory lists no public proof of concept and no confirmed in-the-wild exploitation, so tenant-facing urgency comes from the shared-host architecture rather than from observed attacks.

Exposure context

A ZoomEye query for app="MariaDB" returns 5111720 assets identifying as MariaDB. For providers, that external figure is less useful than an internal count: how many shared hosts, how many tenants each, and which of those hosts grant FILE or CREATE USER outside a controlled administrative identity.

ZoomEye search: https://www.zoomeye.ai/searchResult?q=YXBwPSJNYXJpYURCIg%3D%3D

Remediation and mitigations

Patch every branch present in the fleet and verify the running build per host. In shared environments, a single unpatched host undermines the isolation story for all of its tenants.

Then reduce the shared capability set. Provision tenant accounts without FILE, without CREATE USER, and without GRANT OPTION in view creation; put schema management behind an administrative identity that tenants cannot reach. Where CONNECT exists only for historical reasons, disable it per instance.

Review the data directory and service account home for unexpected files, and treat any finding as a host-level incident that spans tenants. Communicate on that basis rather than per tenant.

References

Top comments (0)