2.2. Problem

Adminer does not properly validate MySQL server responses in vulnerable versions.

Result: An attacker-controlled MySQL server can request:

"Read this local file on the machine or container hosting Adminer and send it to me."

This mechanism is related to the MySQL packet: 0xFB | filename → triggers local file reading.

Why version 4.6.2 is vulnerable

Adminer 4.6.2 allowed a user to specify an external MySQL server and connect to it freely. However, MySQL also allowed — by default — the use of:

• LOAD DATA LOCAL INFILE
• in automatic mode when certain servers requested a file.

Thus: Adminer → connects to malicious server → malicious server requests a file → Adminer sends it.

This is the essence of the vulnerability.

3. Exploitation conditions

The attacker must:

1. Host a malicious MySQL server (Rogue MySQL Server).
2. Get Adminer to connect to their server:
   • via a configuration error,
   • via a publicly exposed interface,
   • via a user action (supply host attack).
3. The rogue MySQL server sends a LOAD DATA LOCAL INFILE packet.
4. Adminer reads a local file.
5. The file is sent back to the attacker.

No root password is required to exfiltrate a local file: Adminer performs the action as a PHP application on the target server.

4. Consequences of the vulnerability

4.1. Confidentiality compromise

The attacker can:

• read /etc/passwd (of the entity hosting Adminer: host machine or container),
• read /etc/shadow (depending on PHP user permissions),
• retrieve configuration files,
• steal MySQL connection credentials,
• extract any information accessible by the web user.

4.2. Impact escalation

With the stolen MySQL credentials (secondary step), they can then:

• connect to the real internal database,
• read data,
• write to tables,
• inject malicious payloads.

5. Practical demonstration (PoC) — Lab architecture

The PoC is performed in an isolated and containerized environment to avoid any risk.

5.1. Lab components

1. Vulnerable Adminer (version 4.6.2) Role: victim Exposed locally via localhost:8080
2. Legitimate MySQL (optional) Role: simulate a real database
3. Rogue MySQL Server (Python) Role: attacker It sends the 0xFB filename packets to force Adminer to read a local file.

5.2. Folder structure

6. PoC walkthrough: how the vulnerability manifests?

6.1. Start the lab

6.2. Connect from Adminer to the Rogue Server

In http://localhost:8080:

• System: MySQL
• Server: rogue_mysql:33306
• User: anything
• Password: anything

6.3. Automatic process

1. Adminer sends the handshake.
2. The Rogue MySQL sends LOAD DATA LOCAL INFILE '/etc/passwd'.
3. Adminer reads /etc/passwd.
4. Adminer sends its content to the rogue.
5. The rogue stores the text in stolen_file.txt.

6.4. Observed result

Use the following command to view the rogue logs:

Expected result:

View the contents of the stolen_file.txt file:

Once inside the container, you can view the contents of files including stolen_file.txt

Result:

This result demonstrates the vulnerability unequivocally.

7. Mitigation measures

A. Update Adminer (this alone suffices)

Most reliable solution: Upgrade to Adminer ≥ 4.6.3

Later versions fix the network behavior.

What was fixed in later versions

Starting from Adminer 4.7.x, several protections were introduced:

Adminer now disables LOAD DATA LOCAL INFILE by default

Either:

• fully disabled
• or enabled only when explicitly authorized by the user

→ Result: your rogue MySQL can no longer exfiltrate files.

Adminer filters client actions before sending to the server

This prevents external connections from using dangerous functions.

Additional input validation mechanisms

New versions check:

• whether the target server is the expected one
• whether the action is not dangerous
• whether the request corresponds to a legitimate user action

B. Disable external connections

Limit Adminer to internal hosts only:

• via firewall (OUTPUT + DOCKER NETWORKS),
• via filtered reverse proxy,
• via strictly localized network configuration.

Production Adminer should always point to an internal MySQL.

C. Disable LOCAL INFILE on the MySQL side

Prevents theft via a legitimate MySQL client:

or:

D. Never expose Adminer publicly

Adminer must not be accessible on the Internet.

In production:

• restricted access via VPN,
• SSO or strong authentication,
• automatic expiration.

E. Remove Adminer after use

Adminer should be seen as a temporary tool:

• deploy it for a specific task,
• then remove it.

8. Resources and reliable references

• Source of the Python script used: https://github.com/Gifts/Rogue-MySql-Server/blob/master/rogue_mysql_server.py
• Official Adminer website https://www.adminer.org/en/
• Sansec (initial disclosure) https://sansec.io/research/adminer-4.6.2-file-disclosure-vulnerability
• Podalirius (technical explanations + PoC) https://podalirius.net/en/cves/2021-43008/
• vulhub: https://github.com/vulhub/vulhub/blob/master/adminer/CVE-2021-43008/

9. Final summary

CVE-2021-43008 is a critical vulnerability in Adminer ≤ 4.6.2 that allows:

• an attacker controlling a MySQL server,
• to force Adminer to read a local file,
• then exfiltrate its content to the attacker.

This is a perfect demonstration of the importance of:

• network control,
• MySQL client restrictions,
• non-exposure of administration tools,
• software version management.