Thanks for raising this. We appreciate people keeping an eye on Openfire’s dependencies.
As far as we can tell, Openfire is not affected by CVE-2025-58056: According to the Netty advisory (GHSA-fghv-69vj-qj49), the issue was fixed in 4.2.5.Final. The 4.2.16.Final version that Openfire currently uses should already include that fix.
Perhaps a different CVE was intended, since Netty 4.2.17.Final did address several other issues? It’s also common for scanning tools to match affected versions incorrectly. If you can tell us which finding you’re working from, we’re happy to take another look.
As for your more general question: yes, we try to keep our dependencies current, and Netty updates are part of our regular release work.
A wider note, offered in a constructive spirit: Openfire is run by a small group of volunteers. A report like this takes real time to triage. We have to find the advisory, check the affected version ranges, and work out whether the vulnerable code is even reachable in Openfire. That time comes from the same limited pool we use for fixing bugs and building features. As this report shows, sometimes that work ends with “not affected.”
This is becoming increasingly pressing. With the rise of AI-assisted tooling, we’re receiving more and more security-related reports, and the triage workload is rising with them. We’re glad to keep improving the project, and we take security seriously. But most of this work is unpaid.
Organizations that build on Openfire have the most to gain from it staying healthy, and they’re also best placed to help. We’d love to see more of them take that step. Here are some ways to do so:
- An initial assessment. Include links to the advisory, the affected version ranges, and, if you can, whether Openfire uses the affected module or code path. This turns a research task into a quick review.
- Pull requests. A dependency bump is often a one-line change, and we’re happy to review it.
- Testing. Running pre-release builds in your environment and reporting back is very valuable to us.
- Private reporting. For anything that might really be exploitable, please use our security reporting process rather than the public forum.
- Commercial support. If your organization needs formal answers, assessments, or timelines for its own compliance processes, paid support or sponsorship is a good fit for that, and it directly supports the people doing this work.
One small request as well: this forum is public, so we’d ask that “critical” be reserved for issues confirmed to affect Openfire. Other users read these titles, and a misplaced one can cause unnecessary alarm.
Thanks again, and we hope to see you around!