|
2 | 2 |
|
3 | 3 | At Flowise, we prioritize security and continuously work to safeguard our systems. However, vulnerabilities can still exist. If you identify a security issue, please report it to us so we can address it promptly. Your cooperation helps us better protect our platform and users. |
4 | 4 |
|
| 5 | +### Scope |
| 6 | +- Flowise Cloud: cloud.flowiseai.com |
| 7 | +- Public Flowise Repositories |
| 8 | + |
5 | 9 | ### Out of scope vulnerabilities |
6 | 10 |
|
7 | | -- Clickjacking on pages without sensitive actions |
8 | | -- CSRF on unauthenticated/logout/login pages |
| 11 | +- Hypothetical issues that do not have a demonstrable, practical impact |
| 12 | +- Vulnerabilities that affect out-of-date browsers |
| 13 | +- ClickjackingCSRF on unauthenticated/logout/login pages |
| 14 | +- Banner disclosure on common/public services |
| 15 | +- Disclosure of known public files or directories (e.g. robots.txt) |
9 | 16 | - Attacks requiring MITM (Man-in-the-Middle) or physical device access |
10 | 17 | - Social engineering attacks |
11 | | -- Activities that cause service disruption (DoS) |
| 18 | +- Denial service via bruteforce attack |
12 | 19 | - Content spoofing and text injection without a valid attack vector |
| 20 | +- Username enumeration via Login Page error message |
| 21 | +- Username enumeration via Forgot password error message |
| 22 | +- Bruteforce attacks |
13 | 23 | - Email spoofing |
14 | 24 | - Absence of DNSSEC, CAA, CSP headers |
15 | 25 | - Missing Secure or HTTP-only flag on non-sensitive cookies |
16 | 26 | - Deadlinks |
17 | 27 | - User enumeration |
| 28 | +- Social Engineering |
| 29 | +- Version Disclosure |
| 30 | +- Vulnerabilities that can only affect the attacker (e.g. self-XSS) |
| 31 | +- Known vulnerabilities in used libraries (unless exploitability can be proven) |
| 32 | +- Static application security testing findings |
| 33 | + |
18 | 34 |
|
19 | 35 | ### Reporting Guidelines |
20 | 36 |
|
21 | 37 | - Submit your findings to https://github.com/FlowiseAI/Flowise/security |
22 | 38 | - Provide clear details to help us reproduce and fix the issue quickly. |
23 | 39 |
|
24 | | -### Disclosure Guidelines |
| 40 | +### Reporting Guidelines |
| 41 | + |
| 42 | +- Submit your findings to https://github.com/FlowiseAI/Flowise/security |
| 43 | +- Ensure that the vulnerability is exploitable. Theoretical or static application security testing reports are subject to dismissal. |
| 44 | +- Submit the report with CVSS vector and calculated severity. |
| 45 | +- Provide a clear detailed report with proof of concept to help us reproduce and remediate the vulnerability. |
| 46 | + |
| 47 | +### Disclosure Terms |
| 48 | + |
| 49 | +The Flowise team believes that transparency is important and public bug bounty reports are a valuable source of knowledge for bug bounty researchers. However, the Flowise team may have legitimate reasons not to disclose vulnerabilities. |
25 | 50 |
|
26 | | -- Do not publicly disclose vulnerabilities until we have assessed, resolved, and notified affected users. |
27 | | -- If you plan to present your research (e.g., at a conference or in a blog), share a draft with us at least **30 days in advance** for review. |
28 | | -- Avoid including: |
29 | | - - Data from any Flowise customer projects |
30 | | - - Flowise user/customer information |
31 | | - - Details about Flowise employees, contractors, or partners |
| 51 | +Do not discuss or disclose vulnerability information without prior written consent. If you plan on presenting your research, please share a draft with us at least 45 days in advance for review. Avoid including: |
| 52 | +- Data from any Flowise customer projects |
| 53 | +- Flowise user/customer information |
| 54 | +- Details about Flowise employees, contractors, or partners |
32 | 55 |
|
33 | | -### Response to Reports |
| 56 | +### Report Validation Times |
34 | 57 |
|
35 | | -- We will acknowledge your report within **5 business days** and provide an estimated resolution timeline. |
36 | | -- Your report will be kept **confidential**, and your details will not be shared without your consent. |
| 58 | +We will validate submissions within the below timelines. |
| 59 | +| Vulnerability Severity | Time to Validate | |
| 60 | +| ---------------------- | ---------------- | |
| 61 | +| Critical | 5 business days | |
| 62 | +| High | 5 business days | |
| 63 | +| Medium | 15 business days | |
| 64 | +| Low | 15 business days | |
37 | 65 |
|
| 66 | +Your report will be kept *confidential*, and your details will not be shared without your consent. The Flowise team will triage and adjust severity or CVSS score if necessary. |
38 | 67 | We appreciate your efforts in helping us maintain a secure platform and look forward to working together to resolve any issues responsibly. |
| 68 | + |
| 69 | +### Remediation |
| 70 | + |
| 71 | +Once the report has been verified, the Flowise team will plan the remediation steps. |
| 72 | +Below is the estimated time to remediate the triaged security reports. |
| 73 | + |
| 74 | +| Triaged Severity | Estimated Time to Remediate | |
| 75 | +| ---------------------- | ---------------- | |
| 76 | +| Critical | 30 business days | |
| 77 | +| High | 60 business days | |
| 78 | +| Medium | 90 business days | |
| 79 | + |
| 80 | +### Public Disclosure Timeline |
| 81 | + |
| 82 | +Public Disclosure occurs exactly 30 days after the next official release that includes the security patch. This period gives Flowise users a time to adopt the patched version before technical vulnerability details are made public, mitigating the risk of immediate post-disclosure exploitation. |
| 83 | + |
| 84 | +#### Reaching out to the Security team |
| 85 | +To report a new vulnerability, please submit a Github security Security Advisory report. |
| 86 | +If you have any questions or concerns about the existing Security Advisory, please contact security-team@flowiseai.com. |
0 commit comments