Do we have to worry about Xalan

[Marcin Noworzyń]

Is Wildfly safe having in mind the new CVE-2022-34169?
Right now there is no errata for JBoss:
https://access.redhat.com/security/cve/CVE-2022-34169

There is a new ticket for Xalan but I think there will be no fix:
https://issues.apache.org/jira/browse/XALANJ-2636

There is an unresolved old request to remove Xalan from Wildfly:
https://issues.redhat.com/browse/WFLY-4704

Does anyone know if this vulnerability affects Wildfly 21/26?

Thanks and regards,
Marcin Noworzyn

[Brian Stansberry]

Thank you very much, Marcin, for raising this issue.

It's true there is no errata for JBoss EAP for CVE-2022-34169.  The problematic code in the xalan-j 2.7.1-jbossorg-5 jar that WildFly uses is not present in the 2.7.1.redhat-00013 release that EAP uses.  That code comes into the artifact WildFly uses via the shading in of BCEL.jar in https://github.com/jboss/xalan-j/tree/jboss_2_7_1/lib.  The redhat-xxxx builds do not shade that jar in.

So, WildFly is vulnerable to this, in that we ship the problematic code. Normal use of WildFly does not require the problematic code, which mitigates the risk.

I've filed https://issues.redhat.com/browse/WFLY-16771 and https://issues.redhat.com/browse/WFLY-16773 to track getting this fixed in WildFly 26.1.2 and WildFly 27.

https://github.com/openjdk/jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc shows the fix that was made in OpenJDK 8 for this; in our case I think we'll just drop the BCEL.jar from the jbossorg artifact so the class won't even be present.

Best regards,

Brian Stansberry

Project Lead, WildFly

[Marcin Noworzyń]

Thank you Brian for the great answer. I appreciate there are issues filled to track WildFly's and already a pull request! Waiting for fixed versions.

Best regards,

Marcin Noworzyń