Security Bug Bounty

Effective date: 2026-03-10

For security researchers

Security researchers help keep Fluxer safe. If you find a vulnerability, we want to hear about it, and we want you to feel safe telling us.

This policy covers what's in scope, how to submit a report, what legal protections we offer, how we triage and respond, and how we recognise your work.

Safe harbour

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

We treat good-faith research conducted under this policy as authorised activity. We won't bring or support legal proceedings against you 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 was conducted in line with this policy.

We won't 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 conducted under this policy, we'll take steps to confirm that your actions were authorised. This may include a written statement to the court or the relevant authority.

Safe harbour applies by default and can't be revoked retroactively. If we later narrow the scope, research conducted under the previous scope stays covered.

Limits. Safe harbour does not extend to research conducted for the purpose of extortion or coercion, activity that intentionally harms users, degrades the service, or destroys data, or activity that violates applicable law beyond what's needed for good-faith testing. If you're unsure whether a planned test is within scope, ask us first at security@fluxer.app.

Who should read this

Anyone who discovers or goes looking for a security issue in Fluxer: researchers, community members, or otherwise. The policy covers scope, triage methodology, reward eligibility, and disclosure coordination.

Scope

In scope

Fluxer websites, applications, and services operated by Fluxer Platform AB, including the following domains and any subdomain thereof: fluxer.app, fluxer.app, fluxer.gg, fluxer.gift, fluxerapp.com, fluxer.dev, fluxerusercontent.com, fluxerstatic.com, and fluxer.media.

Infrastructure, systems, and operational services directly managed by Fluxer that affect authentication, authorisation, payments, community data, or the processing of security- or privacy-relevant data (including user identifiers, account metadata, logs, analytics, and telemetry).

Abuse cases that allow unauthorised persistence, privilege escalation, or data disclosure when triggered through officially supported product features.

Self-hosted Fluxer instances that rely on Fluxer's security guidance, provided the issue is reproducible on the latest official release as shipped by us and isn't caused solely by third-party modifications or local misconfiguration.

If you're unsure whether a target is in scope, email security@fluxer.app and ask before testing.

Out of scope

Third-party services and infrastructure that we don't control, including partner communities' independent integrations, bots, or external hosting providers. If you find a vulnerability in a third-party service we use, report it to that service's own security team and let us know so we can assess any impact on Fluxer.

Physical security. Vulnerabilities requiring physical access to facilities, servers, or devices.

Social engineering. Social engineering, phishing, bribery, coercion, or attempts to manipulate Fluxer staff or users. This includes pretexting, vishing, and any form of human manipulation.

Denial of service. DoS attacks, traffic flooding, rate-limit exhaustion, or resource exhaustion testing. Exception: if you discover an application-layer DoS vulnerability that can be triggered by a single unauthenticated request or a small number of requests, report it without actively exploiting it at scale. We'll accept the report on the basis of a proof of concept.

Automated scanning noise. Automated scanning or bulk testing that produces noisy or low-signal findings without a clear security impact and a reliable reproduction path.

Non-security issues. General UI bugs, feature requests, or support issues. Email support@fluxer.app for those.

Outdated self-hosted deployments. Issues in forked, modified, or outdated self-hosted deployments that aren't reproducible on the latest official release.

Low-impact findings without demonstrated impact. We generally don't prioritise reports for missing best-practice headers, minor configuration issues, or theoretical vulnerabilities unless you can show a concrete, exploitable security impact. If you believe a low-severity finding has a realistic attack path, include it and we'll consider it.

How to report

Email your report to security@fluxer.app.

If you'd like to encrypt your report, email security@fluxer.app with the subject line "PGP key request" and we'll send you our public key.

What to include

A good report contains:

• A clear title that summarises the vulnerability.
• A description of the security impact: what an attacker could achieve and which users or systems are affected.
• A realistic attack scenario describing how the vulnerability would be exploited in practice.
• Step-by-step reproduction instructions, including any prerequisites (account type, permissions, configuration).
• Proof of concept material: screenshots, logs, recordings, HTTP requests, or code that demonstrates the issue.
• Environment details: browser, OS, client version, region, logged-in state, and any relevant configuration.
• Any mitigations you tried and whether the issue persists after clearing caches, using a private window, or restarting clients.
• A severity estimate, either a CVSS v4.0 score or a plain-language assessment of the access and impact.

The more detail you provide, the faster we can validate and fix the issue.

Coordinated disclosure

Please don't publicly disclose the vulnerability until we've acknowledged your report and had a reasonable opportunity to investigate and deploy a fix. Our standard disclosure timeline is 90 days after we confirm and remediate the vulnerability, in line with widely accepted practice. We'll coordinate the timeline with you and credit you in any public advisory unless you'd prefer to remain anonymous.

If we can't remediate within 90 days, we'll communicate our progress and work with you on an adjusted timeline. We'll never request indefinite non-disclosure.

How we triage reports

Severity classification

We use CVSS v4.0 as our baseline scoring framework, supplemented by a platform-specific business impact assessment. The table below describes our severity tiers with representative examples.

We reserve the right to adjust severity based on context, including the number of affected users, the sensitivity of affected data, ease of exploitation, and whether the vulnerability is already being exploited in the wild.

Duplicate reports

If multiple reports describe the same underlying vulnerability, we credit and reward the first report that clearly explains the issue and gives a reliable reproduction path. Later reporters will be acknowledged but won't receive the primary reward. If your report adds new information to an existing report (for example, a more severe attack vector or broader impact), we may offer partial recognition.

Rewards and recognition

We value the time and expertise that goes into good security research. Depending on the validity, severity, and impact of your finding, we may award the following.

Non-monetary recognition

• A Bug Hunter badge on your Fluxer profile.
• A listing on our Security Hall of Fame, published on our website with your consent.
• Fluxer Plutonium gift codes for premium features.
• CVE credit where applicable and warranted.
• Public acknowledgment on our social media and security advisories, with your consent.

Monetary rewards

We intend to introduce cash rewards once our payments infrastructure supports it. We'll update this section when bounties become available. In the meantime, we may offer monetary recognition on a case-by-case basis for exceptionally high-impact findings.

Indicative reward tiers (non-monetary, current)

These tiers are indicative. We may adjust recognition upward for reports of exceptional quality, creative exploitation techniques, or findings that reveal systemic issues.

Eligibility

To be eligible for rewards and recognition, you must:

• Report findings privately to security@fluxer.app in line with this policy.
• Not publicly disclose the vulnerability before we've acknowledged and addressed it.
• Not exploit the vulnerability beyond what's needed to demonstrate it.
• Comply with all safe testing rules described below.
• Not be a current employee, contractor, or immediate family member of a Fluxer employee.

What to expect from us

Acknowledgment. We aim to acknowledge receipt within 3 business days (often sooner).

Triage. We'll review your report, assess severity, and give an initial triage response within 5 business days of acknowledgment. Critical findings may be triaged faster.

Updates. We'll keep you informed as we investigate and remediate. If our severity assessment differs from yours, we'll explain why.

Remediation. We'll work to fix validated vulnerabilities within the target timelines in the severity table above. If it'll take longer, we'll let you know.

Disclosure and credit. After a fix is deployed, we'll coordinate public disclosure and credit with you, unless you'd prefer to remain anonymous. We'll share a draft of any public advisory with you for review before publication.

If we can't reproduce the issue, we'll tell you what we tried and may ask for more details, environment information, or a clearer proof of concept. We won't close a report just because we couldn't reproduce it on the first attempt. We'll work with you.

Safe testing rules

To make sure security research doesn't harm Fluxer users or degrade the service, please follow these rules.

Test only what you own or control. Only test against accounts, Communities, and data that you own or have explicit written permission to use. Community-level testing (roles, permissions, invites, moderation tools, settings, data access) must happen only in Communities you own or administer, or where you have explicit permission from the Community Owner.

Don't access others' data. Don't access, modify, exfiltrate, or attempt to view other users' or Communities' data without their consent. If you inadvertently access another user's data during testing, stop immediately, don't store or share it, and report it to us.

Don't cause harm. Don't delete, modify, or corrupt data belonging to other users. Don't degrade service availability or performance. Don't send notifications, emails, or other communications to users who aren't part of your test.

Don't use disruptive techniques. Don't use automated flooding, scraping, brute-forcing, or other techniques that degrade reliability or generate noisy, low-signal data. If your testing could trigger real user notifications, support workflows, emails, billing events, or payments, get in touch first so we can prepare.

Follow the law. Comply with applicable laws in your jurisdiction and in the jurisdictions where Fluxer operates. If you're unsure whether a particular test is legal, err on the side of caution and ask us first.

Protect sensitive data. If your research involves any user data (even test data), handle it securely and delete it when your research is done. Don't include real user data in reports unless it's strictly needed to demonstrate the vulnerability.

Changes to this policy

We may update this policy from time to time. Changes will be noted in our changelog. Research conducted under a previous version remains covered by the safe harbour terms that were in effect when the research was performed.

Contact

Security reports: security@fluxer.app
Questions about this policy: security@fluxer.app
Non-security issues: support@fluxer.app

Thanks for helping keep Fluxer secure.