Vulnerability Descriptions
A structured collection of vulnerability descriptions I use during penetration testing, red team operations, and reporting. This section helps standardize findings, improve clarity in communication, and ensure consistency in deliverables.
Vulnerability Descriptions Overview
Clear and consistent vulnerability descriptions are a cornerstone of effective penetration testing and red team reporting. A well-written description not only documents the technical weakness but also communicates the business impact, risk level, and recommended remediation in a way that both technical and non-technical stakeholders can understand.
This section serves as a curated notebook of vulnerabilities I frequently encounter, categorized by type, with standardized writeups that can be adapted to specific engagements.
Why Standardized Descriptions Matter
When performing security assessments, consistency in reporting is just as important as technical accuracy. Standardized vulnerability descriptions provide:
- Clarity for Stakeholders – Non-technical audiences understand the risk.
- Efficiency in Reporting – Faster creation of deliverables by reusing templates.
- Consistency Across Engagements – Avoids discrepancies in how similar findings are described.
- Alignment with Standards – Mapped to CVSS, CWE, and MITRE ATT&CK for better integration.
Reporting is Part of the Exploit Chain
A vulnerability assessment is only as good as the report it produces. Clear descriptions ensure that findings don’t just get discovered—they get understood, prioritized, and fixed.
Structure of a Vulnerability Entry
Each vulnerability description follows a modular structure:
- Title – Short, descriptive name (e.g., SQL Injection in Login Form).
- Description – Clear explanation of the weakness and how it manifests.
- Impact – Business and technical consequences of successful exploitation.
- Proof of Concept (PoC) – Minimal reproducible example, where applicable.
- References – Links to CVEs, CWEs, advisories, or vendor documentation.
- Remediation – Practical, prioritized steps to fix the issue.
- Severity – CVSS v3/v4 score, qualitative risk rating (Low/Medium/High/Critical).
Example Categories
-
Web Application Vulnerabilities
- SQL Injection (CWE-89)
- Cross-Site Scripting (CWE-79)
- Insecure Direct Object References (CWE-639)
- Cross-Site Request Forgery (CWE-352)
-
Infrastructure & Network Vulnerabilities
- SMB Signing Disabled
- Weak TLS/SSL Configurations
- Open SSH Ports with Default Credentials
- Exposed Management Interfaces
-
Privilege Escalation
- Misconfigured Sudo Permissions
- Kernel Exploits (Dirty COW, Dirty Pipe, etc.)
- Insecure Service Permissions
-
Cloud & Container Vulnerabilities
- Publicly Accessible S3 Buckets
- Overly Permissive IAM Roles
- Insecure Kubernetes RBAC Configurations
Methodology-First Approach
Vulnerability descriptions are not just about documenting what’s broken—they’re about telling the story of risk. In practice, this means:
- Always linking vulnerabilities to attack paths (how an attacker would chain them).
- Showing business relevance (data exfiltration, financial fraud, compliance gaps).
- Providing actionable remediation steps tailored to the environment.
Final Thoughts
This section is a living reference that evolves as new vulnerabilities emerge and reporting standards change. By maintaining a standardized approach, I can accelerate reporting while ensuring findings remain accurate, understandable, and impactful.
Last updated on
Sliver C2 Cheatsheet
A complete and practical cheatsheet for Sliver, the open-source Command and Control (C2) framework used by red teams and penetration testers for secure post-exploitation, beaconing, and multi-platform payload delivery.
Host Header Poisoning
How Host Header Poisoning vulnerabilities allow attackers to manipulate HTTP Host headers for password reset poisoning, cache poisoning, SSRF, and authentication bypass attacks.