In this blog post, I will take you through my personal journey of identifying a vulnerability, navigating the ethical considerations of reporting it, and the intricate process leading to my work being recognized with a CVE identifier. Join me as I share insights from this experience, aiming to illuminate the path for those interested in the field of information security, and to highlight the pivotal role of CVEs in our digital era.
Information security stands as a crucial barrier against digital threats in the ever-evolving world of technology. Among the many facets of this field, the concept of Common Vulnerabilities and Exposures (CVE) is essential in understanding and managing information security risks. But what exactly are CVEs, and why do they matter? This is the story of my journey into the intricate world of information security, leading to the moment I received my first CVE identifier – a milestone that symbolizes both an achievement and a responsibility.
What is a CVE—and Why Does It Matter?
Information security is like a continuous chess game, where defenders and attackers consistently adapt their strategies. In this digital contest, vulnerabilities – flaws or weaknesses in a system – can be exploited to cause harm. This is where CVEs become crucial. A CVE is a publicly disclosed record identifying and cataloging vulnerabilities in software or hardware. Each CVE is unique, serving as a reference for the information security community to discuss, analyze, and address specific vulnerabilities.
The importance of CVEs extends beyond just cataloging. They are pivotal for information security professionals to communicate about specific threats, coordinate defense strategies, and develop patches or fixes. More broadly, CVEs help organizations and individuals understand their exposure to risk and prioritize their security measures accordingly.
Discovering a CVE is not merely about finding a system flaw; it’s about contributing to the collective effort of making the digital world safer. It involves a meticulous attention to detail, a profound understanding of system interactions, and a steadfast commitment to ethical practices. Reporting a CVE is a process governed by responsibility – it’s about ensuring that the information is used constructively to strengthen defenses, not for exploitation.
My Journey and Discovery
My cybersecurity journey began about 5 years when I joined Team Viris after completing my studies in informatics. Like many in the field, I spent learning through platforms Hack the Box and a few others. From early on, my focus gravitated towards Windows and Active Directory related vulnerabilities.
The vulnerability that became the CVE was discovered during the penetration test for a customer in a privilege escalation phase of the test for a newly deployed environment. I went through the standard procedure of privilege escalation which means discovering potentially vulnerable programs and services among things such as PATH variable abuse and DLL hijacking that are better described in a bit older blog post https://fuzzysecurity.com/tutorials/16.html. During that process a potentially vulnerable service was discovered which was then reported to customer and we’ve discussed the possibility of reporting the issue to the IBM since it was their product.
Responsible Disclosure
Discovering a vulnerability comes with responsibility. Ethical reporting is not only about finding security flaws, but also about handling them in a way that keeps people and systems safe. Researchers should avoid sharing details publicly before a fix is available or using the vulnerability for personal benefit. Instead, the issue should be reported privately to the affected organization, so they have time to investigate and release a patch. Good communication and a respectful, cooperative approach are important throughout the process.
Sometimes organizations may not respond or cooperate as expected. Even then, researchers should continue acting responsibly and, if necessary, seek support from mediators such as CERT organizations. Sharing experiences and lessons learned, without exposing sensitive details, can also help educate others and strengthen the security community.
For aspiring security researchers, technical skills are only one part of the journey. Continuous learning, hands-on practice, curiosity, and persistence all play an important role in a field that changes every day. At the same time, acting ethically, communicating clearly, and learning from the wider security community are what truly help someone grow into a trusted security professional.
I reported the vulnerability via the HackerOne platform, which I chose for the possibility of more effective communication with the organization. The process took longer than I expected, but this is understandable for larger organizations.
The reporting timeline looked like this:
June 9, 2023 – report submitted via HackerOne
June 12, 2023 – report reviewed by HackerOne and forwarded to IBM
August 31, 2023 – inquired about the status of the report
September 1, 2023 – received a response that they would check on the status
September 14, 2023 – patch issued, patch page published
October 4, 2023 – added acknowledgment of the vulnerability researcher
October 5, 2023 – IBM decided not to disclose the report
With the HackerOne platform, communication was simplified, as I didn’t have to worry about the security of the communication channel itself, such as encrypting the message. Additionally, the platform served as a mediator that simplified the process on both sides.
Recognition
Receiving my first CVE identifier was a really rewarding moment. Not because of the title itself, but because it felt like confirmation that the time, patience, and careful research had made a difference and helped improve security in a meaningful way.
Like many researchers, I had reported issues before that ended up being configuration mistakes, false positives, or findings that simply could not be reproduced. That is a normal part of the process. Vulnerability research often means hitting dead ends, testing the same things repeatedly, and learning through trial and error.
This time, though, everything came together — from the initial discovery and validation to responsible disclosure and, eventually, official recognition.
Link to the CVE details:
https://www.ibm.com/support/pages/node/7031707
Franci Šacer