CVE-2023-26119(9.8) on neko-htmlunit-2.66.0.jar dependency

[dmitry-weirdo]

Starting at around 10.Apr.2023, the following started to fail on the Java project:

[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0': 
[ERROR] 
[ERROR] neko-htmlunit-2.66.0.jar: CVE-2023-26119(9.8)

This dependency comes from the latest esapi.jar

+- org.owasp.esapi:esapi:jar:2.5.1.0:compile
|  +- xom:xom:jar:1.3.8:compile
|  +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
|  |  +- commons-logging:commons-logging:jar:1.2:compile
|  |  \- commons-collections:commons-collections:jar:3.2.2:compile
|  +- commons-configuration:commons-configuration:jar:1.10:compile
|  +- commons-lang:commons-lang:jar:2.6:compile
|  +- org.apache.commons:commons-collections4:jar:4.4:compile
|  +- org.apache-extras.beanshell:bsh:jar:2.0b6:compile
|  +- org.owasp.antisamy:antisamy:jar:1.7.2:compile
|  |  +- net.sourceforge.htmlunit:neko-htmlunit:jar:2.66.0:compile
|  |  +- org.apache.xmlgraphics:batik-css:jar:1.16:compile
|  |  |  +- org.apache.xmlgraphics:batik-shared-resources:jar:1.16:compile
|  |  |  +- org.apache.xmlgraphics:batik-util:jar:1.16:compile
|  |  |  |  +- org.apache.xmlgraphics:batik-constants:jar:1.16:compile
|  |  |  |  \- org.apache.xmlgraphics:batik-i18n:jar:1.16:compile
|  |  |  \- org.apache.xmlgraphics:xmlgraphics-commons:jar:2.7:compile
|  |  +- xerces:xercesImpl:jar:2.12.2:compile
|  |  \- xml-apis:xml-apis-ext:jar:1.3.04:compile
|  \- xml-apis:xml-apis:jar:1.4.01:compile

The ticket in antisamy — nahsra/antisamy#321
The ticket in neko-htmlunit — HtmlUnit/htmlunit-neko#20

[jeremiahjstacey]

The dependency tree listed is for the artifact created from the ESAPI/esapi-java-legacy baseline, which is a different repository.

https://github.com/ESAPI/esapi-java-legacy/

Per the tree you've listed, please note that nekohtml is a dependency of antisamy, not of the ESAPI project.

|  +- org.owasp.antisamy:antisamy:jar:1.7.2:compile
|  |  +- net.sourceforge.htmlunit:neko-htmlunit:jar:2.66.0:compile

The Antisamy team is very responsive to CVE's in the project, but if you'd like to ensure they are aware please follow up with them in the Antisamy github project.

https://github.com/nahsra/antisamy

Worth noting that this dependency is already updated in the development baseline to v 2.70.0
https://github.com/nahsra/antisamy/blob/main/pom.xml

ESAPI is currently using the latest released version of antisamy. Until a new version of Antisamy is available there is no additional action that can be taken by the ESAPI team.

[kwwall]

This is already on the AntiSamy folks' GitHub issues and I've been working with their team for the past day and a half or so. We can't do anything until they upgrade and since this is a major revision (2.70.0 --> 3.0.0) there are LOTS of interface changes so it may take a while. If you are not using any of the HTTPUtilities.getSafeValidInput methods, it shouldn't affect you as I think that is the only place we use AntiSamy.

[kwwall]

Also, be careful when creating issues. This should have been on ESAPI/esapi-java-legacy not ESAPI/esapi.

[rbri]

Have done some work on the AntiSamy update - the update itself is not that tricky but there was a regression on neko 3.0.0 that introduces some problems. Will make a fresh snapshot build of Neko 3.1.0 and a PR for the needed updates. If the team is happy with this i will make a release.

[kwwall]

Have done some work on the AntiSamy update - the update itself is not that tricky but there was a regression on neko 3.0.0 that introduces some problems. Will make a fresh snapshot build of Neko 3.1.0 and a PR for the needed updates. If the team is happy with this i will make a release.

AntiSamy PR 322 for those of you are are wondering and not watching the AntiSamy repo.

[rbri]

3.1.0 release is available.

[kwwall]

Patched in ESAPI/esapi-java-legacy for a pom update to use AntiSamy 1.7.3 which addresses this. Fixed in commit id ESAPI/esapi-java-legacy@e69430e of PR ESAPI/esapi-java-legacy#784.

Thanks to @rbri and @davewichers for attending to this so promptly.