Bug 2482963

Summary:	artemis-core-client: Unsafe Reflection in Apache ActiveMQ Artemis Federation Message Deserialization
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	anujha, asoldano, bbaranow, bmaxwell, bstansbe, dlofthou, istudens, ivassile, iweiss, mosmerov, msvehla, nwallace, pberan, pesilva, pjindal, pmackay, rstancel, security-response-team, smaestri, thjenkin, vdosoudi
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	Apache ActiveMQ Artemis before 2.34.0 contains an unsafe reflection vulnerability in FederationStreamConnectMessage.getFederationPolicy(). The method calls Class.forName(clazz).getConstructor().newInstance() where clazz is read directly from the CORE protocol wire buffer without type validation. An authenticated federation peer can send a FEDERATION_DOWNSTREAM_CONNECT packet with a crafted class name, causing the broker to load and instantiate arbitrary classes visible to the Artemis module classloader. Static initializers (<clinit>) and no-argument constructors (<init>()) execute as side effects before the type cast, enabling denial of service via system-property poisoning, out-of-memory conditions via classloading, or broker state manipulation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-28 22:24:24 UTC

see https://docs.google.com/document/d/1XdX8AJzGjBgCLE0UZ5N_RGGrzQ14HSVS8HcDgH0X70w/edit?tab=t.6q218rre4ubh#bookmark=id.a4srunl7g7zw for detailed analysis

the unsafe Class.forName() reflection in FederationStreamConnectMessage.getFederationPolicy() is a separate code defect that requires its own fix. the reflection type-check fix landed independently in Artemis 2.34.0 via ARTEMIS-4766. When there is code that still needs to be fixed independently of an existing CVE, a separate CVE is warranted to ensure proper tracking, backporting, and remediation.

Fix status: The upstream fix is delivered in two stages. The primary fix — type validation before instantiation — was released in Artemis 2.34.0 via ARTEMIS-4766. This type check narrows the attack surface to only FederationPolicy implementations (2-3 classes with benign constructors), making exploitation impractical. A complete fix — full removal of the Class.forName() reflection — has been merged to main via ARTEMIS-6067 (2026-05-19) but is not yet released (expected in Artemis 2.55.0). The new CVE fix version should reference Artemis 2.34.0 (ARTEMIS-4766) as the primary fix.

Scored independently (post-auth context, PR:H), the standalone CVSS is 5.5 Medium. However, on products where CVE-2026-27446 is unpatched (e.g., JBoss EAP 7.4 ELS1 — "Will not fix"), this reflection is reachable pre-auth and the combined effective severity is higher.

Comment 1 errata-xmlrpc 2026-08-11 16:37:34 UTC

This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 7

Via RHSA-2026:53644 https://access.redhat.com/errata/RHSA-2026:53644

Comment 2 errata-xmlrpc 2026-08-11 17:42:22 UTC

This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 7.4.25

Via RHSA-2026:53806 https://access.redhat.com/errata/RHSA-2026:53806