Security Bug Bounty

Effective date: 2026-03-10

For security researchers

Security researchers help keep Fluxer safe. If you find a vulnerability, email security@fluxer.app. This policy explains what is in scope, what safe harbour means, how reports are triaged, and how we recognise good research.

Safe harbour

If you follow this policy and act in good faith, Fluxer will not pursue legal action against you for your security research.

Good-faith research under this policy is authorised activity. We will not bring or support legal proceedings under the Swedish Criminal Code (Brottsbalken), the EU Directive on attacks against information systems (2013/40/EU), the U.S. Computer Fraud and Abuse Act (CFAA), the U.S. Digital Millennium Copyright Act (DMCA), or equivalent laws in your jurisdiction, provided your research follows this policy.

We will not file complaints with law enforcement against researchers who act within scope and in good faith. If a third party takes legal action against you because of research under this policy, we will take steps to confirm that your actions were authorised, which may include a written statement to a court or relevant authority.

Safe harbour applies by default and cannot be revoked retroactively. If the scope is later narrowed, research conducted under the previous scope remains covered.

Limits. Safe harbour does not cover extortion, coercion, activity that intentionally harms users, service degradation, data destruction, or violations of law beyond what is needed for good-faith testing. If you are unsure whether a planned test is in scope, ask at security@fluxer.app before testing.

Scope

This policy is for anyone who discovers or looks for a security issue in Fluxer, including researchers, community members, and users.

In scope are Fluxer websites, applications, and services operated by Fluxer Platform AB, including fluxer.app, fluxer.gg, fluxer.gift, fluxerapp.com, fluxer.dev, fluxerusercontent.com, fluxerstatic.com, fluxer.media, and their subdomains. Infrastructure, systems, and operational services directly managed by Fluxer are also in scope when they affect authentication, authorisation, payments, community data, or security- or privacy-relevant data such as user identifiers, account metadata, logs, analytics, and telemetry.

Abuse cases are in scope when they allow unauthorised persistence, privilege escalation, or data disclosure through officially supported product features. Self-hosted Fluxer instances are in scope only when the issue is reproducible on the latest official release as shipped by us and is not caused solely by third-party modifications or local misconfiguration.

Out of scope are third-party services and infrastructure we do not control, including partner communities' independent integrations, bots, and external hosting providers. Physical security, social engineering, phishing, bribery, coercion, and attempts to manipulate Fluxer staff or users are also out of scope.

DoS attacks, traffic flooding, rate-limit exhaustion, resource exhaustion testing, noisy automated scanning, bulk testing without a clear impact, general UI bugs, feature requests, and ordinary support issues are out of scope. Application-layer DoS vulnerabilities that can be demonstrated with a single unauthenticated request or a small number of requests may be reported, but do not actively exploit them at scale.

Issues in forked, modified, or outdated self-hosted deployments are out of scope unless they are reproducible on the latest official release. Low-impact or theoretical findings, such as missing best-practice headers, are usually not prioritised unless you can show a realistic attack path and concrete security impact.

How to report

Email your report to security@fluxer.app. If you want to encrypt it, email the same address with the subject line "PGP key request" and we will send you our public key.

A good report gives us a clear title, the affected area, the security impact, a realistic attack scenario, and step-by-step reproduction instructions. Include relevant proof of concept material such as screenshots, logs, recordings, HTTP requests, or code, plus environment details such as browser, operating system, client version, region, logged-in state, account type, permissions, and configuration. If you have a plain-language severity estimate, include it.

Minimise user data in your report. Use test accounts you control wherever possible. If your PoC involves a real user, redact their username, user ID, email, tokens, and any message content that is not strictly needed to demonstrate the vulnerability. Mark out cookies, authorization headers, and session tokens in HTTP request logs (we do not need them to reproduce). The rules in Safe testing rules below apply: handle any user data securely and delete it once your research is done.

The more precise the report, the faster we can validate and fix the issue.

Coordinated disclosure

Please do not publicly disclose a vulnerability until we have acknowledged your report and had a reasonable opportunity to investigate and deploy a fix. Our standard disclosure timeline is 90 days after a vulnerability is confirmed and remediated.

If remediation cannot be completed within 90 days, we will share progress and agree an adjusted timeline with you. We do not request indefinite non-disclosure.

Triage and remediation

We assess severity based on practical impact, affected users, data sensitivity, exploitability, and whether the issue is already being exploited.

Critical issues include remote code execution on production infrastructure, authentication bypass for arbitrary accounts, mass exfiltration of user data, or full database compromise. Our target remediation window is 1-3 days.

High issues include privilege escalation to administrator access, stored XSS or CSRF enabling account takeover, access to another user's private messages or files, or bypassing safety or moderation systems. Our target remediation window is 7-14 days.

Medium issues include limited or self-XSS with a realistic path, CSRF with moderate impact, non-sensitive information disclosure, or bypassing rate limits in a security-relevant context. Our target remediation window is 30-60 days.

Low issues include minor information disclosure, low-impact configuration issues with a demonstrated attack path, or cosmetic issues in security UI that could cause user confusion. Our target remediation window is 60-90 days.

If multiple reports describe the same underlying vulnerability, primary recognition goes to the first report that clearly explains the issue and provides a reliable reproduction path. Later reports are acknowledged, and partial recognition may be offered when they add a more severe attack vector or broader impact.

Rewards and recognition

Good security research takes time and skill. Fluxer may award a Bug Hunter badge and Fluxer Plutonium gift codes for valid reports.

Plutonium gift codes generally scale by severity: critical reports may receive 12 months, high reports 6 months, medium reports 3 months, and low reports 1 month. These tiers are indicative and may be adjusted for report quality, creative exploitation, or findings that reveal systemic issues.

To be eligible for recognition, report privately to security@fluxer.app, follow this policy, do not publicly disclose the vulnerability before we have acknowledged and addressed it, and do not exploit the issue beyond what is needed to demonstrate it. Current Fluxer employees, contractors, and immediate family members of Fluxer employees are not eligible.

What to expect from us

We acknowledge receipt within 3 business days, often sooner. We review reports, assess severity, and send an initial triage response within 5 business days of acknowledgment. Critical findings may be triaged faster.

We will keep you informed while the issue is investigated and remediated. If our severity assessment differs from yours, we will explain why. Validated vulnerabilities are fixed within the target windows above, or we will tell you why more time is needed.

After a fix is deployed, public disclosure is coordinated with you. A draft of any public advisory is shared with you before publication.

If we cannot reproduce the issue, we will tell you what we tried and may ask for more details, environment information, or a clearer proof of concept. A report is not closed simply because it could not be reproduced on the first attempt.

Safe testing rules

Test only against accounts, Communities, and data that you own or have explicit written permission to use. Community-level testing must happen only in Communities you own or administer, or where the Community Owner has explicitly permitted it.

Do not access, modify, exfiltrate, or attempt to view other users' or Communities' data without consent. If you inadvertently access another user's data, stop immediately, do not store or share it, and report it to us.

Do not delete, corrupt, or modify data belonging to others. Do not degrade service availability or performance, send communications to users outside your test, use automated flooding or scraping, brute-force systems, or generate noisy low-signal data. If your testing could trigger real notifications, support workflows, emails, billing events, or payments, contact us first.

Comply with applicable law in your jurisdiction and in the jurisdictions where Fluxer operates. If you are unsure whether a test is legal or safe, ask before proceeding.

Handle any user data involved in testing securely and delete it when your research is done. Do not include real user data in reports unless it is strictly needed to demonstrate the vulnerability.

Changes to this policy

This policy may be updated from time to time. Changes are noted in our changelog. Research conducted under a previous version remains covered by the safe harbour terms in effect when the research was performed.

Contact

Security reports and questions about this policy go to security@fluxer.app. Non-security issues should go to support@fluxer.app.

Thank you for helping keep Fluxer secure.