We release patches for security vulnerabilities in the following versions:

We take security seriously. If you discover a security vulnerability within Flyto2 Core, please report it responsibly.

Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please report them via email to:

security@flyto.dev

Or, if you prefer, you can use GitHub's private vulnerability reporting feature:

1. Go to the Security tab of this repository
2. Click "Report a vulnerability"
3. Fill out the form with details about the vulnerability

Please include the following information in your report:

• Type of vulnerability (e.g., SQL injection, XSS, authentication bypass)
• Location of the affected source code (file path and line numbers if possible)
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact assessment - what an attacker could achieve
• Suggested fix (if you have one)

• Initial Response: Within 48 hours of your report
• Status Update: Within 7 days with an assessment
• Resolution Target: Within 90 days for most issues

1. Acknowledgment: We will acknowledge receipt of your report within 48 hours
2. Assessment: We will assess the vulnerability and determine its severity
3. Updates: We will keep you informed of our progress
4. Fix: We will develop and test a fix
5. Disclosure: We will coordinate public disclosure with you
6. Credit: We will credit you in our security advisories (unless you prefer anonymity)

When using Flyto2 Core, please follow these security best practices:

Never hardcode sensitive credentials in workflow files.

# BAD - Don't do this
steps:
  - id: api_call
    module: api.http_post
    params:
      headers:
        Authorization: "Bearer sk-1234567890abcdef"  # Never hardcode!

# GOOD - Use environment variables
steps:
  - id: api_call
    module: api.http_post
    params:
      headers:
        Authorization: "Bearer ${env.API_KEY}"

Store sensitive values in environment variables:

# API Keys
export OPENAI_API_KEY="your-key-here"
export ANTHROPIC_API_KEY="your-key-here"
export GITHUB_TOKEN="your-token-here"

# Database Credentials
export DATABASE_URL="postgresql://user:pass@host:5432/db"

# Third-party Services
export SLACK_WEBHOOK_URL="https://hooks.slack.com/..."
export STRIPE_API_KEY="sk_live_..."

Workflow files may contain sensitive logic. Protect them appropriately:

# Restrict workflow file permissions
chmod 600 sensitive-workflow.yaml

# Restrict .env files
chmod 600 .env

When creating custom modules, always validate and sanitize inputs:

All network modules use validate_url_with_env_config() from src/core/utils.py.

from core.utils import validate_url_with_env_config, SSRFError

try:
    validate_url_with_env_config(url)
except SSRFError as e:
    return {'ok': False, 'error': str(e), 'error_code': 'SSRF_BLOCKED'}

localhost, localhost.localdomain, 127.0.0.1, ::1, 0.0.0.0, metadata.google.internal, 169.254.169.254 (cloud metadata), metadata.internal

After hostname resolution, the resolved IP is checked against all blocked ranges. This prevents DNS rebinding attacks where a hostname resolves to a private IP.

The module validator (validator.py) requires all network modules to declare SSRF protection via the ssrf_protected tag (rule SEC001 / CORE-SEC-003).

# Allow private networks (development only)
FLYTO_ALLOW_PRIVATE_NETWORK=true

# Allowlist specific hosts (comma-separated, supports wildcards)
FLYTO_ALLOWED_HOSTS=localhost,127.0.0.1,*.internal.corp.com

# VS Code local mode (allow localhost only)
FLYTO_VSCODE_LOCAL_MODE=true

# Allow remote Ollama server (default: localhost only)
FLYTO_ALLOW_REMOTE_OLLAMA=true

When using browser modules:

# Run in headless mode for server environments
- id: browser
  module: browser.launch
  params:
    headless: true

# Be cautious with file downloads
- id: download
  module: browser.download
  params:
    path: "/safe/download/directory/"  # Use restricted directory

Flyto2 Core automatically redacts sensitive values in logs. However, be careful when:

• Writing custom modules that log parameter values
• Using the utility.log module with sensitive data
• Enabling debug mode in production

Flyto2 Core executes workflow definitions. Be aware that:

• Workflow files should be treated as code
• Only run workflows from trusted sources
• Review third-party modules before using them

Some modules make network requests. Consider:

• Using firewall rules to restrict outbound connections
• Monitoring network traffic from workflow executions
• Using allowlists for permitted domains (see SSRF configuration above)

The browser modules can:

• Execute JavaScript on web pages
• Access cookies and local storage
• Download files

Always run browser automation in isolated environments when processing untrusted content.

Security updates are released as patch versions (e.g., 1.0.1, 1.0.2). We recommend:

1. Subscribe to this repository's releases
2. Update promptly when security patches are released
3. Monitor the security advisories

We follow responsible disclosure practices:

• We will not take legal action against security researchers acting in good faith
• We will work with you to understand and resolve the issue
• We will publicly acknowledge your contribution (with your permission)

For security concerns:

• Email: security@flyto.dev
• GitHub Security Advisories: Report a vulnerability

For general questions:

• GitHub Issues: For non-security bugs and feature requests
• GitHub Discussions: For questions and community support

Thank you for helping keep Flyto2 Core and its users safe.