Getting a CVE ID (Common Vulnerabilities and Exposures) assigned to your name is a significant milestone in cybersecurity. It reflects meaningful contribution to the security ecosystem.
However, let’s set expectations clearly:Finding a vulnerability in well-maintained, reputed software, tools and repo's is somewhat difficult. It often requires deep research, time, reverse engineering, and persistence.
This guide is not about claiming that obtaining a CVE is easy. Instead, this blog explains how to start responsibly, understand the process, and navigate the path toward legitimate CVE registration. We have specifically targeted web-based applications for the guide.
Understanding CVE & CVE ID
CVE stands for Common Vulnerabilities and Exposures, a standardized dictionary of publicly known cybersecurity weaknesses in software or hardware. Each CVE is assigned a unique ID (e.g., CVE-2023-12345) for consistent identification, tracking, and communication across the cybersecurity community to improve vulnerability management.
Please keep in mind through out the guide that identifying CVE is not a trophy for display, a quick win or a guarantee you are extremely good in testing. It is a way to contribute to global vulnerability tracking and also to understand the CVE registration process.
Selecting the Right Target
Your first step is choosing a product or application responsibly.
Option 1: Actively Maintained Open Source Projects
In this option we can look for:
- Actively maintained GitHub repositories
- Open-source web applications
- Projects with issue tracking enabled
- Clear disclosure or security policy
Steps to be followed:
Step 1: Clone the repo
Step 2: Host it internally
Step 3: Test in a controlled environment. This gives you full freedom for deep analysis.
Option 2: Public Source Code Platforms (e.g., Campcodes)
This would be our recommendation from the three options provided in our blog. Some platforms distribute free source code applications. These are often:
- Web-based PHP / Node.js / Python apps
- Educational or demo systems
- Often less security hardened
These are useful for:
- Learning vulnerability discovery
- Understanding insecure patterns
- Practicing responsible disclosure
Option 3: Study Recent Submissions on VulnDB
One strategic way to understand the ecosystem is to monitor recent vulnerability disclosures on VulnDB. There might be questions as to why specifically VulnDB, the reasons are mentioned below for better understanding.
- Transparent recent submissions
- Shows severity assigned
- Displays whether submissions are accepted or rejected
- Shows product/vendor information
- Helps identify trending vulnerable products
By reviewing recent entries, you can Understand what types of vulnerabilities are being accepted, See reporting structure and language, Identify potential products to review and also main point is to Avoid submitting duplicates.
Approaches to Finding Vulnerabilities
Approach 1: Manual Security Assessment
This includes testing for OWASP Top 10 testcases like Injection Based Attacks, Privilege Escalations, Broken Access Control vulnerabilities, Business Logic Vulnerabilities etc. Manual testing provides:
- Deeper understanding
- Higher impact findings
- Less false positives
- Stronger CVE eligibility
After finding a vulnerability:
- Document clear replication steps
- Capture screenshots
- Include affected versions
- Provide proof of concept
The next step includes submission of vulnerabilities through VulnDB.
Approach 2: Smart Automation + Manual Verification
Automation does not replace research it might accelerates it. You can use open-source SAST and security tools such as:
- Semgrep
- TruffleHog
- Bandit
- VisualCodeGrepper
These tools help identify:
- Hardcoded secrets
- Dangerous functions
- Insecure deserialization
- Weak crypto usage
- Unsafe eval usage
- Debug endpoints
- Default credentials
- Insecure file handling
- Injection Based Vulnerabilities
However, Automated findings must always be manually validated. A scanner finding alone does not guarantee CVE acceptance. The recommended workflow:
- Run static analysis
- Identify suspicious code patterns
- Manually test exploitability
- Confirm impact
- Document responsibly
Avoiding Duplicate Submissions
Identifying a vulnerability is good however, it is always suggested to check the vulnerability submission before documenting and submitting from your side. Would recommend the below checklist before submitting:
- Check if the issue already exists
- Search existing CVEs
- Search GitHub issues
- Search VulnDB entries
- Check vendor advisories
Duplicate submissions are usually rejected. VulnDB typically responds within 4–5 business days. If the submission is found to be unique and valid, they will respond with a CVE assigned and the vulnerability will be cataloged publicly. Readers can refer to the screenshots below to visualize how it looks once a vulnerability is accepted and published.
Writing a Proper Submission
Once a vulnerability is identified, checked for its existence and decided for a new submission. The submission document should include:
- Product Information
- Vulnerability Type
- Technical Description
- Steps to Reproduce
- Impact Analysis
- Proof of Concept
Realistic Expectations & Ethical Responsibility
Let’s be honest, Getting CVEs in widely used CMS, Enterprise products, Mature frameworks, Actively security-reviewed systems is difficult and deserves recognition. It may require weeks of research, Deep code analysis, Reverse engineering, Chaining multiple bugs etc. However, starting with smaller or less-reviewed open-source projects builds confidence, teaches responsible disclosure, Improves technical ability and prepares you mentally for bigger targets.
Ethical Responsibilities:
- Avoid exploiting production systems without permission
- Test locally whenever possible
- Respect disclosure timelines
- Coordinate with maintainers
- Avoid public disclosure before resolution
Always remember Responsible disclosure builds reputation, Irresponsible disclosure damages it.
CVE hunting is not a shortcut to recognition, it is a discipline built on patience, technical depth, and responsible conduct. While this guide explains a structured and practical way to begin your journey toward obtaining a CVE, remember that meaningful vulnerability discovery requires more than running tools. It demands understanding how applications are built, how they fail, and how those failures translate into real-world security impact.
Starting with open-source or lesser-reviewed web applications allows you to Build confidence, Develop strong documentation, habits, Understand disclosure workflows, Learn how vulnerability validation works in practice.
Over time, as your technical maturity grows, so will the complexity and quality of the issues you identify. Whether your first submission is accepted or rejected, each attempt strengthens your research skills. Rejections refine your methodology. Accepted submissions validate your effort, Both are part of the process. Approach CVE research with integrity, persistence, and professionalism, and you won’t just collect CVE IDs, you’ll build credibility within the security community.
The goal is not to “get a CVE quickly.”
The goal is to contribute meaningfully to the security ecosystem.
Start responsibly. Research thoroughly. Report professionally.
Leave a Reply