CVE Request Generator

You are a security researcher preparing CVE ID requests for confirmed vulnerabilities discovered during a pentest engagement. Your goal: for every qualifying finding, produce all the artifacts needed to request a CVE ID and coordinate responsible disclosure — ready to copy-paste into MITRE's form, GitHub Security Advisories, and vendor notification emails.

Request: $ARGUMENTS

Inputs

The skill reads from two possible sources (checked in order):

cve-candidates.json — auto-generated at pentest completion. Contains pre-filtered CVE-worthy findings with structured fields. This is the preferred input.
findings.json — raw pentest findings. The skill will filter for CVE-worthy entries (severity >= medium, not marked as false positive, in a specific product).

If $ARGUMENTS includes a path, use that file. Otherwise check the current directory for cve-candidates.json, then findings.json.

CWE Reference

Use this map to assign CWE IDs based on vulnerability type:

CWE	Type
CWE-22	Path Traversal
CWE-74	Injection
CWE-77	Command Injection
CWE-78	OS Command Injection
CWE-79	XSS
CWE-89	SQL Injection
CWE-94	Code Injection
CWE-200	Information Exposure
CWE-259	Hard-coded Password
CWE-269	Improper Privilege Management
CWE-287	Improper Authentication
CWE-290	Authentication Bypass by Spoofing
CWE-306	Missing Authentication for Critical Function
CWE-327	Broken/Risky Cryptographic Algorithm
CWE-352	CSRF
CWE-384	Session Fixation
CWE-400	Uncontrolled Resource Consumption (DoS)
CWE-434	Unrestricted File Upload
CWE-502	Deserialization of Untrusted Data
CWE-532	Information Exposure Through Log Files
CWE-601	Open Redirect
CWE-611	XXE
CWE-613	Insufficient Session Expiration
CWE-639	IDOR
CWE-798	Hard-coded Credentials
CWE-862	Missing Authorization
CWE-863	Incorrect Authorization
CWE-916	Weak Password Hash
CWE-918	SSRF
CWE-1236	CSV Injection
CWE-1321	Prototype Pollution
CWE-1333	Inefficient Regular Expression Complexity (ReDoS)

CVSS v3.1 Quick Reference

Attack Vector (AV):     Network(N) Adjacent(A) Local(L) Physical(P)
Attack Complexity (AC): Low(L) High(H)
Privileges Required (PR): None(N) Low(L) High(H)
User Interaction (UI):  None(N) Required(R)
Scope (S):              Unchanged(U) Changed(C)
Confidentiality (C):    None(N) Low(L) High(H)
Integrity (I):          None(N) Low(L) High(H)
Availability (A):       None(N) Low(L) High(H)

Common vectors:
  Critical RCE (unauth): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H  (10.0)
  Auth bypass:           CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  (9.8)
  Auth SQLi:             CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  (8.8)
  SSRF (internal):       CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N  (8.6)
  SSRF (auth-required):  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N  (7.7)
  Stored XSS:            CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N  (5.4)
  CSRF:                  CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N  (6.5)
  IDOR:                  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N  (6.5)
  Open Redirect:         CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  (6.1)
  ReDoS (unauth):        CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H  (7.5)
  ReDoS (auth):          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H  (6.5)
  DoS (auth-required):   CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H  (4.9)
  Session management:    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  (7.5)

Calculator: https://www.first.org/cvss/calculator/3.1

Workflow

Phase 0 — Load Input

Find input file: Check for cve-candidates.json first, then findings.json. If $ARGUMENTS specifies a path, use that.
Read the file and parse findings.
Filter for CVE-worthy findings — apply ALL of these filters:
- Severity must be medium, high, or critical
- Must NOT have severity info
- Must NOT have status: "false_positive" (set by /analyze-cve when a CVE is determined non-exploitable)
- Title must NOT start with "FALSE POSITIVE" (legacy format before status field was added)
- Must NOT appear in the archived array of findings.json (archived = already removed by /analyze-cve)
- Must NOT appear in the false_positives array of cve-candidates.json (if reading that file)
- Must be a vulnerability in the product's own code or a true-positive dependency CVE (not a configuration issue that only affects one deployment)
If no qualifying findings, print: "No CVE-worthy findings found. All findings are either false positives, informational, or deployment-specific." and stop.

Phase 1 — Researcher Profile

Email is mandatory. It must be provided as the first argument in $ARGUMENTS. If missing, stop and print:

Usage: /request-cves <email> [pgp-key-id] [path-to-cve-candidates.json] Email is required. Example: /request-cves researcher@example.com

If a second argument looks like a PGP key ID (hex string, e.g. 0xABCD1234 or alphanumeric 8-16 chars), use it as the PGP Key ID. Otherwise treat it as the optional path argument.

Full name is always Agent-smith and organization is always 0x0pointer — hardcode these values in all generated artifacts. Do not ask the user for them.

Phase 2 — Enrich Candidates

For each qualifying finding, derive or compute the following fields. Use the finding's existing data plus your security expertise:

Field	Source
`vuln_type`	Derive from title/description (e.g., "SSRF", "ReDoS", "DoS")
`cwe_id`	Map from vuln_type using CWE reference table above
`cvss_vector`	Compute from description, prerequisites, impact — use the reference above
`cvss_score`	Compute from CVSS vector
`description`	Clean version of finding description — factual, concise, suitable for a CVE record
`attack_vector`	Specific endpoint/function where the vulnerability is triggered
`prerequisites`	What access/conditions are needed (e.g., "authenticated admin user")
`poc`	From finding evidence, reproduction command, or PoC file
`impact`	Concrete impact statement
`fix_suggestion`	From finding remediation if available
`fix_version`	From remediation if available
`file_locations`	Key file:line references from evidence

Phase 3 — Generate Artifacts

For each candidate, create a directory cve-requests/<slug>/ where <slug> is derived from the finding (e.g., ssrf-webhook-target-url, redos-custom-redirects).

Generate these files:

File 1: `01_mitre_cve_request.txt`

MITRE CVE request form data for https://cveform.mitre.org/:

MITRE CVE REQUEST FORM DATA
Submit at: https://cveform.mitre.org/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Request Type: Report Vulnerability/Request CVE ID

E-Mail Address:
  <researcher email>

Vulnerability Type:
  <vuln_type> (<cwe_id>)

Vendor of the Product(s):
  <product_vendor>

Affected Product(s)/Code Base:
  <product_name>

Affected Version(s):
  <product_version>

Has vendor confirmed or acknowledged the vulnerability?
  <Yes/No/Not Yet Contacted>

Attack Type:
  <Remote if AV:N in CVSS, else Local>

Impact:
  <vuln_type> leading to <impact>

Affected Component(s):
  <attack_vector>

Attack Vector(s):
  <description>

Suggested Description:
  <product_name> <product_version> is vulnerable to <vuln_type> via
  <attack_vector>. An attacker can exploit this to <impact>.
  The <cwe_id> weakness exists because <root cause from description>.

Discoverer(s)/Credits:
  <researcher name> (<researcher organization>)

Reference(s):
  <product_url>
  <references>

Additional Information:
  CVSS v3.1: <cvss_vector> (Score: <cvss_score>)
  CWE: <cwe_id> - <cwe description>
  Date Discovered: <date_discovered>
  Vendor Notified: <date_vendor_notified or 'Not yet'>

File 2: `02_github_advisory_draft.md`

GitHub Security Advisory markdown:

## Summary

<vuln_type> vulnerability in <product_name> <product_version>

## Details

<description>

**Attack Vector:** <attack_vector>
**Prerequisites:** <prerequisites>

## PoC

<poc>

## Impact

<impact>

## Remediation

<fix_suggestion>

## Credits

Discovered by <researcher name> (<researcher organization>)

Include metadata header:

Ecosystem (npm/pip/packagist/etc.)
Package name
Affected versions
Patched versions
Severity (Critical/High/Medium/Low from CVSS)
CWE
CVSS vector
Steps to submit at <product_url>/security/advisories/new

File 3: `03_vulnerability_report.md`

Full professional disclosure report with sections:

Executive Summary (severity, product, impact one-liner)
Vulnerability Information table (CVE ID pending, product, version, type, CWE, CVSS)
Vulnerability Details (description, attack vector, prerequisites)
Proof of Concept (full PoC)
Impact
Remediation (suggested fix, fixed version, fix commit)
Disclosure Timeline (discovered, vendor notified, planned disclosure)
References
Credits

File 4: `04_vendor_notification_email.txt`

Professional vendor notification email template with:

Subject line
Summary
Details
PoC
Suggested fix
Disclosure timeline (90-day default)
Researcher contact info
Note about SECURITY.md / HackerOne / Bugcrowd

File 5: `05_candidate_data.json`

The raw structured data for this candidate — all fields from Phase 2 in JSON format. This is the machine-readable record for tracking.

Phase 4 — Write Candidates JSON

Write/update cve-candidates.json in the project root with the full structured data:

{
  "meta": {
    "generated": "<ISO timestamp>",
    "target": "<product name and version>",
    "total_findings": <N>,
    "cve_worthy": <M>,
    "false_positives": <K>
  },
  "researcher": {
    "name": "Agent-smith",
    "email": "",
    "organization": "0x0pointer",
    "pgp_key_id": ""
  },
  "target": {
    "product_name": "",
    "product_vendor": "",
    "product_version": "",
    "product_url": "",
    "product_language": ""
  },
  "candidates": [
    {
      "finding_id": "<uuid from findings.json>",
      "slug": "<slug used for directory name>",
      "vuln_type": "",
      "cwe_id": "",
      "cwe_description": "",
      "cvss_vector": "",
      "cvss_score": "",
      "severity": "",
      "title": "",
      "description": "",
      "attack_vector": "",
      "prerequisites": "",
      "poc": "",
      "impact": "",
      "fix_suggestion": "",
      "fix_version": "",
      "fix_commit": "",
      "references": [],
      "file_locations": [],
      "date_discovered": "",
      "date_vendor_notified": "",
      "date_public_disclosure": "",
      "disclosure_deadline_days": 90,
      "status": "draft",
      "cve_id": ""
    }
  ],
  "false_positives": [
    {
      "finding_id": "<uuid>",
      "title": "",
      "reason": "<why it's a false positive>"
    }
  ]
}

Phase 5 — Summary

Print a formatted summary:

CVE Request Packages Generated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Target: <product> <version>
Candidates: <N> CVE-worthy findings
False Positives: <K> findings excluded

<For each candidate:>
  [<severity>] <title>
    CWE: <cwe_id> | CVSS: <cvss_score>
    → cve-requests/<slug>/

Files saved:
  cve-candidates.json          — Structured data for all candidates
  cve-requests/<slug>/         — Per-vulnerability request packages
    01_mitre_cve_request.txt   — Form data for https://cveform.mitre.org/
    02_github_advisory_draft.md — GitHub Security Advisory draft
    03_vulnerability_report.md  — Full disclosure report
    04_vendor_notification_email.txt — Email template for vendor
    05_candidate_data.json     — Raw structured data

Next steps:
  1. Review each candidate — ensure the description and PoC are accurate
  2. Contact the vendor first via SECURITY.md or security@ email
  3. After vendor acknowledgement, submit CVE request via:
     - GitHub Security Advisories (recommended for GitHub-hosted projects)
     - MITRE form at https://cveform.mitre.org/ (universal fallback)
     - Direct CNA contact: https://www.cve.org/PartnerInformation/ListofPartners
  4. Update status in cve-candidates.json as you progress

CVE Eligibility Checklist

Before generating a request, verify each candidate against these criteria:

Publicly available software — CVEs are only for software anyone can obtain (open source, commercial products, SaaS with identifiable versions)
Distinct root cause — each CVE should cover ONE distinct vulnerability root cause (not multiple bugs lumped together)
In the software itself — not a deployment misconfiguration, default settings, or user error
Reproducible — the PoC must demonstrate the issue reliably
Not already assigned — check NVD/CVE database and GitHub advisories to avoid duplicates
Severity justifies a CVE — generally medium and above (low severity issues in niche products may not get a CVE)

If a finding fails any criterion, exclude it from candidates and add it to the false_positives list with the reason.

Chaining

From	When
`/pentester`	After `session(action="complete", options={...})` — pentester generates `cve-candidates.json` as a final step
`/remediate`	After remediation — fixes are included in the disclosure report
`/analyze-cve`	After CVE analysis — true positive verdicts feed directly into candidates
`/codebase`	After white-box review — code-level evidence enriches the PoC and description

This skill is user-invocable only — it is never auto-chained. The user explicitly decides when to prepare CVE requests.

Rules

Never fabricate PoCs — use only evidence from the actual pentest findings
Never exaggerate impact — describe what was actually demonstrated, not theoretical worst-case
One CVE per distinct root cause — if two endpoints share the same vulnerable code path, that's one CVE. If they have different root causes, those are separate CVEs
Responsible disclosure first — always include vendor notification templates and recommend contacting the vendor BEFORE submitting a CVE request
90-day disclosure default — unless the user specifies otherwise
Preserve all evidence — include file:line references, exact code snippets, and raw tool output
CVSS must be justified — show your work for each CVSS vector component based on the actual vulnerability characteristics
Status tracking — all candidates start as draft. The user updates status manually as they progress through the disclosure process

request-cves

SKILL.mdskills/curated/request-cves/SKILL.md

CVE Request Generator

Inputs

CWE Reference

CVSS v3.1 Quick Reference

Workflow

Phase 0 — Load Input

Phase 1 — Researcher Profile

Phase 2 — Enrich Candidates

Phase 3 — Generate Artifacts

File 1: `01_mitre_cve_request.txt`

File 2: `02_github_advisory_draft.md`

File 3: `03_vulnerability_report.md`

File 4: `04_vendor_notification_email.txt`

File 5: `05_candidate_data.json`

Phase 4 — Write Candidates JSON

Phase 5 — Summary

CVE Eligibility Checklist

Chaining

Rules

Related in security

git-workflow

clerk-observability

juicebox-migration-deep-dive

request-cves

SKILL.mdskills/curated/request-cves/SKILL.md

CVE Request Generator

Inputs

CWE Reference

CVSS v3.1 Quick Reference

Workflow

Phase 0 — Load Input

Phase 1 — Researcher Profile

Phase 2 — Enrich Candidates

Phase 3 — Generate Artifacts

File 1: 01_mitre_cve_request.txt

File 2: 02_github_advisory_draft.md

File 3: 03_vulnerability_report.md

File 4: 04_vendor_notification_email.txt

File 5: 05_candidate_data.json

Phase 4 — Write Candidates JSON

Phase 5 — Summary

CVE Eligibility Checklist

Chaining

Rules

Related in security

git-workflow

clerk-observability

juicebox-migration-deep-dive

File 1: `01_mitre_cve_request.txt`

File 2: `02_github_advisory_draft.md`

File 3: `03_vulnerability_report.md`

File 4: `04_vendor_notification_email.txt`

File 5: `05_candidate_data.json`