Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-40152 affecting com.fasterxml.woodstox:woodstox-core #397

Open
ron-ak-p opened this issue Mar 14, 2023 · 3 comments
Open

CVE-2022-40152 affecting com.fasterxml.woodstox:woodstox-core #397

ron-ak-p opened this issue Mar 14, 2023 · 3 comments

Comments

@ron-ak-p
Copy link

CVE-2022-40152 is a vulnerability affecting com.fasterxml.woodstox:woodstox-core, which is a transitive dependency of java-saml via org.apache.santuario:xmlsec. Requesting that you upgrade the dependency org.apache.santuario:xmlsec to 3.0.2+ or 2.3.3+ when they are released. It appears both will include upgraded versions of woodstox-core in which this vulnerability is fixed. Thank you!

@pitbulk
Copy link
Contributor

pitbulk commented May 12, 2023

Noted

@MioG777829
Copy link

Adding interest in this update. Snyk has assigned another XML External Entity (XXE) Injection vulnerability with no CVE number, in com.fasterxml.woodstox:woodstox-core < 5.3.0, the rating of 9.4 out of 10.
https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLWOODSTOX-2928754

@veselov
Copy link

veselov commented Jun 15, 2024

As far as these things go in my experience, it's not particularly possible to wait until all maintainers of my project(s) direct dependencies update theirs, which will require a constant stream of patch releases, and I don't think is a reasonable burden to expect each maintainer to take on. In addition, different direct dependencies will have various versions of the same transitive dependency anyway.
I gave up on this expectation long time ago. The only way is to maintain one's own manifest with all dependencies that have been affected by a vulnerability at least once, using POM's dependencyManagement support. I will need to provide an update to my (deployable somewhere/exposed to the internet) application a lot faster than waiting for each dependency to update theirs, and I can't just say "no, I can't patch this vulnerability because so and so maintainer hasn't updated their library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants