CVE-2021-43008 — Adminer Vulnerability

Arbitrary file reading via a malicious MySQL server

1. What is Adminer?

Adminer is a web tool (PHP) for easily administering MySQL, PostgreSQL, SQLite or SQL Server databases. It is commonly deployed as a lightweight alternative to phpMyAdmin.

Affected versions: Adminer ≤ 4.6.2

---

2. What is the nature of the vulnerability?

2.1. Access Control Failure

Adminer allows connection to any remote MySQL server. When connecting to a MySQL server, the client (here Adminer) accepts:

• a set of initial instructions from the server,
• including the LOAD DATA LOCAL INFILE command, which allows the server to ask the client to send it a local file.

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

adminer_CVE-2021-43008/
│
├── README.md
├── docker-compose.yml
│
└──rogue_mysql_server/
	├── rogue_mysql_server.py
	├── requirements.txt
	└── Dockerfile

---

6. PoC walkthrough: how the vulnerability manifests?

6.1. Start the lab

docker compose build && docker compose up -d

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:

docker logs -f rogue_mysql

Expected result:

2025-11-27 16:59:54,248:INFO:Serving on ('0.0.0.0', 33306)
2025-11-27 17:02:55,213:INFO:Conn from: ('172.18.0.3', 37200)
2025-11-27 17:02:55,214:INFO:Last packet
2025-11-27 17:02:55,214:INFO:Query
2025-11-27 17:02:55,214:INFO:Requesting file: /etc/shadow
2025-11-27 17:02:55,215:INFO:-- Received file data
2025-11-27 17:02:55,215:INFO:Result length: 1 bytes
2025-11-27 17:02:55,216:INFO:Last packet
2025-11-27 17:02:55,216:INFO:Query
2025-11-27 17:02:55,216:INFO:Requesting file: /etc/passwd
2025-11-27 17:02:55,216:INFO:-- Received file data
2025-11-27 17:02:55,217:INFO:Result length: 920 bytes
2025-11-27 17:02:55,217:INFO:File content received: 919 bytes
2025-11-27 17:02:55,217:INFO:File saved to stolen_file.txt

View the contents of the stolen_file.txt file:

docker exec -it rogue_mysql sh

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

# ls
mysql.log  requirements.txt  rogue_mysql_server.py  stolen_file.txt

# cat stolen_file.txt

Result:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/bin/false

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:

[mysqld]
local_infile=0

or:

SET GLOBAL local_infile=0;

---

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