Reporting Vulnerabilities

Software vulnerabilities are a fact of life. They happen. Some are unforgivable and trivial to exploit, others a more obscure or difficult to exploit. Some have a limited impact, others can have catastrophic consequences. Regardless, reporting them helps keep systems and data safe.

This post gets through the process end-to-end:

1. Write a report
2. Responsibly disclose it to the vendor
3. Get a CVE ID and write a Common Vulnerabilities and Exposures (CVE) report
4. Brag about it. Publish the details publicly

Things don’t always happen in this exact order.

For example, the problem might have been identified in a forum (public or on the dark web), before any report has been written. This could lead to a CVE being filed in even before many details or any report has been produced. But at least there is something.

Or, someone wanted to brag about it, and didn’t follow any responsible disclosure and simply posted a report online.

Or, it has never been disclosed and is used in the wild.

Or, it has been reported to the vendor, but they did nothing about it within the agreed timeframe (usually 30 days, sometimes more for vulnerabilities that are more difficult to fix)

And many other scenarios.

Oh, and I’ll finish with some best practices as well.

Write a report

Well, first, check to ensure this hasn’t been found already by searching CVE databases, the vendor’s site, etc. If you can’t find anything, you’re onto something.

A well-written vulnerability report is crucial for helping vendors understand, validate, and fix security issues. This will be a good basis for them to review your findings, confirm them, and submit a CVE.

• Clear Title

  Provide a concise description that identifies the vulnerability type and affected component

  CVE.org's Key Details Phrasing suggests using:

  1️⃣ [VULNTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR].

  For example: “A SQL Injection vulnerability was found in /admin/forgot-password.php in Phpgurukul Land Record System v1.0, which allows remote attackers to execute arbitrary code via the contactno POST request parameter.” (CVE-2025-25389)

  Alternatively,

  2️⃣ [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] [ROOT CAUSE], which allows [ATTACKER] to [IMPACT] via [VECTOR].

  For example: “PHPGurukul Daily Expense Tracker System v1.1 is vulnerable to SQL Injection in /dets/add-expense.php via the date expense parameter.” (CVE-2025-25351)

• Executive Summary

  Brief overview of the vulnerability, its impact, and potential risks.

• Impact Assessment

  Description of potential consequences if exploited. A report should try to define the severity (e.g., High, Critical) and the potential impact (e.g., remote code execution, data exfiltration).

  This can be, and probably should be, done using CVSS (see Calculating CVSS Scores below).

  When assessing the impact of a library vulnerability without knowing how it will be used, we should assume reasonable worst-case scenarios and document these assumptions in the report. Products using this library will need to conduct an impact analysis for their own usage/implementation.

• Technical Description

  Detailed explanation of the vulnerability, including:

  • Affected versions/configurations

    Specify any configuration/settings that are required to be in place for the vulnerability to be exploitable. Ideally, this should also clarify whether this is the default configuration or not (this information can also be provided under the attack details).

  • Attack details

    Provide details on

    • Attack vector (e.g., network, local)
    • Attack complexity
    • Prerequisites for attack to be possible
    • Required privileges
    • User interaction requirements

  • Root Cause

    Common Weakness Enumeration (CWE) is a community-developed list of weaknesses that can be used to easily represent the root cause. This allows some classification and reporting.

  • Impact

    Describe the impact on

    • Data confidentiality and integrity
    • System availability

  • Step-by-step reproduction steps

    Provide detailed steps to reproduce, ideally with code snippets and screenshots.

  • Proof of concept code (if applicable)

• Mitigation Recommendations

  It can be useful to add suggested fixes or workarounds.

• Credits and references

  If there is anyone you need to credit, or references you should cite, now is a good place.

Calculating CVSS Scores

The Common Vulnerability Scoring System (CVSS) helps standardise the severity of vulnerabilities. The current version is CVSS v4.0, but v3.2 is still used.

Without getting too much into details, the Common Vulnerability Scoring System version 4.0: User Guide provides plenty, here are the main points for the Base (CVSS-B) score:

• Exploitability Metrics
  • Attack Vector (AV): Network (N) / Adjacent (A) / Local (L) / Physical (P)
  • Attack Complexity (AC): High (H) / Low (L)
  • Attack Requirements (AT): Present (P) / None (N)
  • Privileges Required (PR): High (H) / Low (L) / None (N)
  • User Interaction (UI): Active (A) / Passive (P) / None (N)
• Vulnerable System Impact Metrics
  • Confidentiality (VC): High (H) / Low (L) / None (N)
  • Integrity (VI): High (H) / Low (L) / None (N)
  • Availability (VA): High (H) / Low (L) / None (N)
• Subsequent System Impact Metrics
  • Confidentiality (SC): High (H) / Low (L) / None (N)
  • Integrity (SI): High (H) / Low (L) / None (N)
  • Availability (SA): High (H) / Low (L) / None (N)

The CVSS 4.0 Calculator is an excellent tool to calculate CVSS scores based on the criteria above. Use it.

This will result in:

• CVSS-B v4.0 Score: e.g, 5.7 / Medium
• Vector: e.g., CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:P/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

Report it to the vendor

Now that you have all this, you should report it to the vendor. They usually have a /.well-known/security.txt file on their website (e.g., https://www.google.com/.well-known/security.txt), which describes their security policies, such as how to report a vulnerability. They might have a page on their site (e.g., https://www.fortiguard.com/psirt_policy), or in the project’s git repository.

Submit a CVE

1. Identify the appropriate CNA CNAs (CVE Numbering Authorities) are organisations authorised to assign CVE IDs to vulnerabilities. Some vendors elect to do this themselves, sometimes because this allows them to control the CVE more closely.

   Check this list on https://www.cve.org/PartnerInformation/ListofPartners:

   • Primary CNAs:
     • Contact the vendor/manufacturer first if they are a CNA (e.g., Atlassian)
     • Or a CNA in your country that steps in (e.g., DirectCyber in Australia)
   • CVE Numbering Authority of Last Resort (CNA-LR): MITRE Corporation

2. Follow the CNA's specific submission guidelines

   It varies for different CNAs. Some CNAs will write and submit the CVE for you.

   For MITRE, use the form on https://cveform.mitre.org/.

   You should have most of it in your report, so get ready to copy and paste! 😢

   • Vulnerability details
   • CVSS scores
   • Proof of concept
   • Contact information
   • etc.

3. Maintain communication for any follow-up questions. If you intend to release the details publicly on your blog/site, respect the vendor’s process and agreed timeline before you release any information.

   If the vendor doesn’t engage, or doesn’t respect their engagement, then you could consider publishing, after giving them a final warning. Before you do this, there are two points you should consider:

   1. Impact on victims
   2. Risk of legal actions

   So this might be a good idea to get independent advice, either via your local CERT or lawyer.

Publish the details

Alright, all cleared, great job! 🙌 Time to brag about it, publish the details publicly, and look for the next vulnerability.