The First CVE I Found: CVE-2025-43720

Discovering and reporting a vulnerability seems to be a rite of passage for anyone in penetration testing or bug hunting. For me, that milestone came with CVE-2025-43720. While it didn’t end up being the high-severity flaw I first imagined, it taught me invaluable lessons about technical nuance, responsible disclosure, and the human side of cybersecurity.

What Is a CVE?

A CVE, or Common Vulnerabilities and Exposures, is a public identifier assigned to known cybersecurity flaws. Think of it as a shared language for the security community. Each CVE entry includes a unique ID (such as CVE-2023-1234), a description of the issue, and references to affected software and versions. It’s a cornerstone of penetration testing, enabling professionals to quickly map vulnerabilities to specific technologies.

Once you identify the software in use and its version, CVEs allow you to cross-reference known issues. From there, you might find a proof of concept (PoC), understand potential impact, and replicate the vulnerability to demonstrate risk to a client.

CVEs vary in severity—from critical issues like unauthenticated remote code execution (RCE) to lower-risk items such as information disclosure. While RCE often steals the spotlight, even a seemingly minor vulnerability can play a pivotal role in a chain of exploits.

The Bug I Found (and Misunderstood)

The vulnerability I discovered was in Headwind MDM, a mobile device management platform. During testing, I found that I could view what appeared to be the admin password while logged in as a low-level user.

Believing this to be the actual admin credential, I thought I’d uncovered a serious privilege escalation flaw. However, after responsibly disclosing the issue to the developer, I learned that I’d misinterpreted what I was seeing.

The “Admin” password was, in fact, a configuration password used in device profiles—not the application’s master admin credential. More importantly, this password was intended to be viewable by admin and user roles, but not by an observer. Since I was logged in as an observer, this was indeed a flaw—but not a critical one. As a result, the CVE’s severity was downgraded from high to low.

Responsible Disclosure in the Era of Bug Bounties

Bug bounty programmes have made it easier than ever for researchers to contribute to security, but they’ve also complicated things. With intense competition and limited payouts, some bug hunters now report issues outside of formal programmes—sometimes with heavy-handed demands for compensation.

I’ve been on the receiving end of such an approach, where a security researcher threatened my organisation for a reward. These types of interactions can feel intimidating, especially for companies unaccustomed to handling vulnerability disclosures.

That context made me especially cautious when reporting the Headwind MDM issue. I made it clear from the start that I wasn’t expecting any reward—I simply wanted to help secure the platform.

How I Reported the Bug

To ensure the developer had everything needed to validate and fix the issue, I:

• Set up a fresh instance of the latest version of the software

• Reproduced the issue in detail, capturing all HTTP requests and responses

• Documented the vulnerability thoroughly

• Sent the report to the best contact email I could find

To my relief, the developer responded professionally and appreciated the transparency. They confirmed that the issue stemmed from a permissions oversight and committed to a fix. After a short period of correspondence, a patched version of the software was released and the vulnerability was closed.

Lessons Learned

This first CVE taught me that:

• Technical accuracy matters: What looks like a serious flaw might not be what it seems.

• Communication is key: A respectful and well-documented report makes all the difference.

• Cold outreach can work: Not every company has a formal disclosure process, but that shouldn’t stop you from doing the right thing.

Above all, this experience gave me the confidence to approach future discoveries with clarity and professionalism. In fact, during my next assessment, I identified a critical vulnerability—and this time, I knew exactly how to handle it.

Want to learn more about Penetration Testing? Contact us...