// resources ⟶ disclosures
Vulnerability Disclosure Policy
Halborn’s vulnerability disclosure policy primarily addresses the following three situations:
Vulnerabilities discovered by Halborn that affect other entities
Vulnerabilities reported to Halborn that affect other entities
Vulnerabilities reported to Halborn that affect Halborn
Our CVE assignment scope includes all blockchain and Web3 products that rely on smart contracts written in Rust, Go, and Solidity as well as blockchain associated Web2 and Web3 infrastructure not covered by another CNA.
Halborn’s vulnerability disclosure policy covers all our products that do not meet one of the exclusion criteria below, except when the impact is deemed high enough that our risk-based approach would dictate otherwise.
Halborn welcomes reports from independent researchers, industry organizations, vendors, customers, and other sources concerned with product or network security.
All security issues and questions should be reported via email to the Halborn Security Team at disclosures@halborn.com. Valid submissions will be acknowledged within 24 hours and reporters will receive a more detailed response to the email within 72 hours, indicating perceived severity and the next steps in handling the report.
When we report a security issue, we ask that you provide full details of the security issue including steps to reproduce and the details of the system where the tests were conducted and a clearly defined impact.
We use CVSS version 3.1 to score vulnerabilities and consider several factors such as active exploitation, customer exposure, and public disclosure timelines while prioritizing response actions for issues.
When a security issue is identified by Halborn engineers or disclosed via the reporting process, the following steps will be taken by Halborn to notify the respective parties to fix it:
Once we have confirmed the vulnerability, we will gather all the necessary information to communicate the details to the affected party.
Halborn will try to establish initial contact with the affected vendor via email regarding the vulnerability and provide supporting documents.
If we don’t receive a response from the vendor within seven days of sending the mail, another reminder will be sent. If the vendor did not respond or refuses to acknowledge the vulnerability within 14 days from initial contact, Halborn may publicly disclose the vulnerability.
If we receive a response from the vendor, we will notify them about the date of the vulnerability disclosure that we have set.
The vendor will be allowed 90 days to provide a patch or relevant fix for the issue. If provided, then the vulnerability will be disclosed immediately following the vendor’s patch or fix release.
If a fix is not provided within the 90 day period and no response is received from the vendor, Halborn will disclose the vulnerability on the determined date.
In the event that the vendor is unable to provide a fix within the deadline, but has communicated to Halborn regarding the same, then the deadline may be adjusted. A maximum of six months of coordination will be given to the vendor for fixing the vulnerabilities. After that the vulnerability may be disclosed regardless of the fix.
The 90-day deadline mentioned above is not a hard deadline. Halborn can shorten or lengthen the deadline based on criteria like the severity of the vulnerability, ease of exploitation, etc.
Until the completion of the disclosure process, Halborn will maintain confidentiality of any communication to and from the vendor. However, we will disclose the vulnerability to the public irrespective of the vendor’s support or not.
All CVEs assigned by Halborn and its vulnerability disclosures can be found in the Halborn Disclosures Page. Only the advisories present in the security advisory will be considered as official documents.
When a security report is received involving Halborn owned or controlled systems or products, it is assigned to an owner who is responsible for evaluating, coordinating remediation, and disclosing the issue as appropriate.
The evaluation process addresses the validity, impact, and scope of the reported issue and includes a review to identify any similar issues that might be present.
Fixes are implemented as necessary
An announcement date is decided for disclosure
Prior to public announcement, all affected stakeholders are given a period of time to implement any fixes needed
For issues affecting non-Halborn products or systems we will make a good faith effort, to the extent permissible, to award credit to the reporter on our disclosures page.
For issues affecting Halborn a reward may be issued at the discretion of Halborn senior leadership. The reward will be issued primarily based on the severity of the finding, among other considerations.
To be eligible for an acknowledgement or bounty the following conditions must be met:
The vulnerability is disclosed to Halborn before it is disclosed publicly, and Halborn or the corresponding vendor are given sufficient time to fix it
The vulnerability is not disclosed to anyone else besides Halborn before it is fixed
The vulnerability is not exploited until it is fixed
We also require that reporters DO NOT:
Cause potential or actual damage to Halborn, systems, or applications.
Use an exploit to view unauthorized data or corrupt data.
Engage in disruptive testing including but not limited to DoS, fuzzing, automated scanning of cloud services, or any action that could impact the confidentiality, integrity, or availability of information and systems.
Engage in social engineering (e.g. phishing, vishing, smishing) of Halborn or other organizations’ employees or customers.
Halborn specifically prohibits any intentional behaviors that are designed to allow unauthorized device or network access, exposure of sensitive device information, or a bypass of security features or restrictions.
Vulnerabilities in Halborn’s scope include any design or implementation issue that substantially affects the confidentiality or integrity of the product and/or impacts user security. Common examples include:
Undisclosed device access methods or “backdoors”
Hardcoded or undocumented account credentials
Undocumented traffic diversion
Cross-site scripting
Cross-site request forgery
Mixed-content scripts
Authentication or authorization flaws
Server-side code execution bugs
Bypass of security feature (Bypass of AV/IPS engine)
Halborn will address any issues of this nature with the highest priority and we encourage all parties to report suspected vulnerabilities for immediate investigation.
The following vulnerability categories are considered out of scope of (unless a proven high impact is demonstrated) and will not be eligible for bounties or credit on our researcher list:
Network-level Denial of Service (DoS/DDoS) vulnerabilities.
Cross-site Request Forgery (CSRF) with low security impact (logout CSRF, etc.)
Client-side application/browser autocomplete or saved credentials
User, account or id enumeration via brute-force
Any kind of physical intrusion or social engineering attempts.
Missing Cookie flags or Missing/Enabled HTTP Headers/Methods (unless it leads directly to a security vulnerability)
Low impact Stack trace disclosures, Information disclosures and banner grabbing issues (Software and Server version disclosure etc.)
Reports that have not been validated from automated web vulnerability scanners and SSL/TLS scanners or port scanners.
Any low impact issues related to session management (i.e. concurrent sessions, session expiration, session refresh on password reset/change log out, etc.)
Vulnerabilities affecting only outdated user agents or application versions
Verbose error pages without proof of exploitability or obtaining sensitive information
Lack of SSL/TLS or SSL/TLS best practices that do not contain a fully functional proof of concept.
Incomplete or missing SPF/DMARC/DKIM records
Self-XSS
Unchained open redirects
Low impact Content Spoofing issues
UI and UX bugs (including spelling mistakes)