We take the security and privacy of customer data seriously. If you discover a security vulnerability in Nolt, we welcome your report and appreciate the opportunity to investigate it.
This program covers security vulnerabilities, not ordinary product bugs. A product defect, unexpected behavior or UI inconsistency does not automatically qualify for a bounty award.
Effective November 1, 2026, Low-severity and Informational reports are no longer eligible for bounty awards. Reports received before this date will be assessed under the terms that applied when they were submitted.
How to report a vulnerability
Send your report to security@nolt.io, and keep any follow-ups in the same email thread.
Please include:
- A short introduction, your security-testing background, and whether you work independently or for a company.
- Links to any public profiles you maintain on platforms such as GitHub, LinkedIn, HackerOne or Bugcrowd.
- The affected feature or endpoint, including the account roles, permissions and board settings needed to reproduce the issue.
- Clear reproduction steps, relevant requests and responses, and a minimal proof of concept.
- An explanation of the expected behavior, what happened instead, and the security impact you demonstrated.
- A proof of concept (PoC) demonstrating the issue and its security impact, with screenshots or a video where helpful.
Public profiles help us understand your background, but they do not replace technical evidence. Please redact credentials, session tokens and customer information before submitting your report.
AI-generated and automated submissions
We receive a high volume of AI-generated and automated reports. Untested or generic AI-generated submissions, fabricated evidence and unvalidated scanner output are automatically ineligible for bounty awards.
You are responsible for verifying your findings and the accuracy of every claim. A convincing description or a list of possible consequences is not a substitute for a reproducible, Nolt-specific issue.
What qualifies as a security vulnerability?
A qualifying report must demonstrate a meaningful security impact—for example, accessing protected information, performing an unauthorized action or executing code in another user’s session.
The following observations do not establish a security vulnerability on their own:
- A button or setting is hidden in the interface but its API operation remains available.
- An endpoint accepts a request or returns HTTP 200.
- Public identifiers, GraphQL operation names or schema definitions are discoverable.
- A user can manage resources they already own or are authorized to control.
- The application behaves differently from what the researcher expected.
We assess the intended permissions, the requester’s existing access and what the finding actually allows them to do.
A safe proof of concept using your own accounts and test data is sufficient. Do not access customer data or cause harm to strengthen a report.
Bounty eligibility and awards
Only verified Moderate- or High-severity security vulnerabilities may be considered for bounty awards.
You must be the first person to submit a sufficiently detailed, reproducible report of the issue. Reporting order is based on when Nolt received the report—not a document’s creation date or the date the issue was discovered.
Duplicates, known issues and issues already fixed before receipt are not eligible for additional bounty awards. Different endpoints or reproduction paths may be assessed together when they share the same underlying vulnerability.
Bounty awards are discretionary. Our final assessment considers:
- The demonstrated security impact and affected scope.
- Exploitability, required privileges and user interaction.
- Whether the finding is new and independently actionable.
- The accuracy, clarity and reproducibility of the report.
There is no fixed bounty amount attached to a severity label. Acknowledging a report, confirming a bug or assigning an initial severity does not guarantee an award.
Initial assessments may change as we investigate. We will explain the outcome and any material changes to our preliminary assessment.
Potentially eligible findings
Moderate-severity examples include:
- Authentication or authorization bypasses with meaningful, limited-scope impact.
- Unauthorized actions affecting another account or board.
- SSRF or CSRF with demonstrated security impact.
High-severity examples include:
- Stored XSS affecting another user’s session.
- Unauthorized access to protected customer data.
- Account takeover or broad privilege escalation.
- SQL injection, remote code execution or SSRF presenting immediate, direct security risks.
These examples are guidance, not automatic severity classifications or award commitments.
Review priorities and response times
We triage all submissions. Credible high-severity reports are flagged for immediate investigation and prioritized remediation.
Low-severity, Informational and practically inconsequential findings enter a lower-priority queue. A substantive response to these reports may take up to three months. Reviewing or fixing an issue does not, by itself, make it bounty-eligible.
For example, a minor permission inconsistency involving an already-trusted role, such as a board Moderator, may be assessed as Low severity where its practical impact is negligible. The role alone does not determine severity—we consider the unauthorized access or control actually gained.
Reports that do not qualify
The following are not eligible for bounty awards:
- Low-severity and Informational reports submitted on or after November 1, 2026.
- Ordinary product bugs, feature requests or workflow inconsistencies without meaningful security impact.
- Fabricated, untested or generic AI-generated reports and unvalidated scanner output.
- Duplicate reports, known issues and issues already fixed before receipt.
- Spam, social engineering, content spoofing, misleading links or brand-abuse scenarios without an independently demonstrated technical vulnerability.
- Public API introspection, operation names or identifiers without an authorization bypass or protected-data exposure.
- Self-XSS that cannot affect another user’s session.
- Denial-of-service, resource-exhaustion or brute-force attacks.
- Attacks requiring physical access, malicious browser extensions or an already-compromised device.
- Missing security headers, SSL/TLS observations, password-policy suggestions, version disclosure or file-path disclosure without demonstrated exploitable impact.
- CSRF without meaningful unauthorized impact, such as logout-only CSRF.
- Vulnerabilities in third-party applications or services not operated by Nolt.
- Legacy-browser-only exploits or newly published third-party vulnerabilities without verification that Nolt is affected.
Responsible testing
Use accounts, boards and data you own or are explicitly authorized to test. Do not disrupt production, send unsolicited messages, access another customer’s information, or modify or destroy other users’ data.
If you unexpectedly encounter customer information, stop testing and notify us immediately. Do not download or retain additional information.
Coordinated disclosure
Keep vulnerability details confidential while we investigate and address the issue.
Before publishing a write-up or proof of concept, coordinate with our security team and wait for written confirmation that the relevant fixes are fully deployed. Do not publish unresolved vulnerability details on Nolt’s public feedback boards.
Thank you for helping us protect Nolt and its users.