` 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-en.md) - [`references/report-template-zh.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-rules.md) - [`references/report-template-en.md`](references/report-template-en.md) - [`references/report-template-zh.md`](references/report-template-zh.md) - [`references/cve-submission-template.md`](references/cve-submission-template.md)

# Cve Report Writer > Use when drafting or rewriting vulnerability reports into aligned English, Chinese, and CVE Markdown deliverables from verified findings, code references, repro steps, or rough disclosure drafts. - Skill: `larlarua/cve-report-writer` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add larlarua/cve-report-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/larlarua/cve-report-writer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: larlarua (https://skillmd.com/u/larlarua) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/larlarua/cve-report-writer --- # 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-rules.md) - [`references/report-template-en.md`](references/report-template-en.md) - [`references/report-template-zh.md`](references/report-template-zh.md) - [`references/cve-submission-template.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. `# ` 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-en.md) - [`references/report-template-zh.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-rules.md) - [`references/report-template-en.md`](references/report-template-en.md) - [`references/report-template-zh.md`](references/report-template-zh.md) - [`references/cve-submission-template.md`](references/cve-submission-template.md)