Entrinsik Informer Username Enumeration – CVE-2025-65185

User enumeration is a common vulnerability found across many applications; however, it is typically missed by automated testing and only discovered with hands on keyboard testing.  During an external penetration test, Triaxiom performs a series of automated scans for both discovery purposes (port mapping, discovery of assets, etc.), and vulnerability enumeration. Once those are complete, in scope hosts are reviewed manually for additional attack surface mapping. In particular, login portals are of great interest to any attacker, and typically go through several rounds of testing, one the first of which is testing for username enumeration.

During a recent external penetration test, Triaxiom Security discovered a username enumeration vulnerability in the Entrinsik Informer version 5.10.1 platform. While researching the platform, Triaxiom noted this vulnerability had not been discovered/reported before, and submitted a request for a CVE. To Read more about the responsible disclosure process see CVEs and Responsible Disclosures: What are they? By Triaxiom’s Penetration Testing Manager, Matt Schmidt.

Why Username Enumeration Important

Username enumeration is an important discovery for several reasons. First, being able to obtain a list of valid users allows for more accurate password spraying attacks. Second, it’s possible these usernames apply elsewhere in the in-scope environment. Just as mapping the attack surface gives a better understanding of the in scope hosts, mapping users to applications gives a better understanding of how those users operate within the environment.

Proof of Concept

For this engagement, Triaxiom noted that the application had a standard login screen, with the typical options for a forgotten password:

Once the user selects Forgot password, they are prompted to enter a username, then click the “Send Link” button:

From here the application prompts the user for a code, presumably sent via email. Triaxiom noted that any code could be entered here and that regardless of the username and code, the application would always prompt the user for a new password:

Interestingly, the application responds with two very different errors depending on whether the user is valid or not. Using the admin user for example, the application states the password cannot be changed because of an incorrect code:

However, when a known non-existent user is submitted, the application states the password cannot be changed because of a “Not Found” error:

From here Triaxiom reviewed the server requests and responses and noted that the attack could be automated via a post request made to the /api/change-password endpoint, then using a tool like Burp Suite’s intruder to compare error codes. Note, here a password change is attempted on the admin account:

This results in a 422 Processable Entry error and a verbose message stating the  code was not correct:

When a known non-existent user is submitted, the error results in 404, not found:

Remediation

The fix for such an issue is to have the application respond in a generic manner. The response of the Forgot Password function should not give an indication whether the account is valid or not. For example, have the application state “An email has been sent with password reset instructions. If you do not receive an email within 5 minutes please try again.” For the Login function, if found to be vulnerable, respond with a generic error message that does not disclose the validity of the username, such as “Invalid credentials.” Lastly, responses for valid and invalid accounts should be studied to ensure that timing and size does not give away valid usernames. In the case above a clear error message states the user cannot be found, however, Triaxiom often finds username enumeration via timing issues, or a discrepancy in size between valid and invalid users via application responses. While it’s possible some legitimate users become frustrated with a less verbose error message, the tradeoff for security outweighs the need to inform anyone of the validity of a user account.

Responsible Disclosure

Triaxiom notified the vendor of the issue via the vendor’s contact email when this vulnerability was initially discovered but did not get a response back. Subsequent follow-ups were sent, but again there was no response. This vulnerability was discovered during an authorized penetration test of a Triaxiom client, and the vendor was contacted in good faith, without expectation of payment of or other monetary reward.