Subject: Request updated FNMS Docker Monitor binary built with Go 1.25.7+ (CVE‑2025‑68121)

Hello Team,

Our security scanner (Prisma Compute) detected that the FNMS Docker Monitor component:

C:\Program Files (x86)\ManageSoft\Container\fnms-docker-monitor.exe

is built with Go

crypto/tls

version 1.25.3, which is vulnerable to CVE‑2025‑68121.

According to the Go project, the vulnerability is fixed only in:

• Go 1.24.13
• Go 1.25.7
• Go 1.26.0‑rc.3

Can you please provide the latest FNMS Container Monitor / Inventory Agent installer or updated

fnms-docker-monitor.exe

built with Go 1.25.7 or later, so we can apply the remediation?

Hello Team

I have some concern about the following point and I need an argent replay please:

-Does SVM detect configuration vulnerabilities based on CIS benchmarks?!

-Does SVM integrate with other asset management tools and CMDB?!

-Does SVM can generate system logs to SIEM solution?!

Please Advise.

Thanks, Regards

Your attention is called to this blog post for how SVR and SVM can help you deal with Log4j .

SVM focuses exclusively on assessing known vulnerable software versions. It uses file signatures to determine the presence of known vulnerable software versions and matches that with research and patches to help you identify and remediate such. So, if Log4j is installed on a system, we will detect it, but that is not typically how Log4j is distributed—rather it is included as a component of another third-party application. In such a case, it will be identified as vulnerable if/when the software including it is disclosed as vulnerable, we write an advisory, and create a file signature to detect it.

That said, we are prioritizing a potential product enhancement that would allow SVM to provide an awareness report to identify specific components like Log4j embedded within your installed software. This would be a new use case for SVM as it would help provide awareness, but you would not be able to remediate it by patching as SVM is traditionally leveraged. This is due to the fact that the product bundling the component is what needs to be patched, so this would be a new reporting-focused use case versus a patch-focused one. Actually patching a vulnerable component will continue to require targeting the application that is shipping the component, versus the component itself.