Security, vulnerability disclosure, and bug bounty policy
Report a vulnerability, check research scope and testing rules, and understand response targets, severity, rewards, and safe harbor.
Last revised: October 23, 2026
Anyone can report a suspected vulnerability to bugs@solarius.me. Include enough detail to explain the affected system, reproduce the issue safely, and assess its impact.
This policy covers Solarius B.V. ("Solarius"), its supplied software, and systems it operates. Live testing requires written authorization; rewards require a written bounty arrangement. A report alone grants neither permission nor payment eligibility.
Product agreements, accepted testing scopes, data-processing agreements (DPAs), and mandatory law retain their stated precedence. This policy does not create a general support or availability commitment.
Scope of systems
Check both who controls the system and what your authorization covers:
| System or activity | Applicable scope |
|---|---|
| Solarius-operated websites, applications, APIs, and infrastructure | Reports are welcome. Live testing is limited to the assets and methods expressly authorized in writing. |
| Software supplied by Solarius | Local analysis requires a valid license and authority over the isolated test environment. |
| Customer workloads, employee accounts, and other customers' data | Excluded unless the party entitled to authorize the activity separately agrees. |
| Third-party services, integrations, hosting platforms, and contractor-operated systems | Their operators' permissions and disclosure rules apply, including when reached through a Solarius-branded address. |
A domain, IP address, certificate, redirect, repository, or paid account is not testing permission. Acquired services, unnamed assets, and additional products need express inclusion in your authorization.
Guard customer assessments follow separate rules of engagement and do not authorize testing Solarius or other customers. Local analysis does not authorize production traffic.
Report a vulnerability
Email the report promptly. Include the following information:
- Affected asset: product, URL, endpoint, parameter, hostname, or software version.
- Observation time: date and time in UTC.
- Prerequisites: required access, configuration, privileges, and user interaction.
- Reproduction: minimal steps, expected behavior, and observed behavior.
- Impact: the data, account, tenant boundary, or service function at risk and a realistic attack scenario.
- Evidence: a small redacted proof of concept, request and response, screenshot, or relevant source reference.
- Confidence: which results you reproduced, inferred from source, or obtained from a tool.
- Contact: a safe reply address for questions and coordination.
Exclude passwords, tokens, customer datasets, and unrelated personal information. Request a secure channel for necessary sensitive evidence.
If another person's data appears, stop and report the location and circumstances. Do not collect, retain, modify, or share more records to prove scale. Request handling and deletion instructions for accidental captures, subject to binding preservation duties.
Send ordinary defects, recovery, billing, and service complaints to help@solarius.me. Active compromise also requires incident reporting. Solarius routes misdirected reports without unnecessary resubmission of sensitive evidence.
Research authorization
Before live testing, obtain written approval from bugs@solarius.me. Approval must identify:
- The researcher, approved collaborators, test accounts, and exact assets and environment.
- Permitted methods, privilege limits, data boundaries, and required third-party permissions.
- Testing dates, time zone, request-rate limits, and concurrency limits.
- Emergency contacts, stop conditions, and the person authorized to approve changes.
Do not transfer or extend permission beyond its approved scope, people, or period. Request designated test accounts if eligibility or account-count limits prevent an authorized test.
Use synthetic data and the minimum privileges and requests needed. Interact only with accounts you control or have explicit permission to use. Stop when the agreed proof is established, authorization ends or is withdrawn, a stop instruction arrives, an unexpected boundary is crossed, sensitive data appears, or the service becomes unstable.
Report outstanding requests and residual effects after stopping. Resume only with written approval. Revocation does not invalidate earlier compliant work.
Prohibited testing
The following methods are prohibited in ordinary vulnerability and bounty research:
- Denial-of-service (DoS), distributed denial-of-service (DDoS), flooding, amplification, stress testing, resource exhaustion, and attempts to find a service's breaking point.
- Brute force, credential stuffing, password spraying, stolen credentials, phishing, social engineering, and physical intrusion.
- Destructive changes, persistence, lateral movement, disabling logs or safeguards, and extraction of production datasets.
- Spam, notification bombing, uncontrolled account creation, purchases, fund transfers, or billing changes used to demonstrate impact.
- Automated scanning outside approved targets or traffic limits, including work performed by a hosted tool or collaborator.
Exceptional methods require separate professional-engagement approval covering affected owners, containment, recovery, and stop conditions. Use source analysis or bounded isolated tests for suspected availability defects.
Financial transaction testing
Use a sandbox, test payment method, or synthetic transaction when available within the approved scope. Live purchases, transfers, refunds, cancellations, or billing changes require separate express approval before testing.
Approval must specify accounts, transaction values, volume, provider permissions, and cleanup. Use minimal values and volume; avoid repeated payment and cancellation cycles. Severity reflects the failure and potential impact, regardless of amount spent. Cost reimbursement requires prior agreement.
Eligible vulnerabilities
Reports should identify a technical weakness with a credible confidentiality, integrity, availability, or access-control impact. Examples include:
- Authentication bypass, privilege escalation, account takeover, or cross-tenant access.
- SQL injection, command injection, or unintended code execution.
- Cross-site scripting (XSS) or cross-site request forgery (CSRF) affecting sensitive data or actions.
- Directory traversal, unintended file access, or exploitable misconfiguration.
- Exposure of secrets or protected data, or an exploitable dependency in the supplied product.
Use safe evidence within your authorization. A reportable issue does not authorize live exploitation or compromise of another person's account.
Out-of-scope and ineligible reports
The following reports do not qualify for a bounty or substantive investigation as submitted without demonstrated additional security impact:
| Report | Missing evidence or scope requirement |
|---|---|
| Unreviewed scanner or AI output, generic checklists, or unverifiable claims | A verified affected asset, boundary, and technical explanation. |
| Missing headers, cookie flags, TLS settings, email-authentication records, or DNS best practices | A working explanation of exploitability beyond a preferred configuration. |
| Version banners, source maps, internal paths, descriptive errors, or public metadata | Exposure of a secret, protected data, or an exploitable path. |
| A dependency CVE or outdated package | Evidence that the affected behavior is present and reachable. |
| Self-XSS, developer-console pasting, or access the victim expressly grants | An additional victim or privilege boundary. |
| Nonsensitive clickjacking, harmless redirects, logout-only CSRF, or harmless CORS and cache behavior | A material unauthorized action or protected-data consequence. |
| Rate-limit or enumeration observations | A credible account, privacy, or other material boundary failure. |
| Volumetric DoS/DDoS, load benchmarks, or finite-capacity observations | Disruptive testing is prohibited; ordinary capacity limits are not bounty findings. |
| Unsupported versions or browsers, unauthorized modifications, or independently operated third-party services | Inclusion in the accepted product and research scope. |
| Cosmetic defects, feature or support requests, duplicates, or materially identical known issues | A new eligible security finding. |
Exposed secrets, exploitable dependencies, takeover chains, cross-tenant cache leaks, and single-request availability defects can warrant assessment. Explain the impact safely; reassessment grants neither exploitation permission nor guaranteed payment.
Junk, misleading, and abusive submissions
After requesting necessary clarification, Solarius can close reports without an identifiable asset, reproducible result, or verifiable source explanation. Fabrication, irrelevant copied reports, severity inflation, repetitive templates, malicious attachments, and payment demands before assessable detail can be rejected or restricted.
AI-assisted or automated report preparation is not itself a reason for rejection. You remain responsible for accuracy, provenance, scope, and verification, and all testing limits still apply. Good-faith mistakes are not abuse. Solarius can consolidate duplicates and restrict repeated manifest abuse after appropriate warning, while preserving routes for material new evidence and protected reports.
Triage, duplicates, and review
Solarius uses the following administration targets:
| Stage | Target |
|---|---|
| Acknowledgement | Within 5 business days of a sufficiently identified report. |
| Initial assessment | Within 10 business days after receiving the necessary information. |
| Progress updates | At least every 15 business days during active coordination, including when there is no material change. |
Business days exclude weekends and Dutch public holidays and use Europe/Amsterdam time. These targets are separate from remediation deadlines. Credible evidence of critical exploitation receives incident escalation even if no bounty is available.
Solarius evaluates good-faith reports, requests necessary clarification, and assigns validated weaknesses an owner and correction or mitigation plan. Reporter identities and evidence receive restricted handling under the Privacy Policy. Public attribution requires your permission; any legally required disclosure follows the applicable government-request safeguards.
The first actionable report normally receives priority for the same root defect and scope. Empty placeholders do not establish priority. A fix bypass or distinct material boundary can qualify separately. Solarius explains duplicates without exposing other researchers' information. Do not split or withhold facts to manufacture awards.
Follow up in the original thread with the report reference. Escalate an unacknowledged report or disputed decision to legal@solarius.me. Submit an ordinary bounty review request within 30 calendar days; later material evidence remains reviewable. The response must explain the outcome against the accepted scope and evidence.
Vulnerability scoring
Assessment considers the following factors:
- Attack reachability, required privileges, complexity, and user interaction.
- Confidentiality, integrity, and availability impact.
- Affected users, data sensitivity, tenant boundaries, and deployed configurations.
- Effective controls, realistic exploit chains, and evidence of exploitation.
Include the version and vector with any Common Vulnerability Scoring System (CVSS) score. Solarius explains its severity assessment using actual product exposure. A proposed score or scanner rating does not determine acceptance, payment, or remediation deadlines.
Bounty eligibility and awards
Rewards require an active written invitation, campaign schedule, or confirmed individual arrangement specifying participants, targets, dates, methods, and award basis. There is no universal public rate or minimum award. Receipt, triage, remediation, and severity discussions are not payment approval.
Participants need lawful capacity and permission to research and receive payment; minors need an expressly permitted guardian arrangement. Findings from assigned Solarius work require separate reward approval for employees, contractors, and advisers. Stolen access or research, concealed confidentiality breaches, and participation in abuse do not establish eligibility.
Findings must meet accepted scope, evidence, safety, and disclosure conditions. Solarius shall honor qualifying fixed rewards. Discretionary awards become payable on communicated approval and cannot override accepted fixed entitlements. Expenses require prior reimbursement agreement.
Award notices identify the report, decision, amount, currency, recipient or team split, payment route, lawful verification, and processing time. Solarius aims to initiate payment within 30 calendar days of receiving necessary tax and payment details, explaining material legal or provider delays.
No participation deposit, subscription purchase, or payment-release fee is required. Payment verification does not prevent submission of a technical report. Declining publicity does not reduce an earned reward. A valid award is not revoked because the issue later seems less commercially important; erroneous duplicate payments remain recoverable lawfully.
Reasonable reward questions are permitted. Threats of unlawful disclosure, continued intrusion, or disruption to obtain payment are prohibited.
Disclosure, evidence, and authorized-research protection
Coordinated disclosure
Agree a publication date and customer protections during coordination. Without a specific agreement, Solarius proposes up to 90 calendar days from a sufficiently detailed report. Active exploitation or material exposure can justify earlier warnings. Extensions need an explained dependency and a renewed date; coordination is not an indefinite publication veto or a restriction on legally protected reports to authorities.
Exclude customer information, live credentials, and unnecessary protected evidence from public material. Do not upload confidential proof to public services, general-purpose model providers, or unauthorized collaborators. If direct coordination fails, you can contact a competent coordinator.
You retain independent research ownership. Submission permits Solarius to use the report and proof for investigation, correction, validation, customer protection, and coordinated advisories. This limited, nonexclusive permission remains subject to confidentiality, personal-data restrictions, and agreed disclosure conditions. Unrelated IP and publicity rights remain yours. Sensitive evidence follows the Privacy Policy and agreed retention or deletion instructions.
Safe harbor
For expressly authorized, materially compliant research, Solarius shall not initiate civil proceedings or request criminal enforcement solely because of that work. Solarius can lawfully confirm its authorization to relevant third parties.
To qualify, you must:
- Stay within the approved assets, accounts, methods, dates, and traffic limits.
- Avoid privacy violations, disruption, destructive changes, and unnecessary data access or retention.
- Stop and report unexpected access, sensitive data, instability, or loss of permission promptly.
- Use findings only for authorized validation, reporting, and coordinated correction.
- Follow the reporting and disclosure conditions without threats or demands for payment as a condition of disclosure.
Solarius assesses promptly reported accidental deviations by intent, harm, cessation, and cooperation. Manually verified findings from automated tools are assessed under the same rules. Discovery of an issue outside scope is reportable, but does not authorize further testing of that system.
Written testing authorization takes precedence over conflicting ordinary service restrictions only for approved work within Solarius's authority. This protection binds Solarius, not authorities or third parties. It grants no criminal immunity or permission for third-party systems and excludes deliberate misuse and continued testing after a stop instruction.
Program changes
Program changes and closure apply prospectively. They do not remove earned award rights or protections for compliant work conducted under the applicable earlier terms. Accepted agreements and mandatory law govern any amendment that affects contractual rights.
Security updates and supported versions
Validated weaknesses receive an owner and risk-based correction or mitigation plan. Priority reflects exploitation, exposure, prerequisites, data, service impact, and temporary controls. Contractual and legal deadlines control; no universal patch deadline or support lifetime applies.
Workarounds, merged changes, releases, hosted rollouts, and customer deployments are separate milestones. Closure needs evidence of correction. Advisories should identify affected versions, impact, fix or mitigation, operator action, limitations, and corrections. Check dependency fixes against the supplied version.
Solarius deploys changes to components it operates. Customers deploy self-hosted software, agents, local dependencies, and independently managed components unless a managed-service agreement assigns that work otherwise. Product support schedules determine supported versions and retirement; request written clarification through support if unclear. Software-license rights survive under their governing licenses.
Active incidents and breach notification
Report active compromise, material exposure, or security-related service failure to help@solarius.me and the purchased urgent channel. Send privacy concerns to dpo@solarius.me. Include product, organization, UTC time, affected resources, impact, and a safe contact. Do not wait for research triage; ordinary email is not a public emergency service.
Solarius assesses the event, restricts evidence access, and coordinates containment, investigation, correction, and recovery within its authority. A product alert does not automatically establish a breach of Solarius systems. Isolation, destructive changes, and other disruptive response require the applicable permission or approved playbook. A quiet alert stream or closed ticket does not prove recovery.
Personal-data breach duties depend on Solarius's role:
| Role | Notification responsibility |
|---|---|
| Processor | Notify the designated customer without undue delay after awareness of a covered breach, under the DPA. Do not wait for a final forensic report or treat the controller's regulatory deadline as a waiting period. |
| Controller | Assess and make authority and individual notifications required by applicable law. |
Initial customer notice can be preliminary. It identifies the known nature, affected categories, likely consequences, mitigation, necessary customer action, and follow-up contact. Missing material information follows in phases. Customers retain their own controller decisions with required assistance; Solarius does not notify people in a customer's name without authority unless law requires it.
A public status update does not replace a required individualized notice. Notification is not an admission of liability, does not waive accountability, and does not require a release of claims.
Recovery must reconcile affected permissions and reapply outstanding deletion and revocation after a restore. Material incidents receive review and corrective follow-up. The agreement determines any root-cause report deliverable. Retained evidence remains purpose-limited, and bounty confidentiality does not suppress mandatory reporting. Notice restrictions follow the government-request policy.