Lab 9: CVD Disclosure Draft · ADV-101 · Virtus Cyber Academy Classroom

~3 hr. Draft a CERT/CC-grade disclosure report for a HYPOTHETICAL novel finding. The hypothetical lets you practice the writing without the political pressure of actual vendor coordination. Format becomes the capstone template.

Goal: ship ~/adv-101/lab-9/disclosure-report.md with all 12 CERT/CC report sections covering a plausible hypothetical vulnerability (you invent the bug; you write it up as if it were real). Word count ~2500-4000.

Estimated time: ~3 hr.

Prerequisites: Week 9 lecture. Lab 8 (CVSS scoring practice).

Authorization line: Lab 9 is paper-only.

Lab 9 session, 2026-MM-DD HH:MM. CVD disclosure-draft exercise on hypothetical
vulnerability; no hardware contact; no real vendor interaction.

Setup

mkdir -p ~/adv-101/lab-9
cd ~/adv-101/lab-9

Part A: Pick a hypothetical vulnerability (~15 min)

Invent a plausible but not-real vulnerability. The hypothetical should be:

Concrete enough to write up. A specific product (real or invented); a specific bug class; a specific impact.
Not too easy. A trivial unauthenticated RCE on a popular product is too easy; pick something with nuance.
Not too political. Avoid current real products; the hypothetical is for practice. Inventing a fictional product is safest.

Three suggested hypotheticals (pick one or invent your own):

A: "Acme Router AR-500 firmware 2.1 has stored XSS in the device-naming interface."

Class: Stored Cross-Site Scripting (CWE-79)
Affected: Acme Router AR-500 firmware 2.1 and earlier
Impact: an attacker on the router admin interface (post-authentication) sets the device name to a malicious script; subsequent admin sessions execute the script
CVSS estimate: medium (5.5-7.0; high integrity impact, low confidentiality)

B: "WidgetCorp IoT Sensor v3 firmware update endpoint accepts unsigned firmware images."

Class: Improper Verification of Cryptographic Signature (CWE-347)
Affected: WidgetCorp Sensor v3 firmware 5.0 to 5.3
Impact: an attacker with network access to the sensor can replace the firmware with arbitrary code; persistent compromise
CVSS estimate: high (8.0-9.5; high integrity, high confidentiality, high availability)

C: "Bookshelf BS-100 e-reader exports user reading history without authentication via /api/export."

Class: Missing Authentication for Critical Function (CWE-306)
Affected: Bookshelf BS-100 firmware 4.2 and earlier
Impact: an attacker with network access can extract any user's reading history, bookmarks, and account email
CVSS estimate: medium (6.0-7.5; high confidentiality, no integrity, no availability)

Pick one. Write the chosen hypothetical's premise in a one-paragraph summary.

Part B: Write the 12 report sections (~120 min)

disclosure-report.md:

# <Vendor> <Product> <Vulnerability-class> in <Component>

**Status:** DRAFT (Lab 9 hypothetical; not for actual disclosure)
**Researcher:** <your name>, VCA-ADV-101 cohort
**Date:** 2026-MM-DD

---

## 1. Summary

(~200 words)

The <Vendor> <Product> firmware version <X> contains <vulnerability-class>. The
vulnerability allows <impact>. Successful exploitation requires <conditions>;
exploitation has been demonstrated in an isolated lab environment using publicly
known techniques.

<Vendor> has been <notified | not yet notified>; the recommended response is
<patch / mitigation / EOL recommendation>.

The vulnerability was discovered during VCA-ADV-101 coursework on 2026-MM-DD as
part of a hypothetical-vulnerability exercise. The report follows CERT/CC and
ISO/IEC 29147 disclosure conventions.

## 2. Affected products and versions

- Product: <full product name>
- Affected versions: <firmware versions; specific>
- Unaffected versions: <if known>
- Discontinued / EOL status: <if known>

## 3. Vulnerability description

(~500 words)

### Technical mechanism

(Detailed technical description; cite CWE; cite any underlying spec or RFC if
relevant.)

### Threat model

The attacker is <position; e.g., "on the same network as the affected device" or
"authenticated as a low-privilege user">. The attack requires <conditions>. A
successful attack achieves <effect>.

### Why this is a vulnerability

<Per the CWE definition; per industry security expectations>. The expected
behavior is <X>; the observed behavior is <Y>; the gap is <Z>.

## 4. Reproduction steps

Numbered; reproducible by another researcher with the same lab environment.

1. <Step 1>
2. <Step 2>
3. <Expected response>
4. <Observed effect>

The reproduction was performed against <lab target description; authorized
hardware in an isolated lab network>.

## 5. Proof-of-concept code reference

A minimal proof-of-concept demonstrating the reproduction is at <link or
attachment>. The PoC ships with the following safety controls:

- Fingerprint-or-refuse on target identity
- `--authorized-by` argparse-required flag
- `--dry-run` default-on mode
- Per-run structured JSON audit log

The PoC does not include weaponized post-exploitation capability.

## 6. CVSS v3.1 scoring

**Vector:** `CVSS:3.1/AV:?/AC:?/PR:?/UI:?/S:?/C:?/I:?/A:?`

**Score:** X.X (Severity)

### Per-metric justification

(One paragraph per metric, as in Lab 8.)

## 7. Remediation (vendor-side)

The recommended fix is <specific>. Per <CWE category>'s standard remediation:

- <Action 1>
- <Action 2>
- <Action 3>

The fix should be deployed as a firmware update; affected operators should be
notified to install the update within <recommended window>.

## 8. Mitigation (operator-side)

Pre-patch, affected operators can reduce risk via:

- <Mitigation 1; specific>
- <Mitigation 2>
- <Mitigation 3>

These are stopgaps; they do not eliminate the vulnerability. The vendor patch
is the long-term answer.

## 9. Negative-scope statement

This report demonstrates the reproduction of the described vulnerability on an
authorized lab target. The report does NOT:

- Demonstrate post-exploitation activities (persistence; lateral movement;
  privilege escalation beyond the immediate impact)
- Chain the described vulnerability with any other vulnerability
- Identify deployed instances of the affected product in the wild
- Include weaponized exploit code beyond the minimum required to demonstrate
  the vulnerable behavior
- Modify the lab target's state in any way beyond what is documented in §4

The reproduction was conducted under written authorization (see academy cohort
authorization document; cohort <X>, signed 2026-MM-DD, counter-signed
2026-MM-DD) on academy-owned or self-purchased hardware in an isolated lab
network with no upstream connection to any production or public-Internet
infrastructure.

## 10. Disclosure timeline

- 2026-MM-DD: Researcher discovered the vulnerability during VCA-ADV-101
  coursework (HYPOTHETICAL; this is a lab exercise, not a real disclosure).
- 2026-MM-DD: (Hypothetical) Researcher notified <Vendor> via <channel>.
- 2026-MM-DD: (Hypothetical) <Vendor> acknowledged.
- 2026-MM-DD: (Hypothetical) Patch released.
- 2026-MM-DD: (Hypothetical) Public disclosure (this report).

In the actual exercise, no vendor was contacted; the timeline above is the
shape a real disclosure would follow.

## 11. References

- CERT/CC Coordinated Vulnerability Disclosure Guide:
  https://vuls.cert.org/confluence/display/CVD/
- ISO/IEC 29147:2018 Information Technology - Security techniques -
  Vulnerability disclosure: https://www.iso.org/standard/72311.html
- CVSS v3.1 Specification: https://www.first.org/cvss/v3.1/specification-document
- CWE-<your-CWE>: https://cwe.mitre.org/data/definitions/<N>.html
- (Additional references specific to the hypothetical)

## 12. Credit

This report is a Lab 9 exercise by <your name> in the VCA-ADV-101 cohort. The
hypothetical vulnerability described is invented for pedagogical purposes; any
resemblance to actual vulnerabilities in real products is coincidental.

---

*Lab 9 hypothetical CVD draft. Not for redistribution outside the cohort.*

Fill in every section with concrete content for your chosen hypothetical. The hypothetical is fictional; the writing should be as detailed as a real disclosure.

Part C: Self-review against the CVD checklist (~30 min)

Score your draft against the following 12-item checklist:

Fix any unchecked items.

Part D: Commit + portfolio (~15 min)

cd ~/adv-101/lab-9
git add disclosure-report.md
git commit -m "Lab 9: hypothetical CVD disclosure draft (CWE-<N>, hypothetical product); 12 CERT/CC sections"

cd ~/adv-101
cat >> lab-portfolio.md <<EOF

### Lab 9 session, 2026-MM-DD HH:MM

**Target:** none (paper-only; hypothetical vulnerability)
**Action:** drafted CERT/CC-grade CVD disclosure report
**Authorization basis:** paper-only; hypothetical product; no real vendor contact
**Session duration:** ~3h
**Artifacts produced:** lab-9/disclosure-report.md
**Incidents:** none
EOF
git add lab-portfolio.md
git commit -m "Portfolio: Lab 9 session entry"

Expected output / artifact

~/adv-101/lab-9/disclosure-report.md: ~2500-4000 words; all 12 CERT/CC sections present; per-metric CVSS justification; explicit negative scope; hypothetical-disclosure timeline.

What's the failure mode?

Hypothetical is too vague. "Acme Router has a vulnerability" is not enough; the reproduction steps cannot be written. Pick a specific bug class with specific affected functionality.
Reproduction steps are not actually reproducible. Even for a hypothetical, the steps must be coherent; if a peer cannot follow them, the format has failed.
Negative scope is omitted or vague. The standard items list (post-exploitation; chaining; targeting; weaponization) is the floor; omit nothing.
CVSS metrics not justified. Per-metric reasoning carries the score; a bare score in the report is not defensible.

Common pitfalls

Hypothetical too similar to a real product. "Cisco Catalyst 9300 has..." is too risky; pick a fictional name (Acme Router; WidgetCorp Sensor) or a product clearly out of scope (an end-of-life device with no current relevance).
Skipping the disclosure timeline. Hypothetical disclosures still need a timeline; it documents the format you would follow with a real vendor.
Wrong CWE. A CSRF is CWE-352; an XSS is CWE-79; an unauthenticated function is CWE-306. Cite the correct CWE; the CVE database conventions key off the CWE.
Marketing voice. "This critical zero-day affects millions of devices!" is marketing. Practitioner voice: "The vulnerability is reachable via cross-origin HTTP; the impact is configuration replacement; the affected version range is X to Y; estimated deployment is unknown."

What would a reviewer ask?

"Walk me through your reproduction steps. Could I follow them to reproduce on my own authorized lab?"
"Your negative scope excludes 'chaining with other vulnerabilities.' Why is that excluded? When would chaining be in scope?"
"The disclosure timeline shows a 30-day gap between notification and acknowledgment. Is that within CERT/CC norms? Cite."

Stretch (optional)

Write a second hypothetical disclosure. Different bug class; different product. Compare structurally with the first.
Re-write a real disclosure in your own voice. Pick a recent CERT/CC note; re-draft it in your format; compare to the original. Notice the structural differences; notice the voice differences.
Draft the vendor-acknowledgment email. If you were the vendor receiving your hypothetical disclosure, what would your acknowledgment look like? 100-200 words.
Draft the post-publication blog post. What does the researcher publish AFTER the coordinated disclosure? The disclosure report is for technical readers; the blog post is for the broader audience. Practice both registers.

Lab 9 v0.1.