What the advisory says
Apache disclosed CVE-2022-23913 as an Apache ActiveMQ Artemis availability issue in which maliciously formed protocol data could cause uncontrolled memory consumption and partially disrupt broker availability. The reviewed GitHub advisory rates the issue high severity and maps it to CWE-770. [S1] [S2] [S3] [S4]
Affected releases
For the Maven package org.apache.activemq:artemis-core-client, the reviewed advisory and OSV mark releases earlier than 2.19.1 as affected and 2.19.1 as the first fixed release. [S2] [S3]
Apache's announcement describes the maintained upgrade paths: use Artemis 2.20.0 or newer on the main line, or 2.19.1 on the Java 8 maintenance line. Prefer the latest supported release compatible with the rest of the Artemis stack. [S1] [S6]
Why deployment context matters
An affected dependency is actionable patch-triage evidence, but it is not proof of an exploitable live broker. Practical exposure depends on which artifact is deployed, whether the affected code is loaded, whether untrusted protocol data can reach it, and the runtime's resource controls.
Covered by FixVibe
Covered by FixVibe. Authorized GitHub repo scans can report affected org.apache.activemq:artemis-core-client dependency evidence from supported Maven manifests. A finding includes the dependency source, detected version or supported range, fixed version, confidence, and a version-based advisory evidence posture.
FixVibe does not connect to an Artemis broker, send messages or crafted protocol data, consume memory, attempt a crash, or reproduce denial of service. Repository evidence does not prove deployment, reachability, untrusted traffic, resource exhaustion, or runtime impact.
Remediation
Upgrade the affected dependency using the appropriate supported Artemis release line. Apache recommended 2.20.0 on the main line and 2.19.1 for Java 8 users; newer supported releases include the correction. Keep related Artemis modules aligned through the project's dependency-management source, regenerate resolved dependencies, rebuild deployed artifacts, and remove stale vulnerable packages from images and caches. [S1] [S2] [S5] [S6]
Verify the resolved dependency tree and the version inside the deployed artifact, then use normal functional and load smoke tests with resource monitoring. Confirm that network access to broker protocols is restricted to trusted clients. Do not use crafted packets, deliberate memory exhaustion, crash testing, or denial-of-service attempts as verification.