| name | cve-advisory |
| description | Write CVE-format security advisories following MITRE CNA operational rules and CVE Record schema. Use when publishing vulnerability disclosures, preparing coordinated disclosure documentation, or creating vendor security advisories that require CVE identifiers. |
| tags | ["security","cve","advisory","vulnerability-disclosure","mitre"] |
| triggers | ["cve advisory","vulnerability advisory","write cve","security advisory","vulnerability disclosure"] |
cve-advisory
When to Use
- Publishing a vulnerability disclosure that requires a CVE ID
- Preparing coordinated vulnerability disclosure documentation
- Creating vendor security advisories for product vulnerabilities
- Writing CERT/CSIRT advisories in standard CVE format
- Documenting vulnerabilities for submission to CVE Numbering Authorities
- Formatting findings for security advisory databases
- Requesting CVE ID assignment from a CNA
Quick Start
Basic CVE advisory structure:
# CVE-YYYY-NNNNN: [Vulnerability Type] in [Product Name]
## Summary
[Product Name] [version range] contains a [vulnerability type] in the
[component] that allows [attacker type] to [impact]. This vulnerability
has been assigned CVE-YYYY-NNNNN.
## Affected Products
- Product: [Vendor] [Product Name]
- Versions: [affected version range]
- Fixed in: [fixed version] (or "No fix available")
## Vulnerability Details
- **Type:** CWE-XXX ([CWE Name])
- **CVSS 3.1:** X.X ([Severity])
- **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
## References
- [Vendor Advisory](https://vendor.example.com/security/advisory)
- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN)
Step-by-Step Process
Step 1: Understand CVE Record Requirements
Mandatory Elements (CNA Rules v4.1.0):
| Element | Requirement | Notes |
|---|
| CVE ID | MUST have format CVE-YYYY-NNNNN | Year-based numbering |
| Affected Product | MUST identify at least one | Vendor, product, version |
| Vulnerability Type | MUST identify type | Use CWE classification |
| Description | MUST contain prose description | English required |
| Public Reference | MUST have at least one | Not CVE Record itself |
| Status | MUST be "affected" or "unknown" | Not only "unaffected" |
Optional but Recommended:
- CVSS scoring (base metrics)
- Fixed versions
- Credits (not in description)
- Workarounds/mitigations
- Timeline
- Technical details
Step 2: Write CVE Description
Description Requirements (CNA Rules 5.2):
- MUST summarize the vulnerability
- MUST NOT credit people or organizations
- MUST NOT contradict other CVE Record fields
- MUST include one English description
- MAY include descriptions in other languages
Description Template:
[Product Name] [version] [has/contains] [a/an] [vulnerability type]
vulnerability in [component/feature] that allows [attacker type] to
[impact/consequence]. [Optional: Additional technical context].
Good Description Examples:
# Example 1: SQL Injection
LibreNMS before 24.1.0 has an SQL injection vulnerability in the
device search functionality that allows authenticated attackers
to execute arbitrary SQL commands via the q parameter.
# Example 2: Remote Code Execution
Apache Log4j2 2.0-beta9 through 2.14.1 contains a remote code
execution vulnerability in the JNDI lookup feature that allows
unauthenticated attackers to execute arbitrary code via a crafted
log message.
# Example 3: Authentication Bypass
Fortinet FortiOS 7.2.0 through 7.2.6 and FortiProxy 7.2.0 through
7.2.8 contain an authentication bypass vulnerability in the
administrative interface that allows remote attackers to gain
super-admin privileges via crafted CSF proxy requests.
Bad Description Examples:
# BAD: Credits in description
A vulnerability discovered by John Smith at Security Corp...
# BAD: Too vague
A security issue exists in the application.
# BAD: No product/version
SQL injection allows data extraction.
# BAD: Contains CVE in description loop
CVE-2024-1234 is a vulnerability that references CVE-2024-1234...
Step 3: Classify with CWE
Common CWE Categories for Bug Bounty:
| Category | CWE ID | Description |
|---|
| SQL Injection | CWE-89 | SQL command injection |
| XSS Stored | CWE-79 | Cross-site scripting |
| Command Injection | CWE-78 | OS command injection |
| Path Traversal | CWE-22 | Path traversal |
| SSRF | CWE-918 | Server-side request forgery |
| XXE | CWE-611 | XML external entity |
| Deserialization | CWE-502 | Unsafe deserialization |
| Auth Bypass | CWE-287 | Improper authentication |
| IDOR | CWE-639 | Authorization bypass |
| CSRF | CWE-352 | Cross-site request forgery |
| Open Redirect | CWE-601 | URL redirection |
| Info Disclosure | CWE-200 | Information exposure |
| RCE | CWE-94 | Code injection |
| Memory Corruption | CWE-119 | Buffer overflow |
| Use After Free | CWE-416 | Use after free |
| Integer Overflow | CWE-190 | Integer overflow |
| Race Condition | CWE-362 | Race condition |
| Hard-coded Creds | CWE-798 | Hard-coded credentials |
| Weak Crypto | CWE-327 | Broken cryptography |
| Missing Auth | CWE-306 | Missing authentication |
CWE Selection Guidelines:
1. Choose most specific CWE that fits
2. If uncertain, use parent category
3. Multiple CWEs allowed if applicable
4. Link to official CWE entry
Example hierarchy:
- CWE-74 (Injection) - Parent
- CWE-89 (SQL Injection) - Specific
- CWE-564 (Hibernate Injection) - Most specific
Step 4: Format Affected Products
Product Identification Format:
{
"vendor": "Vendor Name",
"product": "Product Name",
"versions": [
{
"version": "1.0.0",
"status": "affected",
"versionType": "semver"
},
{
"version": "2.0.0",
"status": "unaffected",
"versionType": "semver"
}
]
}
Version Range Formats:
# Specific versions
Affected: 1.0.0, 1.0.1, 1.1.0
Fixed: 1.1.1
# Version ranges
Affected: >= 1.0.0, < 2.0.0
Fixed: >= 2.0.0
# All versions before fix
Affected: All versions before 3.5.2
Fixed: 3.5.2 and later
# Branch-specific
Affected: 1.x before 1.9.8, 2.x before 2.3.1
Fixed: 1.9.8, 2.3.1
# With date
Affected: Versions released before 2024-01-15
Markdown Format:
## Affected Products
| Vendor | Product | Affected Versions | Fixed Version |
| ------ | ------- | ------------------ | --------------------- |
| Apache | Log4j | 2.0-beta9 - 2.14.1 | 2.15.0 |
| Apache | Log4j | 2.15.0 | 2.16.0 (complete fix) |
Step 5: Calculate CVSS Score
CVSS 3.1 Base Metrics:
Attack Vector (AV): N=Network, A=Adjacent, L=Local, P=Physical
Attack Complexity (AC): L=Low, H=High
Privileges Required (PR): N=None, L=Low, H=High
User Interaction (UI): N=None, R=Required
Scope (S): U=Unchanged, C=Changed
Confidentiality (C): N=None, L=Low, H=High
Integrity (I): N=None, L=Low, H=High
Availability (A): N=None, L=Low, H=High
Common Vulnerability Vectors:
# Unauthenticated RCE (Critical 9.8)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
# Authenticated SQL Injection (High 8.8)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
# Stored XSS (Medium 6.1)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
# Information Disclosure (Medium 5.3)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
# Local Privilege Escalation (High 7.8)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
# CSRF (Medium 4.3)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Severity Ratings:
| Score Range | Severity |
|---|
| 0.0 | None |
| 0.1 - 3.9 | Low |
| 4.0 - 6.9 | Medium |
| 7.0 - 8.9 | High |
| 9.0 - 10.0 | Critical |
Step 6: Include Public References
Reference Requirements (CNA Rules 5.3):
1. At least one public reference REQUIRED
2. Reference MUST exist before CVE Record published
3. Reference SHOULD NOT require login
4. Reference MUST contain info about specific vulnerability
5. CVE Record itself CANNOT be only reference
6. Consider long-term availability (use Internet Archive)
Reference Types:
## References
### Vendor Advisory (Primary)
- [Vendor Security Advisory](https://vendor.example.com/security/SA-2024-001)
### Technical References
- [GitHub Security Advisory](https://github.com/org/repo/security/advisories/GHSA-xxxx-xxxx-xxxx)
- [Exploit Database](https://www.exploit-db.com/exploits/XXXXX)
### Databases
- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN)
- [MITRE CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-NNNNN)
### Patches
- [Git Commit](https://github.com/org/repo/commit/abc123)
- [Patch Diff](https://vendor.example.com/patches/security-fix.patch)
Step 7: Document Timeline
Disclosure Timeline Format:
## Timeline
| Date | Event |
| ---------- | ------------------------ |
| 2024-01-15 | Vulnerability discovered |
| 2024-01-16 | Vendor contacted |
| 2024-01-18 | Vendor acknowledged |
| 2024-02-01 | CVE ID requested |
| 2024-02-05 | CVE-2024-XXXXX assigned |
| 2024-03-01 | Patch released |
| 2024-03-15 | Public disclosure |
Alternative Format:
## Disclosure Timeline
- **Discovery:** January 15, 2024
- **Vendor Notification:** January 16, 2024
- **CVE Assignment:** February 5, 2024 (CVE-2024-XXXXX)
- **Patch Available:** March 1, 2024
- **Public Disclosure:** March 15, 2024
- **Advisory Published:** March 15, 2024
Examples
Example 1: Critical RCE Advisory
Scenario: Remote code execution in enterprise software
# CVE-2024-29847: Remote Code Execution in Ivanti EPM Agent Portal
## Summary
Ivanti Endpoint Manager (EPM) before 2022 SU6 and 2024 before 2024 SU1
contains a deserialization vulnerability in the Agent Portal component
that allows unauthenticated remote attackers to execute arbitrary code
on the EPM core server. Successful exploitation can result in complete
system compromise.
## Affected Products
| Product | Affected Versions | Fixed Version |
| ---------- | ----------------- | ------------- |
| Ivanti EPM | 2024 before SU1 | 2024 SU1 |
| Ivanti EPM | 2022 before SU6 | 2022 SU6 |
## Vulnerability Details
- **CVE ID:** CVE-2024-29847
- **Type:** CWE-502 (Deserialization of Untrusted Data)
- **CVSS 3.1:** 10.0 (Critical)
- **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
## Technical Details
The Agent Portal component processes serialized .NET objects without
proper validation. An attacker can craft a malicious serialized payload
that, when deserialized by the server, executes arbitrary code in the
context of the EPM service account.
### Attack Prerequisites
- Network access to EPM core server (default port 443)
- No authentication required
- No user interaction required
### Impact
- Remote code execution as SYSTEM
- Full compromise of EPM server
- Potential lateral movement to managed endpoints
- Access to stored credentials and certificates
## Remediation
### Immediate Actions
1. Apply vendor patch (2024 SU1 or 2022 SU6)
2. Restrict network access to Agent Portal
3. Monitor for exploitation attempts
### Indicators of Compromise
POST /AgentPortal/api/v1/deserialize
Content-Type: application/octet-stream
[Base64-encoded .NET serialized payload]
## References
- [Ivanti Security Advisory](https://forums.ivanti.com/s/article/SA-2024-001)
- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2024-29847)
- [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
## Timeline
| Date | Event |
|------|-------|
| 2024-02-12 | Vulnerability discovered |
| 2024-02-14 | Reported to Ivanti |
| 2024-03-01 | CVE-2024-29847 assigned |
| 2024-09-10 | Patch released |
| 2024-09-10 | Public disclosure |
## Credits
This vulnerability was discovered during authorized security research.
Example 2: Medium Severity Web Vulnerability
Scenario: Stored XSS in web application
# CVE-2024-12345: Stored Cross-Site Scripting in WordPress Plugin
## Summary
ProfileGrid – User Profiles, Groups and Communities plugin for
WordPress before 5.7.9 contains a stored cross-site scripting
vulnerability in the user biography field that allows authenticated
attackers with Subscriber-level access to inject malicious scripts
that execute when other users view the profile page.
## Affected Products
| Product | Affected Versions | Fixed Version |
| ----------- | ----------------- | ------------- |
| ProfileGrid | < 5.7.9 | 5.7.9 |
## Vulnerability Details
- **CVE ID:** CVE-2024-12345
- **Type:** CWE-79 (Improper Neutralization of Input During Web Page Generation)
- **CVSS 3.1:** 5.4 (Medium)
- **Vector:** CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
## Technical Details
The `pm_user_bio` field does not properly sanitize user input before
storing in the database or rendering in HTML output. JavaScript code
embedded in the biography field executes in the browsers of users
viewing the profile.
### Vulnerable Code Pattern
```php
// Vulnerable - no sanitization
$bio = $_POST['pm_user_bio'];
update_user_meta($user_id, 'pm_user_bio', $bio);
// Vulnerable - no escaping on output
echo $user_bio;
```
Proof of Concept
POST /wp-admin/admin-ajax.php
action=pm_update_profile&pm_user_bio=<script>alert(document.domain)</script>
Remediation
- Update to ProfileGrid version 5.7.9 or later
- If update not possible, use Web Application Firewall rules
- Sanitize existing user biography fields
References
Timeline
| Date | Event |
|---|
| 2024-06-15 | Vulnerability discovered |
| 2024-06-16 | Reported to vendor |
| 2024-06-20 | Vendor acknowledged |
| 2024-07-01 | Patch released (5.7.9) |
| 2024-07-08 | CVE assigned |
| 2024-07-15 | Public disclosure |
### Example 3: End-of-Life Product Advisory
**Scenario:** Vulnerability in unsupported software
```markdown
# CVE-2024-98765: Authentication Bypass in Legacy Router
## Summary
D-Link DIR-859 routers contain an authentication bypass vulnerability
in the web management interface that allows unauthenticated remote
attackers to access administrative functions. This product has reached
end-of-life status and no patch will be provided.
## Affected Products
| Product | Status | Recommendation |
|---------|--------|----------------|
| D-Link DIR-859 (all versions) | End-of-Life | Replace device |
## Vulnerability Details
- **CVE ID:** CVE-2024-98765
- **Type:** CWE-306 (Missing Authentication for Critical Function)
- **CVSS 3.1:** 9.8 (Critical)
- **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
**Note:** This CVE Record uses the "unsupported-when-assigned" tag
as the affected product no longer receives security updates.
## Technical Details
The administrative interface at `/cgi-bin/webproc` accepts requests
without session validation when specific HTTP headers are present.
### Attack Vector
```http
GET /cgi-bin/webproc?getconfig HTTP/1.1
Host: 192.168.0.1
X-Forwarded-For: 127.0.0.1
Referer: http://192.168.0.1/
Mitigation
No patch available - product end-of-life
Recommended actions:
- Replace device with supported model
- Disable remote management
- Implement network segmentation
- Use VPN for remote access
References
Timeline
| Date | Event |
|---|
| 2024-08-01 | Vulnerability discovered |
| 2024-08-05 | Vendor notified |
| 2024-08-10 | Vendor confirmed EOL, no fix |
| 2024-08-15 | CVE assigned with EOL tag |
| 2024-09-01 | Public disclosure |
## Error Handling
| Error | Cause | Resolution |
|-------|-------|------------|
| CVE ID not assigned | CNA rejected request | Provide more evidence, try different CNA |
| Description rejected | Contains credits | Remove names from description, use credits field |
| Missing reference | No public URL | Create advisory page first, then CVE Record |
| Wrong CWE | Misclassified vuln type | Review CWE hierarchy, choose parent if unsure |
| Duplicate CVE | Already assigned | Search NVD before requesting, request merge |
| Version unclear | Ambiguous affected versions | Specify exact versions or commit ranges |
| Rejected submission | Schema validation failed | Validate JSON against CVE schema 5.x |
## CVE Record JSON Format
**Minimal Valid CVE Record:**
```json
{
"dataType": "CVE_RECORD",
"dataVersion": "5.0",
"cveMetadata": {
"cveId": "CVE-2024-XXXXX",
"assignerOrgId": "org-uuid-here",
"state": "PUBLISHED"
},
"containers": {
"cna": {
"affected": [
{
"vendor": "Vendor Name",
"product": "Product Name",
"versions": [
{
"version": "1.0.0",
"status": "affected"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Vulnerability description here."
}
],
"problemTypes": [
{
"descriptions": [
{
"type": "CWE",
"cweId": "CWE-79",
"description": "Cross-site Scripting (XSS)"
}
]
}
],
"references": [
{
"url": "https://example.com/advisory"
}
]
}
}
}
Tool Reference
| Resource | Description |
|---|
| CVE Services API | Official CVE submission interface |
| CVSS Calculator | FIRST CVSS 3.1 calculator |
| CWE Database | Weakness enumeration reference |
| NVD | National Vulnerability Database |
| CVE JSON Schema | Official record format specification |
| CNA List | CVE Numbering Authority directory |
Requesting CVE IDs
Finding Appropriate CNA:
1. Product vendor (if they are a CNA)
2. Bug bounty platform (HackerOne, Bugcrowd)
3. GitHub (for GitHub-hosted projects)
4. MITRE (CNA of Last Resort)
5. CISA (critical infrastructure)
Request Process:
1. Verify vulnerability exists
2. Check no CVE already assigned (search NVD)
3. Identify appropriate CNA
4. Submit request with:
- Affected product/version
- Vulnerability type
- Impact description
- Proof of concept
- Public reference (or commitment to create one)
5. Wait for assignment (typically 72 hours)
6. Publish CVE Record within 72 hours of disclosure
References
