Neko 2.63.x patch to fix CVE-2024-23635 finding from dependent library

[DawidSobierajski]

Hello,

I am currently using a library A which is dependent on other artifact B that uses htmlunit-neko 2.63.0 as a dependency and for this version my sonar instance reports CVE-2024-23635. The description of a CVE says that it is caused by scanStartElement and scanEndElement functions. The vulnerability was fixed with 3.11.0 version which introduced scanTagName function in place of scanName in both scanStartElement and scanEndElement.

Unfortunately, changing neko version is impossible due to differences between 2.63.0 and 3.11.0 versions and it causes various incompatibility errors, for example

org.apache.xerces.xni.XMLAttributes cannot be converted to org.htmlunit.cyberneko.xerces.xni.XMLAttributes

and so on...

Would it be possible to create patched version of 2.63.x, in that case it would be 2.63.1 with changes that I already prepared on my fork: https://github.com/DawidSobierajski/htmlunit-neko/tree/2_63_1
Diff: https://github.com/HtmlUnit/htmlunit-neko/compare/2.63.0...DawidSobierajski:htmlunit-neko:2_63_1?expand=1
Commit used for back porting: 55053e4

Thank you

[rbri]

Hi Dawid,

valid point.
There was a major change form 2.67 to 2.68 due to the intergration of xerces (to mitigate other CSV's).
At least you should be able to update to 2.67 without any problems. But this will not solve you CSV... :-D

From you description and the LinkedIn profile (hope i found the right one https://www.linkedin.com/in/dawidsobierajski/) i guess you use neko in a business context. And getting support like this is exactly the reason why I think all the companies using open source should sponsor for the maintenance of open source projects.

Therefore let us try the following:

• I will have a look at you branch and some other things to prepare a hotfix release, maybe we should backport some other fixes also
• You check if you can jump to version 2.67.0 without any compatibility issues
• If you really use neko in your company context, please clarify if sponsoring for this task or for the ongoing maintenance of the lib is an option
• we can connect on linkedin, for a one to one connection

[rbri]

hava started the branch 2_67_maintenance

[rbri]

@DawidSobierajski - any progress at your side?