Bug 2431939 (CVE-2026-24330)

Summary:	CVE-2026-24330 wildfly-core: WildFly: Arbitrary File Read via malicious archive deployment
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	anujha, aschwart, asoldano, aszczucz, bbaranow, bmaxwell, boliveir, brian.stansberry, bstansbe, darran.lofthouse, dhanak, dlofthou, dosoudil, drichtar, drosa, gmalinko, ibek, istudens, ivassile, iweiss, janstey, jrokos, kverlaen, mnovotny, mosmerov, mposolda, msvehla, nwallace, pberan, pdelbell, pesilva, pjindal, pmackay, rmartinc, rstancel, rstepani, sausingh, security-response-team, smaestri, ssilvert, sthorger, thjenkin, tom.jenkinson, vdosoudi, vmuzikar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in wildfly-core. A remote attacker, authenticated as a 'deployer' account, can import and deploy a malicious archive file from an untrusted source. This is achieved by leveraging WildFly libraries to craft a Java project that allows an HTTP POST request to upload and deploy the malicious archive. This could lead to further exploitation, such as arbitrary file read vulnerabilities.	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:
Deadline:	2026-07-29

Description OSIDB Bzimport 2026-01-22 03:19:10 UTC

A remote user authenticated as ‘deployer’ account can import and deploy a malicious
archive file from an untrusted source outside the intended control environment. In this
specific case, the attacker leveraged WildFly (open source) libraries to craft a Java project
that enabled them to perform an HTTP POST request to upload and deploy the malicious
archive file from the untrusted source. In this particular scenario, the archive file is a WAR
that contains a “read.jsp” page. Once the attacker uploads this file, they can leverage it to
exploit other vulnerabilities, such as Arbitrary File Read, as dimostrated in this case.

Comment 2 Darran Lofthouse 2026-01-22 11:17:32 UTC

This is not a vulnerability, this is the nature of an application server handling deployments.

The nature of deployments mean that they are bundles of code that will be executed by the application server process, as they are executed by the application server process these deployments have the same privileges as the user running the application server.

Deployments can only be deployed to the application server via the management interface or by directly copying it to the application server's directories.

Within our default out of the box configuration the management interfaces are configured to be accessible over the loopback address only and require authentication. The default configuration does not contain default users with remote access to the application server.

Additionally the application server provides a role based access control mechanism that can be enabled to restrict sensitive operations to users that have been granted specific roles.

As the report identifies the ability to deploy to the application server is effectively a high privilege as it enables new code to be deployed to the running process, however it is the responsibility of the administrator to update the configuration to meet their operational needs.

On updating the default configuration it is advisable to enable role based access control to enable authorization decisions to be applied to the management operations.
If opening up the management interfaces to be accessible over other interfaces other than the loopback address the administrator should consider how accessible this needs to be and consider other solutions such as firewall rules to restrict access to trusted networks only.
Finally the deployer role should only be granted to users who can be trusted with this responsibility and who will keep their credentials secure.

As described this issue would suggest an administrator has opened up access to the management interface to untrusted destinations and has granted the deployer role either to a user who can not be trusted or who has somehow leaked their credentials.