Background

In the software vulnerability world that we live in, a common activity is to keep an eye on the public discussions of vulnerabilities, investigate them, and also determine how the vulnerability was discovered in the first place. While there are some infosec rockstars out there who can seemingly derive vulnerabilities from thin air, the common answer is that vulnerabilities are often found by using specific tools, combined with a curious mindset. Yes, a good number of the vulnerabilities that we’ve discovered are due to not much more than noticing unexpected behaviors and pulling those threads.

CVE-2025-13176 in ESET Inspect Connector

In this particular case, we were investigating a vulnerability write-up about ESET Inspect Connector (CVE-2025-13176). One of the screenshots from this report is a Process Monitor log that shows the attempt of a privileged process to load an openssl.cnf file from a path that an unprivileged can influence. 

For reasons we cannot fathom, Microsoft Windows allows unprivileged users to create directories off of the C:\ root. As such, an unprivileged Windows user can create the C:\src\vpkg\packages\openssl_x64-windows-static\ directory to place their own openssl.cnf file. When the openssl library processes this file, it may attempt to load specified libraries. This can allow for privilege escalation when the library code is executed with the privileges of the hosting process. CVE-2025-13176 is a typical Windows Local Privilege Escalation (LPE) vulnerability that occurs by processing an openssl.cnf file.

Crassus

The openssl.cnf LPE primitive is common enough on the Windows platform, so I explicitly added it to the Crassus LPE-finding tool. So obviously, we were curious to see if this vulnerability could indeed have been just one of the many Crassus findings. After installing the vulnerable version of the software, we check the Process Monitor log file with Crassus:

Oh. Yes, Crassus did indeed find CVE-2025-13176 with zero effort whatsoever. However, it found what appears to be additional vulnerabilities in the form of noticing the attempt to load several DLL files in the c:\programdata\eset\inspect connector\modules directory, which can be written to by an unprivileged Windows user. Did perhaps ESET fix this as well without assigning a CVE to it? Time to test the latest version of the ESET Inspect Connector software…

Oh. Well, this seems like a problem. Though Crassus results themselves aren’t enough to prove that software is vulnerable. Let’s run that build.bat file in the Crassus stubs directory to build these DLL files that will simply launch calc.exe. Then we can reboot the system with a Process Monitor boot log enabled to see what happens.

The proof of the pudding is in the tasting, and we have some tasty pudding here. Being the ethical people that we are, it’s time to report this to the vendor.

Vendor response

After 38 days, I received the following from ESET:

Dear Reporter,

We had internal discussion about mentioned behavior.

We can confirm that there is possibility to write to the path where component EI connector run. Unfortunately component is related to the another product where all self defense is configured and EI connector just inherit configuration and also self defense.

Please also note that in case that you want to install EI connector admin permissions are required.

Currently it is not possible to improve behavior.

For this reason report will be rejected.

Thank you very much for understanding.

Best Regards,

ESET Security Team

To be honest, I lack the ability to parse “component is related to the another product where all self defense is configured.” I have a machine with the software in question installed, and the screenshot above demonstrating the launch of calc.exe was not faked.

We understand that we live in a world where security researchers are probably bombarding vendors with AI-generated reports, and presumably said vendors are using AI to filter out the flood of incoming reports. However, this doesn’t excuse the dismissive behavior from a number of vendors that we’ve worked with.

Here we have a case where a security researcher wanted to do the right thing and ensure that the vendor was able to correct the vulnerability. But rather than ask questions or interact with the reporter, the vendor simply closed the case. And as such, this information is being published here for the world to see.

To the software vendors of the world, We implore you to treat vulnerability researchers with the respect that you would like to be treated with. The consequences of an upset researcher are perhaps not worth the time that you save by closing a case and moving on to the next one.

To the vulnerability researchers out there, please do continue to report vulnerabilities you find to the vendors. The world is a better place with software that is more secure. And while you’re at it, go ahead and give Crassus a shot if you want to try easily finding your own LPE vulnerabilities. 

Happy bug hunting!