Vulnerability Disclosure Policy

1. Introduction

In Flux Studio LLC (“In Flux Studio,” “IFS,” “we,” “our”) is committed to maintaining the security of our platform and the data entrusted to us by our customers. We recognize that independent security researchers play a valuable role in identifying vulnerabilities that strengthen our defenses.

This Vulnerability Disclosure Policy (“VDP”) describes how to report security vulnerabilities to In Flux Studio, defines the scope of systems covered, establishes rules of engagement for good-faith security research, and provides a safe harbor commitment to researchers who comply with this policy.

2. How to Report a Vulnerability

Email: security@influxstudio.co

Please include the following in your report:

• A clear description of the vulnerability and the affected system or endpoint.
• Step-by-step instructions to reproduce the issue.
• Any supporting evidence, such as screenshots, HTTP request/response captures, or proof-of-concept code.
• Your assessment of the severity and potential impact.
• Your preferred method of contact for follow-up communication.

We do not currently support PGP-encrypted submissions. If you require encrypted communication, please indicate this in your initial report and we will coordinate a secure channel.

3. Systems in Scope

The following In Flux Studio-operated systems are within the scope of this policy:

3.1 Out of Scope

The following third-party services are not operated by In Flux Studio and are excluded from this policy. Researchers must not test these systems under this VDP:

• Railway hosting infrastructure (*.up.railway.app)
• Google services (OAuth, Drive, Fonts, Workspace)
• Resend email delivery infrastructure
• Payment processing services (Stripe, Paddle), if and when activated

If you discover a vulnerability in a third-party service that affects In Flux Studio, please report it to us and we will coordinate with the relevant provider.

4. Vulnerability Types We Want to Hear About

We are interested in receiving reports about the following categories of vulnerabilities affecting in-scope systems:

• Authentication and session management vulnerabilities
• Authorization bypass — accessing another user’s data, projects, or administrative functions
• Injection vulnerabilities (SQL injection, command injection, cross-site scripting)
• Insecure direct object references (IDOR)
• Sensitive data exposure — credentials, personally identifiable information, or customer content
• Broken access control
• Security misconfiguration on in-scope systems
• Server-side request forgery (SSRF)

4.1 Exclusions

The following are generally not considered in-scope vulnerabilities under this policy, though we welcome reports if you believe a specific instance presents a material security risk:

• Denial-of-service (DoS) or distributed denial-of-service (DDoS) attacks
• Social engineering or phishing attacks against In Flux Studio employees or customers
• Physical attacks against In Flux Studio infrastructure or personnel
• Reports generated solely by automated scanning tools without demonstrated exploitability
• Missing HTTP security headers without a demonstrated attack vector
• Vulnerabilities in out-of-scope third-party services listed in Section 3.1

5. Rules of Engagement

To qualify for the safe harbor provided in Section 6, researchers must comply with all of the following rules.

5.1 Permitted Conduct

1. Test only systems listed in Section 3 as in-scope.
2. Report any discovered vulnerability to security@influxstudio.co as soon as practicable after discovery.
3. Limit exploitation to the minimum necessary to demonstrate the vulnerability. Proof-of-concept should stop at confirmation of the issue.
4. Conduct testing using accounts you own or control. Do not intentionally access, retain, or exfiltrate data belonging to other users. If you inadvertently access another user’s data in the course of testing, follow the requirements in Section 6.3.

5.2 Prohibited Conduct

The following activities are prohibited and will void the safe harbor:

1. Accessing, downloading, modifying, exfiltrating, or deleting data belonging to any other user or customer.
2. Performing denial-of-service attacks, resource exhaustion attacks, or sending excessive automated traffic that degrades service availability.
3. Using social engineering, phishing, or pretexting against In Flux Studio employees, contractors, or customers.
4. Publicly disclosing vulnerability details before the expiration of the disclosure window defined in Section 7, or before In Flux Studio has confirmed remediation, whichever comes first.
5. Exploiting a vulnerability for any purpose other than demonstrating its existence to In Flux Studio.
6. Testing out-of-scope systems, including third-party infrastructure listed in Section 3.1.
7. Conducting any activity that violates applicable law, regardless of whether it is described in this policy.

6. Safe Harbor

6.1 In Flux Studio’s Commitment

If you conduct security research in compliance with this policy, In Flux Studio commits to the following:

1. We will not initiate or support civil legal action against you related to your research activities conducted in compliance with this policy.
2. We will not refer your research activities to law enforcement or pursue criminal charges under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), the Delaware Computer Fraud Act (11 Del. C. § 932–936), the New Jersey Computer Related Offenses Act (N.J.S.A. 2C:20-25 et seq.), or equivalent state statutes, provided your conduct complies with this policy.
3. We consider research conducted in compliance with this policy to be authorized for purposes of the Computer Fraud and Abuse Act and equivalent state computer crime statutes.
4. We will not enforce provisions of our Terms of Service (including Section 7.1, Acceptable Use Policy) against activities conducted in compliance with this policy.
5. We will not invoke the user indemnification provisions of our Terms of Service (Section 12.1) against you with respect to claims arising from your research activities conducted in compliance with this policy, including inadvertent access to other users’ data as addressed in Section 6.3.

6.2 Scope and Limitations of Safe Harbor

This safe harbor applies exclusively to legal claims that In Flux Studio could assert or cause to be asserted against the researcher. It does not extend to claims by third parties, including the third-party service providers listed in Section 3.1. If a third party initiates legal action against you for research conducted in compliance with this policy, we will take reasonable steps to make it known that your activities were authorized under this VDP, but we cannot guarantee the actions of third parties.

This safe harbor does not constitute a waiver of In Flux Studio’s rights under Sections 11 and 12 of the Terms of Service (Limitation of Liability and Indemnification), except as set forth below. The Limitation of Liability provisions of Section 11 of the Terms of Service continue to apply to In Flux Studio’s liability to you. The User Indemnification provision in Section 12.1 of the Terms of Service is subject to the carve-out in Section 6.1(e) above for activities conducted in compliance with this policy.

6.3 Inadvertent Data Access

If, in the course of good-faith research conducted in compliance with this policy, you inadvertently access data belonging to another user, you must immediately cease further access to that data, report the finding to security@influxstudio.co, and delete any copies of the data in your possession. Provided you comply with these requirements, In Flux Studio will treat the inadvertent access as covered by the safe harbor in Section 6.1.

7. Coordinated Disclosure

In Flux Studio follows coordinated disclosure practices consistent with CISA guidelines and industry norms.

7.1 Disclosure Window

Upon receipt and acknowledgment of a vulnerability report, In Flux Studio requests a disclosure window of ninety (90) calendar days to assess, remediate, and deploy a fix before any public disclosure by the researcher.

7.2 Extensions

If remediation requires additional time beyond the 90-day window, In Flux Studio will notify the researcher before the window expires with a revised timeline and justification. Extensions are by mutual agreement; neither party is obligated to agree to an extension.

7.3 Public Disclosure

Upon remediation, the researcher may request coordinated public disclosure. In Flux Studio will work with the researcher to agree on the timing and content of any public disclosure. If the researcher wishes to be credited, In Flux Studio will acknowledge the researcher by name or handle (at the researcher’s preference) on our security acknowledgments page, if one is published.

7.4 Early Disclosure

If In Flux Studio becomes aware that a reported vulnerability is being actively exploited in the wild, we reserve the right to issue a public advisory before the 90-day window expires, after providing the researcher reasonable advance notice.

8. Our Response Commitments

In Flux Studio will make best efforts to meet the following response timelines:

These timelines are best-effort commitments. In Flux Studio is currently in beta, and our security operations are staffed accordingly. We do not commit to a specific remediation or patch deployment timeline. We will communicate honestly about expected resolution timeframes on a per-report basis.

9. Recognition

In Flux Studio does not currently operate a bug bounty program and does not offer monetary compensation for vulnerability reports.

We value the contributions of security researchers and, with the researcher’s consent, will publicly acknowledge valid reports on our security acknowledgments page when one is published. Researchers may choose to be identified by name, pseudonym, or to remain anonymous.

10. Governing Law and Dispute Resolution

This Vulnerability Disclosure Policy is a standalone policy, independent of any other agreement between In Flux Studio and the researcher. It is governed by and construed in accordance with the laws of the State of Delaware, without regard to conflict-of-law principles. Any dispute arising out of or relating to this policy, or to security research conducted under it, shall be brought exclusively in the state or federal courts located in the State of Delaware.

For a researcher who is also a user of the Service: claims arising under or relating to the Terms of Service are governed by the dispute resolution provisions of the Terms of Service; claims arising under or relating to this policy are governed by this Section 10.

Nothing in this policy is intended to waive any right or defense available to In Flux Studio under applicable law, except as expressly stated in Section 6.

11. Changes to This Policy

In Flux Studio may update this policy from time to time. Material changes will be posted at www.influxstudio.co/security with a revised effective date. The updated policy applies to vulnerability reports submitted after the revised effective date. Reports submitted under a prior version of this policy will be governed by the version in effect at the time of submission.

12. Contact Information

Appendix A: security.txt (RFC 9116)

The following machine-readable file is deployed at /.well-known/security.txt on both app.influxstudio.co and influxstudio.co.

Contact: mailto:privacy@influxstudio.co
Expires: 2027-06-15T00:00:00+00:00
Policy: https://www.influxstudio.co/security
Preferred-Languages: en