Cve Report Writer

Overview

Generate two aligned narrative vulnerability reports, one English and one Chinese, plus one CVE submission helper Markdown file from the same source material. Preserve the same facts, structure, and severity across all outputs, and change only the language where applicable.

Use this skill when the user already has findings, repro steps, code references, logs, screenshots, or rough drafts and needs them converted into disclosure-ready Markdown reports and a structured CVE intake helper.

Workflow

Follow this sequence:

1. Read the source materials.
2. Extract only verified facts from the provided drafts, notes, screenshots, logs, code references, or reproduction evidence.
3. Trace the confirmed vulnerable code path and collect the core source-to-sink code snippets that explain the risk.
4. Write the narrative reports in the exact section order defined in references/report-rules.md.
5. Generate xxx_en.md, xxx_zh.md, and xxx_cve.md.
6. Keep the English and Chinese files structurally identical.
7. Keep the CVE helper aligned with the same verified facts.
8. Include the core vulnerable code path and a complete reproducible PoC in every output file.

Required Output Rules

Read these files before drafting:

• references/report-rules.md
• references/report-template-en.md
• references/report-template-zh.md
• references/cve-submission-template.md

Apply these rules strictly:

• Produce exactly three files for each finding: xxx_en.md, xxx_zh.md, and xxx_cve.md.
• Keep the English and Chinese versions semantically identical.
• Keep the CVE helper factually aligned with the two narrative reports.
• Use only the allowed sections for each template.
• Do not add banned sections even if they are common in other templates.
• Keep the tone suitable for public GitHub issues, private advisories, or CVE-style submissions.
• Prefer precise, evidence-based language over exaggerated claims.
• If the affected version range is uncertain, keep a clearly marked placeholder instead of inventing one.
• Every output file must include the core vulnerable code path or code snippets that materially explain the risk.
• Every output file must include a complete reproducible PoC flow that matches the verified route, parameters, and behavior.
• Do not leave screenshot placeholders or screenshot instructions unless the user explicitly asks for them.
• xxx_en.md and xxx_zh.md must end with a supplemental metadata section that captures affected product details, severity metadata, and weaknesses metadata.

Required Section Order

Use this section order only for xxx_en.md and xxx_zh.md:

1. # <Title>
2. ## Summary
3. ## Details
4. ## POC
5. ## Impact
6. ## Remediation
7. ## Disclosure Notes
8. ## Supplemental Information for English and ## 补充信息 for Chinese

Use these templates:

• references/report-template-en.md
• references/report-template-zh.md

Banned Sections

Never include these sections unless the user explicitly overrides this skill:

• Example Request
• Observed Result
• Verification
• Why This Matters
• Suggested Fix Direction

If the source draft contains useful text under those headings, fold the useful facts into the allowed sections instead of preserving the headings.

Title Rules

Write titles in a public issue or CVE style format:

• English: SSRF in /path via root-cause (product <= version)
• Chinese: mirror the same meaning, severity, endpoint, and version scope

If the version range is not confirmed, use a cautious placeholder such as:

• English: (affected versions to be confirmed)
• Chinese: （受影响版本待确认）

Do not fabricate an affected range.

Core Code Rules

Every output file must contain the core vulnerable code path.

The code content must:

• cover the confirmed risk chain from entry point to enforcement failure or dangerous sink
• use concise snippets only, not full files
• keep line references or file references when available
• explain why each snippet matters
• avoid speculative code that has not been tied to the verified exploit path

POC Rules

POC must contain the practical reproduction flow and a complete PoC that can be followed without screenshots.

The PoC must:

• use the verified route, parameters, headers, and payload format
• match the actual request method and endpoint naming used by the product
• state the relevant runtime prerequisites when they affect exploitability
• describe the expected response or outcome based on verified evidence
• stay reproducible and copyable

Do not leave screenshot placeholders or screenshot guidance in any output unless the user explicitly asks for them.

Content Rules

Summary

• State the vulnerability type, affected feature or endpoint, attacker prerequisites, and core impact in 1 to 3 short paragraphs.

Details

• Explain the root cause.
• Reference the relevant endpoint, permission model, trust boundary, or data flow.
• Include the core vulnerable code path or concise code snippets that materially strengthen the report.
• Remove noisy implementation detail that does not help the reader understand exploitability.

POC

• Describe the exploitation path in a practical order.
• Reuse the user's verified repro flow when available.
• Keep the steps reproducible.
• Include a complete PoC and expected outcome instead of screenshot placeholders.

Impact

• State concrete security consequences.
• Do not repeat the full repro flow.
• Prefer direct outcomes such as unauthorized access, credential leakage, internal network reachability, task tampering, code execution, or cross-tenant data exposure.

Remediation

• Give high-level, technically correct fix guidance.
• Do not prescribe overly specific code patches unless the user explicitly asks for them.
• Prefer durable fixes such as consistent server-side authorization checks, trusted-source resolution, strict validation, identity binding, or removal of insecure defaults.

Disclosure Notes

• Keep this section short.
• Use it for caveats such as unconfirmed affected version range, issue-style formatting, or disclosure status.

Supplemental Information / 补充信息

• Append this section at the very end of xxx_en.md and xxx_zh.md.
• Use it for form-style metadata that should remain easy to copy into advisory portals or disclosure forms.
• Include these fields:
  • Affected products
    • Ecosystem
    • Package name
    • Affected versions
    • Patched versions
  • Severity
    • Scoring method
    • Score
    • Vector string
  • Weaknesses
    • CWE
• Severity must provide CVSS scoring details: method, numeric score from 0.0 to 10.0, and vector string.
• If any value is unknown, keep a clearly marked placeholder instead of inventing one.

CVE Template Rules

The xxx_cve.md file is a structured submission helper for CVE or CNA intake forms.

Populate these fields:

1. Vulnerability type
2. CWE
3. Vendor of the product(s)
4. Affected product(s)/code base
   • Product
   • Version
5. Attack type
6. Impact
   • if Other is selected, explain it
7. Affected component(s)
8. Core vulnerable code path
9. Attack vector(s)
10. Suggested description of the vulnerability for use in the CVE
11. Discoverer(s)/Credits
12. Reference(s)
13. Additional information

Apply these constraints:

• Vulnerability type must be chosen from the fixed enumerated options documented in the template.
• Attack type must be chosen from the fixed enumerated options documented in the template.
• Impact must use only the documented checkbox options, and Other impact must explain any checked Other.
• CWE may use a precise CWE identifier with a short title, or a clearly marked placeholder if not yet confirmed.
• Core vulnerable code path must contain concise, relevant snippets or a structured source-to-sink summary.
• Default Discoverer(s)/Credits to [Your Name] unless the user explicitly overrides it.
• Default Reference(s) to blank placeholders for the user to fill later.
• Default Additional information to blank unless useful supporting context is clearly available.
• Do not invent fixed versions or references.
• If multiple impacts apply, list all supported ones in the template output.

Style Rules

• Use Markdown only.
• Prefer short paragraphs and flat bullets.
• Keep each section focused.
• Avoid hype, emotional wording, and unsupported severity claims.
• Preserve the user's evidence and findings; improve clarity, not meaning.
• Do not downgrade or upgrade impact without evidence from the source materials.

Handling Source Drafts

When the user provides rough drafts:

• keep all verified facts
• normalize terminology
• fill missing Impact, Remediation, Disclosure Notes, CWE, or huntr field content when needed
• remove duplicate statements across sections
• merge redundant request or verification details into POC
• convert screenshots into supporting evidence only when the user explicitly wants them referenced

When the user provides only one language:

• draft the missing language version to match it exactly in meaning

When the user provides both languages:

• align them so the content is equivalent section by section

Resources

Use these files as the canonical reference for output shape:

• references/report-rules.md
• references/report-template-en.md
• references/report-template-zh.md
• references/cve-submission-template.md