Bump shaded netty to 4.1.115.Final in micrometer-registry-statsd to address CVE-2024-47535

[rkuijt-mollie]

Mitigates GHSA-xq3w-v528-46rv in Netty dependency.

[pivotal-cla]

@rkuijt-mollie Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[rkuijt-mollie]

Not signing the CLA as this change is minor enough.

[jonatan-ivanov]

We have automation around this, this will be upgraded automatically before the next release.
Could you please tell us through which dependency did you bump into this?

[krishnatippur]

I am running into a vulnerability check failure w.r.t. CVE-2024-47535 when pulling in micrometer-registry-statsd dependency.

@jonatan-ivanov , you mentioned this will be upgraded automatically before the next release - what is the ETA for the next release?

[jonatan-ivanov]

It is scheduled for December 9th, see the calendar: https://spring.io/projects#release-calendar
Does that work for you?

[krishnatippur]

Thanks for that link. I would like this to be done sooner, since https://access.redhat.com/security/cve/cve-2024-47535 is a medium severity vulnerability. Otherwise until December 9th, our internal vulnerability scanners will need to be updated for exceptions per asset, and we have several hundreds of them :(

Perhaps a patch/minor release in the meantime? Would that be possible?

[shakuzen]

I would like this to be done sooner, since https://access.redhat.com/security/cve/cve-2024-47535 is a medium severity vulnerability.

In case it isn't clear to anyone, if you are not running your production apps on Windows, this CVE is a false positive for you (even if you are running Windows in production, an attacker needs to be able to create a file on the system where the app is running). Vulnerability scanners should be more sophisticated and organizations need processes in place to consider such context. This is creating more work for everyone to solve a problem that doesn't exist for a vast majority of users.

We can do an earlier release, but I don't think it's a reasonable expectation that we do so for false positive CVEs. We get reports like this with some frequency and they're consistently false positives. We can do a release in this case because we may have some users running on Windows in production, but I expect that is a vanishingly small number of our users.

[krishnatippur]

I would like this to be done sooner, since https://access.redhat.com/security/cve/cve-2024-47535 is a medium severity vulnerability.

In case it isn't clear to anyone, if you are not running your production apps on Windows, this CVE is a false positive for you (even if you are running Windows in production, an attacker needs to be able to create a file on the system where the app is running). Vulnerability scanners should be more sophisticated and organizations need processes in place to consider such context. This is creating more work for everyone to solve a problem that doesn't exist for a vast majority of users.

We can do an earlier release, but I don't think it's a reasonable expectation that we do so for false positive CVEs. We get reports like this with some frequency and they're consistently false positives. We can do a release in this case because we may have some users running on Windows in production, but I expect that is a vanishingly small number of our users.

I agree that our org's vulnerability scanners can/should be smarter. False positives like this derail us all, so I appreciate you taking this up off-cycle. Thank you!

[shakuzen]

Micrometer 1.12.13, 1.13.8, and 1.14.1 with this upgrade have been released and should be available from Maven Central shortly.