Cloudanix VulnDB

CVE-2026-119210

Medium · 5.9

CVSS

5.9

EPSS

0.3%

Published

Oct 29, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A database connection library could be tricked by a malicious server into sending files from a user's computer to an attacker.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Data Exposure
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Bypass of filename validation in ClientMessage.validateLocalFileName() allows a malicious server or MITM to inject LOAD DATA LOCAL INFILE requests via crafted identifiers or metadata queries, causing the client to stream arbitrary local files when allowLocalInfile is enabled.

Why it matters to the business

Applications using the affected connector versions risk unauthorized exposure of sensitive client-side files to an attacker-controlled database server, potentially leading to data leakage with minimal attacker effort required.

How an attack unfolds

An attacker positions a malicious or compromised MariaDB/MySQL server or intercepts traffic; when the client performs metadata or update operations, the server returns crafted identifiers that trigger the vulnerable regex, causing the client to honor a subsequent LOCAL INFILE request and stream the named local file back to the attacker.

How to fix it

Upgrade MariaDB Connector/J to version 3.3.7 or later, 3.4.5 or later, or 3.5.11 or later. Disable allowLocalInfile wherever possible and avoid using updatable result sets or metadata methods against untrusted servers.

How to confirm the fix worked

Confirm the connector version is at or above a fixed release; test by attempting a connection to a server returning crafted identifiers while monitoring for unexpected LOCAL INFILE activity or file access attempts.

Typical attack path

  1. Attacker controls or compromises a MariaDB/MySQL server reachable by the victim application
  2. Victim application connects with allowLocalInfile enabled and performs queries involving DatabaseMetaData or updatable ResultSets
  3. Server responds with maliciously crafted database/table identifiers or result metadata containing LOAD DATA LOCAL INFILE syntax
  4. Connector's flawed regex accepts the injected text and issues a LOCAL INFILE request for an attacker-chosen client file
  5. Client streams the requested file contents to the attacker-controlled server

How to detect it

Review application logs for unexpected LOAD DATA LOCAL INFILE requests or file access originating from the connector; inspect network traffic for responses containing suspicious quoted identifiers followed by file transfer requests; check process monitoring for reads of sensitive local files shortly after database metadata calls.

What your security team should do

  • Immediately inventory all Java applications using MariaDB Connector/J and identify those on versions 3.0.0 through the vulnerable ranges
  • Prioritize upgrade to 3.3.7, 3.4.5, or 3.5.11 within the next patch cycle given the two-day publication window
  • Review connection configurations and set allowLocalInfile=false by default
  • Monitor for any new exploit code or EPSS increases over the coming weeks

The record

MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the ClientMessage.validateLocalFileName() check used a regular expression that could match LOAD DATA LOCAL INFILE text inside quoted identifiers, string literals, or comments instead of requiring a real statement. A malicious or compromised server, or a machine-in-the-middle attacker, could return crafted database or table identifiers that the connector reused in metadata or updatable-result queries, then answer with a LOCAL INFILE request for a client file. With allowLocalInfile enabled, this caused the connector to stream any readable client-host file named by the crafted text, including through DatabaseMetaData.getImportedKeys(), DatabaseMetaData.getExportedKeys(), or ResultSet.updateRow() paths. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities