Can I disclose a vulnerability publicly?
Yes, you can disclose vulnerabilities publicly.
Please use these guidelines when preparing a public write-up of a vulnerability you discovered and disclosed to our organization.
Disclosure Timing
- Do not publish any details of the vulnerability until we have confirmed remediation or granted explicit written permission.
- If you wish to publish after remediation but before receiving explicit permission, please coordinate with us to agree on a safe publication date.
Redaction of Sensitive Information
- Do not include:
- Proprietary or user data
- Internal system identifiers (e.g., production IPs, hostnames)
- Authentication credentials, session tokens, or cookies
- Anonymize or mask any details that could allow reproduction on live systems.
- Example: * Replace real IP addresses with placeholders like `10.0.0.1`, and mask usernames or tokens with `[REDACTED]`.
- Ensure PoCs and screenshots do not contain any personally identifiable information (PII) or sensitive data, even if redacted.
Write-Up Structure
We recommend the following structure for your write-up. Use clear formatting (such as Markdown or plain text) for readability.
Title: [Vulnerability Title]
Author: [Your Name or Alias]
Date Reported: [YYYY-MM-DD]
Date Resolved: [YYYY-MM-DD]
Scope: [General description of the asset or system affected]
Vulnerability Type: [e.g., Cross-Site Scripting (XSS)]
Summary: A brief description of the vulnerability and its impact.
Steps to Reproduce: Safe, redacted, and non-destructive steps to demonstrate the issue. Avoid including any steps that could disrupt production systems.
Impact: Describe what a malicious actor could achieve if the vulnerability were exploited.
Root Cause: A high-level explanation of the underlying flaw (e.g., improper input validation).
Remediation: Describe the fix implemented or recommended (e.g., code patch, configuration change) and/or best practices.
Timeline: Report submitted: [Date] Acknowledged: [Date] Resolved: [Date] Permission to publish: [Date]
References: List any relevant external resources, advisories, CVEs, or CWEs.
Acknowledgments: University of Nebraska.
Summary: A brief description of the vulnerability and its impact.
Steps to Reproduce: Safe, redacted, and non-destructive steps to demonstrate the issue. Avoid including any steps that could disrupt production systems.
Impact: Describe what a malicious actor could achieve if the vulnerability were exploited.
Root Cause: A high-level explanation of the underlying flaw (e.g., improper input validation).
Remediation: Describe the fix implemented or recommended (e.g., code patch, configuration change) and/or best practices.
Timeline: Report submitted: [Date] Acknowledged: [Date] Resolved: [Date] Permission to publish: [Date]
References: List any relevant external resources, advisories, CVEs, or CWEs.
Acknowledgments: University of Nebraska.
Proof of Concept (PoC) Restrictions
- Only include redacted or simulated payloads.
- Do not include scripts, URLs, or code that target our live systems.
- Do not submit executable files, malware samples, or any content that could be weaponized.
- Ensure PoCs do not contain any PII or sensitive data.
Coordination and Review
- Submit a draft of your write-up to us prior to publication.
- We may request adjustments to remove sensitive or proprietary information.
- Please allow up to 10 business days for our review and feedback before publishing.
Legal and Ethical Compliance
- Ensure your write-up only reflects testing performed within the authorized scope and in accordance with the VDP rules of engagement.
- Do not describe or reference any unauthorized access or disruptive actions.
For questions or to submit your write-up draft, please refer to the contact information provided in the main VDP documentation.