The University of Nebraska is committed to ensuring that all academic, research, and service activities are carried out in the safest way, guaranteeing the confidentiality, integrity and availability of the information. The University of Nebraska Vulnerability Disclosure program is an experimental program aiming to improve UN's online security, intended to give security researchers clear guidelines for conducting vulnerability discovery activities and to convey our preferences in how to submit discovered vulnerabilities to us. Here you will find information about what systems and types of research are covered, how to send us vulnerability reports, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.
We encourage you to contact us to report potential vulnerabilities in our systems.
The primary source for this document is the Department of Homeland Security's Vulnerability Disclosure Policy Template.
Authorization
If you make a good faith effort to comply with this document during your security research, we will consider your research to be authorized we will work with you to understand and resolve the issue quickly, and University of Nebraska will not recommend or pursue legal action related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this document, we will make this authorization known.
Guidelines
In this program "research” means activities in which you:
- Notify us as soon as possible after you discover a real or potential security issue.
- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
- Only use exploits to the extent necessary to confirm a vulnerability’s presence. Do not use an exploit to compromise or exfiltrate data, establish persistent command line access, or use the exploit to pivot to other systems.
- Provide us with a reasonable amount of time to resolve the issue before you disclose it publicly.
- Do not submit a high volume of low-quality reports.
Once you’ve established that a vulnerability exists or encounter any sensitive data (including personally identifiable information, financial information, or proprietary information or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else.
Test methods
The following activities are not authorized:
- Network denial of service (DoS or DDoS) tests or other tests that impair access to or damage a system or data
- Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing
- Any activity related to university medical data or services is prohibited and could result in disciplinary/legal actions.
- Local network-based exploits such as DNS poisoning or ARP spoofing
- Social engineering
Scope
This program is limited only to following systems and services:
- *.nebraska.edu
- *.unk.edu
- *.unl.edu
- *.unomaha.edu
In-Scope vulnerabilities
- Remote Code Execution (RCE)
- SQL injection
- XML External Entity Injection (XXE)
- Authorization bypass/escalation
- Sensitive information leaks that expose private user data, credentials, or internal secrets (excluding public metadata such as software versions).
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
Out-of-Scope vulnerabilities
1. Third-Party Software Vulnerabilities
- Vulnerabilities in software we do not control or maintain.
- Example: Lack of verification for account deletion in Mailman.
- Exception: If the issue results from our misconfiguration, it may be in scope.
2. Issues That Do Not Pose a Real Risk to Users
- Theoretical vulnerabilities without practical exploitability.
- Example: Self-XSS requiring user interaction.
3. Denial of Service (DoS) & Rate-Limiting Issues
- DoS vulnerabilities, excessive requests, or missing rate limits unless explicitly in scope.
- Example: Lack of rate limiting on login forms without a proven exploit.
4. Content Spoofing & Clickjacking
- Clickjacking reports with no real security impact.
- Example: Clickjacking on a static page.
5. Best Practices & Missing Security Headers
- Reports on missing headers that do not expose sensitive data.
- Example: Lack of
X-Frame-Optionson an informational page.
6. Social Engineering & Phishing
- Attacks requiring social engineering.
- Example: Convincing support to change an account email.
7. Deprecated or Non-Operational Assets
- Vulnerabilities in retired or inactive services.
- Example: Outdated documentation sites.
8. Non-Exploitable Information Disclosure
- Publicly available information without security risk.
- Example: Exposed software version in HTTP headers.
9. Lack of Security Best Practices Without Exploitability
- Reports suggesting security improvements without a direct exploit.
- Example: Use of outdated libraries with no known vulnerabilities.
10. Low-Impact CSRF Issues
- CSRF affecting non-sensitive actions.
- Example: CSRF on profile picture update.
11. Vulnerabilities in User-Supplied Content
- Abuse of user-generated content without security risks.
- Example: A user posting misleading URLs.
12. Attacks Requiring Physical Access
- Exploits requiring physical access to a device.
- Example: Extracting credentials from an unlocked device.
13. Automated Scanner Reports Without Manual Verification
- Reports generated solely by automated tools without proof of exploitability.
- Example: Scanner detecting an "information disclosure" issue with no impact.
14. Lack of Email Security Features
- Reports on missing SPF, DKIM, or DMARC unless they enable phishing attacks.
- Example: Missing DMARC policy without phishing risk.
15. Account Enumeration on Public Interfaces
- Username or email existence checks unless they have security consequences.
- Example: Finding if an email exists via password reset.
16. Bugs Without Substantial or Demonstrable Security Risk
- Any bug that does not pose a substantial or demonstrable security risk is considered out of scope.
- Example: Cosmetic UI issues that do not affect functionality or security.
17. Public Exposure of Budgets, Salaries, or Personnel Rosters
- Any vulnerabilities related to the public exposure of employee salaries, rosters, or similar sensitive internal information are considered out of scope, unless they result in a direct security risk.
- Example: Exposure of staff rosters or salary data on public-facing pages without proper access control mechanisms.
18. Other Methods Not Authorized in 'Test Methods'
- Any testing methods not explicitly authorized or listed in the "Test Methods" section of the bug bounty program are considered out of scope.
- Example: Physical access to servers, social engineering, or using attacks not allowed by the program (e.g., brute forcing, exploiting third-party services, etc.).
Reporting a vulnerability
- We accept vulnerability reports via its-sec@nebraska.edu.
- Reports may be submitted anonymously.
- If you share contact information, we will acknowledge receipt of your report within 3 business days.
- We do not support PGP-encrypted emails.
What we would like to see from you
In order to help us triage and prioritize submissions, we recommend that your reports:
- Describe the location where the vulnerability was discovered and the potential impact of exploitation.
- Offer a detailed description of the steps needed to reproduce the vulnerability (proof of concept scripts or screenshots are helpful).
- Be in English, if possible.
What you can expect from us
- When you choose to share your contact information with us, we commit to coordinating with you as openly and as quickly as possible.
- Within 3 business days, we will acknowledge that your report has been received.
- To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about what steps we are taking during the remediation process, including on issues or challenges that may delay resolution.
- We will maintain an open dialogue to discuss issues.
Rewards & Recognition
While we currently do not offer monetary rewards, we are pleased to recognize your efforts by featuring your name in our Hall of Fame, commemorating your contribution to our organization's security efforts, and granting digital badges as a reward for the perseverance and quality of the reports.
Each vulnerability will receive a score based on its severity and impact:
| Criticality | Score |
| Info | 25 |
| Low | 100 |
| Medium | 250 |
| High | 500 |
| Critical | 1000 |
Vulnerability reports that are not eligible because they are out-of-scope or were already reported, will be classified as “Info” and eligible for public acknowledgment if they represent a high-quality security research submission.
We align with Bugcrowd Vulnerability Rating Taxonomy as a reference for classification and severity.
The points are cumulative and will be used to determine the level of recognition in the Hall of Fame and granting digital badges based on the following levels:
| Rank | Score | Recognition |
|
Initiate |
25+ |
Hall of Fame |
|
Explorer |
100+ |
Explorer Digital Badge |
|
Adventurer |
2,500+ |
Adventurer Digital Badge |
|
Vanguard |
5,000+ |
Vanguard Digital Badge |
|
Champion |
10,000+ |
Champion Digital Badge |
|
Hero |
15,000+ |
Hero Digital Badge |
|
Legend |
20,000+ |
Legend Digital Badge, Printed Certificate, & NU Security Challenge Coin |
Questions
Questions regarding this policy may be sent to its-sec@nebraska.edu. We also invite you to contact us with suggestions for improving this policy.
Hall of Fame
On behalf of our students, all University Staff and especially our IT crew, we would like to express our gratitude to the following people for making a responsible disclosure to us and helping make University of Nebraska services more secure.
2021
- Nayanjyoti Roy ★
2023
- Gaurang Maheta ★
2024
- Kishan Shah ★
- Aashutosh Devkota ★★
- Veshraj Ghimire ★
- Rajan Kshedal ★★
2025
- Pedro Paulo (0xPedrop) ★
- Kursad Alsan ★x9
- Eslam Abu Bakr ★★
- Siddu Mulkalla (saikumar andure) ★★★
- Tolkien Urinbaev ★★
- Hamim Hossain (Hamim404) ★x17
- Srijan Adhikari ★
- Paavan Jogula ★
- Ngô Sỹ Tuấn ★
- William Bastos ★x7
- Samara Gama (IgobySamy) ★★★
- Mogtaba Basim ★
- Abdul Rahman Nofal ★
- Joshua Ingya ★
- Brenno Oliveira ★
- Kanala Sai Gowtham Reddy ★
- Dror Peleg ★★★
- Vaibhav Jain ★★★
- Pallavi Pandey ★x6
- Naitik Gupta ★★
- Ali Raza ★
- Miguel Segovia Gil ★★★