From Bugcrowd VDP Report to Published CVE

Most bug hunters never see the CVE side of a report. You submit, it gets triaged, it gets fixed or closed, and the ticket goes quiet. The part where a vendor reserves an identifier, writes an advisory and publishes a record with your name in the credits happens somewhere else.

I went through that path four times in 2026 with Progress Software: CVE-2026-91140, CVE-2026-92931, CVE-2026-106138 and CVE-2026-106139, all reported through Bugcrowd vulnerability disclosure programs and all assigned by Progress acting as a CVE Numbering Authority. The mechanics are learnable, and once you know them you can write reports that make the vendor's job easier and your credit more likely.

This post walks the path end to end: what a VDP is, how to write a report a vendor can act on, what triage argues about, how a CVE ID gets assigned and published, which artifacts appear where, and what I do once the record is live. No invented timelines, no payloads; the CVE-specific facts are the ones on the public record.

VDP vs bug bounty vs direct email

A vulnerability disclosure program (VDP) is a vendor's public statement that it wants security reports, with rules about scope and conduct, and a promise not to pursue legal action against researchers who follow them. That promise is the safe harbour. A VDP on Bugcrowd or HackerOne runs through the platform's form and triage team; a vendor-run VDP usually means a security@ address and a policy page.

A bug bounty is a VDP with money attached. The rules are similar; the difference is a reward table.

Direct email with no published policy is the worst of the three for a researcher: no safe harbour, no tracking, no shared definition of "fixed".

The misconception I hear most: "VDPs do not pay, so they are not worth the time." What a VDP gives you instead is credit that compounds: Hall of Fame listings, CVE records that cite you as finder, and a relationship with a security team that will take your next report seriously. All 12 of my Progress CVEs came from VDPs, and I am on the Bugcrowd Hall of Fame for the Vero, Sitefinity, Chef, DevTools, DataDirect and MarkLogic programs because of that choice.

Writing a report a vendor can act on

A triage team reads dozens of reports. The ones that move fastest answer every question the triager would otherwise have to ask. Each field has a reason to exist:

Title states the class and component so the report can be routed without opening it.
Affected component and version becomes the CVE record's affected block. Pin the exact package name and tested version; "latest" is not a version.
CWE (Common Weakness Enumeration, MITRE's catalogue of weakness types) gives the vendor the problemTypes entry and tells engineers which fix pattern applies.
CVSS vector with justification (Common Vulnerability Scoring System) is where disagreements happen, so explain each metric rather than pasting a score.
Minimal PoC: the smallest input that demonstrates the issue. A one-line reproduction gets fixed faster than a video.
Impact in concrete terms: what an attacker can read, change or run, and from where.
Fix suggestion is optional but shortens the engineering conversation.

The template I use, trimmed to essentials:

Title: [CWE-918] SSRF in <package> <component> via <input>

Affected: @vendor/package 1.2.3 (npm), tested on Node 20 / Linux
Not affected: (if known)

Weakness: CWE-918 Server-Side Request Forgery

CVSS 3.1: 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
  AV:N - reachable over the network
  PR:N - no credentials needed
  UI:R - a user must open the crafted page
  S:U  - impact stays within the vulnerable component
  C/I/A:H - server-side fetch reaches internal services

Steps to reproduce:
  1. Install @vendor/[email protected] in a fresh project
  2. Send: GET /render?src=https://attacker.example/ HTTP/1.1
  3. Observe an inbound request on attacker.example from the server IP

Impact: server issues requests to attacker-chosen hosts; internal
services reachable from the render host are exposed.

Suggested fix: resolve the fetch origin from server config, not request
data; allow-list hosts and schemes.

Disclosure: happy to coordinate; please credit "Abhishek Nandkumar
Bhaskar (Abhi-Hackz)" in any advisory or CVE record.

Two details worth copying: the "Not affected" line, which saves a round of "does this hit older versions too", and the credit line with the exact spelling you want in the record.

Triage and the "is this a vulnerability?" conversation

Triage is where the platform and vendor decide whether the report describes a security issue, whether it is in scope, and how severe it is. Three things get argued about.

Reproducibility. If the triager cannot reproduce from your steps, nothing else matters. Reproduce it yourself from a clean environment before submitting: fresh install, pinned version, exact request. If it depends on configuration, say so.

Version pinning. A vendor cannot assign a CVE to "the current version"; they need a range. If you tested one version, say that and let them determine the range. Do not guess at versions you did not test.

Scope. VDPs list in-scope assets. A finding in an npm package may not obviously fit a program that lists web properties. Read the policy; if the package is unlisted but vendor-owned, say why you believe it is in scope and let the triager escalate.

The conversation that catches people out is "this is hardening, not a vulnerability". It comes up when the impact section is vague. Concrete impact ("a low-privileged user can run JavaScript in an admin's browser by setting a label") survives it; "unsanitised input" alone does not.

How a CVE gets assigned

CVE (Common Vulnerabilities and Exposures) is the public catalogue of vulnerability identifiers, operated by MITRE. Most IDs are not assigned by MITRE directly but by CVE Numbering Authorities (CNAs): vendors, open-source projects and coordinators granted authority to assign IDs for products in their scope. Progress Software is a CNA for its own products, which is why all 12 of my IDs came from Progress and not a third party.

The lifecycle, in the CVE program's terms:

Reserved. The CNA allocates an ID. The ID exists but the record is empty and private.
Published. The CNA submits the record content and it becomes visible at cve.org.
Updated, if anything changes later, such as a corrected version range.

The record is JSON. The fields you care about as a finder:

{
  "cveMetadata": { "cveId": "CVE-2026-XXXXX", "state": "PUBLISHED" },
  "containers": { "cna": {
    "affected": [ { "vendor": "Vendor", "product": "@vendor/package",
      "versions": [ { "version": "1.0.0", "lessThan": "1.2.0", "status": "affected" } ] } ],
    "problemTypes": [ { "descriptions": [ { "cweId": "CWE-918", "description": "SSRF" } ] } ],
    "metrics": [ { "cvssV3_1": { "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/..." } } ],
    "credits": [ { "type": "finder", "value": "Abhishek Nandkumar Bhaskar (Abhi-Hackz)" } ],
    "references": [ { "url": "https://vendor.example/advisory" } ]
  } }
}

Notice how directly these map onto the report template: affected from your version pinning, problemTypes from your CWE, metrics from your vector, credits from your credit line. Write the report with the record in mind and the vendor is mostly copying.

To be clear: the researcher does not assign anything. You can request a CVE and supply the facts, but the CNA decides whether the issue meets the threshold and what the final text says. For CVE-2026-91140 the published description is the vendor's wording, and that is normal.

Advisories, KB articles and Hall of Fame

A CVE record is rarely the only artifact. Vendors publish their own documents alongside it, through channels that vary by product. For my four:

Security bulletins and advisories. The DataDirect issue was covered by the "Progress DataDirect Critical Security Alert Bulletin, September 2026" and the Sitefinity issue by the "Sitefinity Critical Security Advisory for Addressing Security Vulnerabilities in Next.js, September 2026". These are what a customer's security team reads.
Knowledge base articles. The two chart-tooltip issues each have a Telerik KB article (kb-security-chart-tooltip-xss-cve-2026-106138 and -106139) with affected ranges, fixed versions and, for the Vue package, a workaround.
Public patch commits. For the generator, the fix commit is public on GitHub in progress/datadirect-arc-ai-model-gen. Not every vendor does this; when they do, it is the best teaching material, because you can read exactly what changed.
Platform Hall of Fame. Bugcrowd lists researchers per program. That is a platform artifact, separate from the vendor's, and usually what people find first.

Where you are cited depends on the artifact: the CVE record has a credits field, advisories usually have an acknowledgements line, KB articles sometimes have neither. Ask for credit explicitly; do not assume it carries over.

Timeline expectations

I am not going to publish internal dates, and you should be careful doing so for your own reports. From the public record: the vendor bulletins for the DataDirect and Sitefinity issues are dated September 2026, and the first four CVE records were published between 2026-10-05 and 2026-10-10, with patched versions already available; eight further Kendo UI for jQuery records followed on 2026-10-15. That is what coordinated disclosure should look like: fix first, then record.

Generic order of events on a VDP-to-CVE path:

Platform triage validates and forwards to the vendor.
The vendor reproduces, confirms the affected range and develops a fix.
The CNA reserves an ID (you may or may not be told).
The fix ships; the advisory or KB article and the CVE record publish together or close to it.
Platform Hall of Fame and credits update.

It takes weeks to months. The vendor controls the clock, and a VDP rarely commits to a deadline. If a report goes silent, a polite status request through the platform is appropriate; publishing before the fix is not, unless the program's policy says otherwise.

What I do after publication

Verify the record. Read the published CVE at cve.org and check the affected range, CWE, vector and credit spelling against what you reported. Records are written by people; mistakes happen.

Request corrections. If the record disagrees with the advisory, or the version range is wrong, go back through the channel you reported on. CNAs can update records, and a clean record is in everyone's interest.

Cross-reference the artifacts. Make sure the advisory, KB article and CVE record point at each other and at the same fixed version.

Update your own profile. Add the IDs to your Hall of Fame page and platform profiles. The record is the proof; link to it rather than describing it.

Write it up responsibly. Explain the class, cite the record, withhold the PoC unless the vendor is fine with publication. My write-up of these four is linked below.

Checklist: before you hit submit

Component and exact version pinned; reproduced from a clean install.
CWE named; CVSS 3.1 vector with a one-line justification per metric.
Minimal, deterministic reproduction; one request or one file if possible.
Impact stated as what an attacker gains, from which privilege level.
Scope checked against the program policy.
Credit line with the exact name spelling you want in the record.
A note that you will coordinate and will not publish before the fix.

Takeaways

A VDP trades money for safe harbour and credit; for CVE-level findings that credit is permanent and public.
Write the report in the shape of the CVE record: affected versions, CWE, CVSS with justification, credits.
The CNA, not the researcher, decides on and words the record. Your job is to make that decision easy.
Advisories, KB articles, patch commits and Hall of Fame pages are separate artifacts; check all of them after publication and ask for corrections where they disagree.

Learn more

The CVE Program: CNA model and record format (cve.org)
MITRE CWE, for choosing the right weakness ID (cwe.mitre.org)
FIRST CVSS v3.1 Specification and User Guide (first.org)
OWASP Vulnerability Disclosure Cheat Sheet (owasp.org)

From a Bugcrowd VDP Report to a Published CVE: How Coordinated Disclosure Actually Works