CVE-2025-62611

What it actually does

The flaw is a client-side arbitrary file disclosure issue in aiomysql before version 0.3.0. A malicious or impersonated MySQL server can send a LOAD DATA LOCAL INFILE request packet and cause a vulnerable aiomysql client to read and transmit local files accessible to the client process, even when the client-side local-file setting should prevent that behavior. The impact is confidentiality-only: secrets, configuration files, source code, SSH keys, environment variables, or other readable local files may be exfiltrated from the application host. Exploitation requires the vulnerable client to connect to an attacker-controlled or intercepted MySQL endpoint.

Why it matters to the business

Successful exploitation can expose credentials, database connection strings, API keys, private keys, application configuration, or sensitive files from systems running vulnerable aiomysql clients. This can lead to follow-on compromise of databases, cloud accounts, internal services, or source repositories if stolen secrets are reusable. The EPSS score is currently low and the issue is not listed in CISA KEV, but it is straightforward to exploit when an attacker can influence database connection targets, DNS, routing, service discovery, development tooling, or CI/CD configuration. The supplied product metadata lists Ubuntu 16.04 Firefox and Thunderbird packages with fixed versions, while the vulnerability description identifies aiomysql as the affected component; teams should validate applicability against authoritative vendor advisories and software inventory.

How an attack unfolds

An attacker first positions a rogue MySQL-compatible server where a vulnerable aiomysql client will connect, either by controlling an application configuration value, poisoning DNS, compromising service discovery, intercepting traffic, or luring a developer or automation job to use a malicious database endpoint. The rogue server emulates enough of the MySQL handshake and authentication flow for the client to proceed. After connection setup, the server sends a LOAD DATA LOCAL INFILE-style request for a chosen local path, such as an environment file, SSH key, application settings file, or operating-system configuration file. Because vulnerable aiomysql versions do not correctly enforce the client-side local-file setting before responding, the client opens the requested file and sends its contents back to the rogue server. The attacker then reviews the stolen content for credentials or operational details that can be used for further access.

How to fix it

Upgrade aiomysql to version 0.3.0 or later wherever it is used, including application dependencies, development environments, automation jobs, containers, and build images. Pin or constrain dependency versions to prevent reintroduction of vulnerable releases. Disable MySQL local infile functionality wherever not explicitly required, both in client connection options and on database servers. Restrict applications to approved database endpoints using allowlists, private networking, certificate validation where supported, and secure service discovery. Prevent untrusted users from controlling database host, port, connection string, or DNS resolution inputs. Rotate any secrets that may have been stored in files accessible to vulnerable client processes if exposure is suspected. The provided fixed-version data also lists Ubuntu 16.04 package fixes for Firefox 68.0+build3-0ubuntu0.16.04.1 and Thunderbird 1:60.8.0+build1-0ubuntu0.16.04.2; validate those package advisories separately because they do not align with the aiomysql vulnerability description.

How to confirm the fix worked

Confirm dependency inventory shows aiomysql version 0.3.0 or later in all runtime, container, virtual environment, lockfile, and build contexts. Check package manifests such as requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, setup.py, setup.cfg, SBOMs, and container image package lists for aiomysql versions below 0.3.0. Where practical, perform a controlled test against a benign MySQL test server that attempts a LOCAL INFILE request and verify the client refuses to send local file contents. Confirm application configuration uses only approved database endpoints and that local infile behavior is disabled unless there is a documented business requirement. For the supplied Ubuntu package entries, verify installed Firefox and Thunderbird package versions with the operating-system package manager only if those products are in scope for the relevant advisory.

Typical attack path

1. Identify an application, script, worker, development tool, or CI job that uses aiomysql before version 0.3.0.
2. Gain the ability to make that client connect to an attacker-controlled MySQL endpoint through configuration manipulation, DNS/service-discovery abuse, network interception, or social engineering.
3. Run a rogue MySQL-compatible server that completes or emulates the initial client handshake.
4. Send a server-side LOCAL INFILE request for targeted paths likely to contain secrets or sensitive data.
5. Receive the file contents transmitted by the vulnerable client process.
6. Use any exposed credentials, keys, tokens, or configuration data for follow-on access or lateral movement.

How to detect it

Investigate whether systems using aiomysql before 0.3.0 connected to unapproved, unexpected, newly registered, external, or attacker-controlled MySQL endpoints. Useful sources include application logs, dependency inventories, container image metadata, CI/CD job logs, DNS query logs, service-discovery logs, egress firewall logs, proxy logs, VPC flow logs, NetFlow, packet captures, and endpoint process/network telemetry. Look for Python processes initiating outbound MySQL connections to unusual hosts or IP addresses, particularly followed by file-read activity for sensitive paths. If packet capture is available, inspect MySQL traffic for server-to-client LOCAL INFILE request packets, commonly represented by command byte 0xfb followed by a requested file path. Application logs may not record the file transfer, so absence of an application error is not proof of non-exploitation. Hunt for access to high-value local files by Python application processes around the time of suspicious MySQL connections, including .env files, SSH private keys, cloud credential files, Kubernetes service account tokens, application settings, and /proc/self/environ. If a rogue endpoint is identified, treat any file readable by the vulnerable process as potentially exposed.

• LOAD DATA LOCAL INFILE
• LOCAL INFILE
• LOAD_LOCAL
• local_infile
• 0xfb
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /.env
• ~/.env
• /root/.ssh/id_rsa
• ~/.ssh/id_rsa
• /root/.aws/credentials
• ~/.aws/credentials
• /var/run/secrets/kubernetes.io/serviceaccount/token
• /app/.env
• /app/config.py
• settings.py
• config.yaml
• database.yml
• tcp/3306

What your security team should do

• Prioritize identifying all uses of aiomysql and upgrade any instance below 0.3.0.
• Review database connection configuration paths and remove any ability for untrusted users, job parameters, or external input to set MySQL hostnames or connection strings.
• Restrict outbound MySQL connections to approved database servers using firewall, egress gateway, security group, or proxy controls.
• Disable LOCAL INFILE support unless explicitly required and documented.
• Search logs and network telemetry for vulnerable clients connecting to unusual MySQL servers, especially internet-facing or recently introduced endpoints.
• If suspicious connections are found, rotate secrets stored in files readable by the affected process, including environment files, SSH keys, application configs, cloud credentials, and database credentials.
• Add dependency scanning and SBOM checks that fail builds when aiomysql versions below 0.3.0 are present.
• Validate the apparent affected-product mismatch between the aiomysql advisory and supplied Ubuntu Firefox/Thunderbird package data before using those package versions as remediation evidence.