English for Security Vulnerability Reports: CVE and Disclosure Language

A vulnerability report is one of the highest-stakes documents in software. It has to convey what’s broken, how bad it is, and how to fix it — precisely, calmly, and without either understating or sensationalising. The language is specialised, and getting it wrong damages credibility. This guide covers the English of CVEs, severity, impact, and responsible disclosure.

---

The anatomy of a vulnerability report

A strong report answers, in order:

1. What the vulnerability is (the class and component).
2. Severity (how serious, ideally with a CVSS score).
3. Impact (what an attacker can actually do).
4. Reproduction (proof it’s real).
5. Affected versions (the scope).
6. Remediation (how to fix or mitigate).

Each section has its own conventional phrasing.

---

Naming the vulnerability

Use the standard vulnerability-class vocabulary — it signals competence and tells readers what to expect:

• injection — SQL injection, command injection. “This is a SQL injection in the search endpoint.”
• XSS (cross-site scripting) — “A stored XSS in the comment field.”
• CSRF (cross-site request forgery)
• SSRF (server-side request forgery)
• RCE (remote code execution) — the most serious class. “This allows unauthenticated RCE.”
• privilege escalation — gaining higher access. “A privilege-escalation flaw lets a user become admin.”
• path traversal — “A path-traversal bug exposes arbitrary files.”
• IDOR (insecure direct object reference) — accessing others’ data by changing an ID.
• information disclosure / leak — exposing data. “An information disclosure in the error response.”

“An unauthenticated attacker can achieve remote code execution via a deserialization flaw in the import endpoint.”

---

Severity language

Severity uses CVSS (Common Vulnerability Scoring System), a 0–10 score with bands:

• Critical (9.0–10.0)
• High (7.0–8.9)
• Medium (4.0–6.9)
• Low (0.1–3.9)

Phrasing:

• “This is rated Critical (CVSS 9.8).”
• “We assess this as High severity.”
• “The base score is 8.1 due to network attack vector and high impact.”

Be specific about the conditions that drive severity:

• attack vector — network, adjacent, local, physical. “Network-exploitable, no user interaction.”
• privileges required — “No authentication is required.”
• user interaction — “Requires the victim to click a link.”

The phrase “pre-auth” (before authentication) vs “post-auth” (after) is critical: pre-auth bugs are far more dangerous.

---

Describing impact precisely

Impact is where reports often fail — either vague (“it’s bad”) or hyperbolic. State exactly what an attacker can do.

• “An attacker can read arbitrary files on the host.”
• “This allows full account takeover.”
• “An attacker can execute arbitrary commands as the service user.”
• “The flaw exposes other users’ personal data.”

Use the CIA triad framing when useful — confidentiality, integrity, availability:

• “This affects confidentiality (data exposure) but not integrity.”
• “A successful exploit compromises availability — it crashes the service.”

Avoid weasel words: “could potentially possibly allow” — say “allows” if it does, “may allow under X condition” if it’s conditional.

---

Writing reproduction steps

A report without reproduction is a claim, not a finding. Be exact and minimal — a proof of concept, not a tutorial.

Steps to reproduce:
1. Send a POST to /api/import with the payload below.
2. Observe the server executes the embedded command.

Proof of concept:
  POST /api/import
  Content-Type: application/json
  { "data": "<crafted payload>" }

Result: the command `id` runs and returns the service user.

Phrases:

• “The following request demonstrates the issue:”
• “This proof of concept executes id as the service user.”
• “The vulnerability can be triggered with a single unauthenticated request.”

Redact anything dangerous when sharing publicly: “Payload redacted pending the fix.”

---

Affected versions and remediation

State scope and fix unambiguously:

• “Affected versions: 2.0.0 through 2.4.1.”
• “Fixed in 2.4.2.”
• “Versions prior to 2.4.2 are vulnerable.”

Remediation phrasing:

• “Upgrade to 2.4.2 or later.”
• “As a mitigation, disable the import feature until you can patch.”
• “There is no workaround; patching is required.”

Distinguish a fix (removes the vulnerability) from a mitigation (reduces risk without fully fixing).

---

Responsible disclosure language

When you report to a vendor, the tone is professional and cooperative, not threatening.

• “We are reporting this privately under responsible disclosure.”
• “We propose a 90-day disclosure timeline, in line with industry norms.”
• “Please confirm receipt and an expected remediation date.”
• “We will coordinate public disclosure once a patch is available.”
• “The issue is under embargo until the agreed disclosure date.”

Key terms:

• responsible / coordinated disclosure — reporting privately first.
• disclosure timeline — agreed window before going public.
• embargo — hold on public details.
• PoC (proof of concept) — demonstration code.
• patch / advisory — the fix and its announcement.

“We’ve reported this privately and agreed a 90-day embargo. We’ll publish the advisory and CVE once the patch ships.”

---

Before and after

Before: “There’s a really bad security hole in the import thing, hackers could totally destroy everything, you need to fix it ASAP!!!”

This is alarming, unspecific, and unprofessional.

After: “Summary: Unauthenticated RCE in the /api/import endpoint via unsafe deserialization. Severity: Critical (CVSS 9.8), network attack vector, no auth required. Impact: Arbitrary command execution as the service user, leading to full host compromise. Affected: 2.0.0–2.4.1. Remediation: Upgrade to 2.4.2; as a mitigation, disable the import feature. PoC attached, payload redacted.”

The second is taken seriously precisely because it’s calm and specific.

---

Common mistakes

• Hyperbole. “Catastrophic, total destruction” reads as amateur. Let the facts carry the weight.
• Vague impact. “It’s insecure” — say what an attacker can do.
• Confusing fix and mitigation. A mitigation reduces risk; a fix removes the bug.
• Pre-auth vs post-auth left unstated. Always say whether authentication is required.
• No reproduction. Without a PoC, it’s an unverified claim.
• Overusing “could potentially possibly”. State what is, then hedge only genuinely conditional parts.

---

Key takeaways

• Structure: what, severity, impact, reproduction, affected versions, remediation.
• Name the vulnerability class and state pre-auth vs post-auth.
• Give a CVSS score and explain what drives it.
• Describe impact as what an attacker can actually do.
• Keep the tone calm and precise — facts, not alarm — and use responsible disclosure language.

A great vulnerability report earns trust through clarity. Write it so the reader knows exactly how bad it is and exactly what to do next.