Wan2.1/SECURITY.md
Claude ad3e7bd5d2
docs: add comprehensive project documentation
Adds essential documentation to make the project more welcoming,
secure, and maintainable for contributors and users.

CONTRIBUTING.md:
- Complete contribution guidelines with examples
- Development setup instructions
- Code style and testing requirements
- Commit message conventions (Conventional Commits)
- Pull request process
- Type hints and docstring guidelines

CODE_OF_CONDUCT.md:
- Based on Contributor Covenant 2.1
- Clear community standards and expectations
- Enforcement guidelines with graduated responses
- Reporting and resolution procedures

SECURITY.md:
- Vulnerability reporting process
- Security best practices for users
- Known security considerations
- Disclosure policy
- Supported versions table
- Security checklist for developers

CHANGELOG.md:
- Keep a Changelog format
- Comprehensive refactoring documentation
- Migration guide for security changes
- Detailed version history
- Deprecation notices section

Benefits:
- Clear expectations for contributors
- Professional community management
- Transparent security practices
- Comprehensive change tracking
- Improved onboarding experience
2025-11-19 04:25:16 +00:00

7.1 KiB

Security Policy

Supported Versions

The following versions of Wan2.1 are currently being supported with security updates:

Version Supported
2.x
1.x
< 1.0

Reporting a Vulnerability

We take the security of Wan2.1 seriously. If you believe you have found a security vulnerability, please report it to us as described below.

Where to Report

Please do not report security vulnerabilities through public GitHub issues.

Instead, please report them via:

  1. GitHub Security Advisory: Use the Security tab to privately report vulnerabilities
  2. Email: Contact the project maintainers (if email is provided in project documentation)

What to Include

Please include the following information in your report:

  • Description: A clear description of the vulnerability
  • Type: The type of vulnerability (e.g., remote code execution, information disclosure, denial of service)
  • Impact: The potential impact of the vulnerability
  • Steps to Reproduce: Detailed steps to reproduce the vulnerability
  • Proof of Concept: If possible, include a minimal proof of concept
  • Affected Versions: Which versions of Wan2.1 are affected
  • Suggested Fix: If you have suggestions for fixing the vulnerability

Example Report

**Description**: Arbitrary code execution through malicious model checkpoint

**Type**: Remote Code Execution (RCE)

**Impact**: An attacker could execute arbitrary Python code by crafting a
malicious model checkpoint file.

**Steps to Reproduce**:
1. Create a malicious checkpoint using pickle
2. Load the checkpoint using torch.load()
3. Code executes during unpickling

**Affected Versions**: All versions < 2.1.0

**Suggested Fix**: Use weights_only=True in torch.load() calls

Response Timeline

  • Initial Response: Within 48 hours
  • Status Update: Within 7 days
  • Fix Timeline: Varies by severity (see below)

Severity Levels

Severity Response Time Fix Timeline
Critical 24 hours 1-7 days
High 48 hours 7-30 days
Medium 7 days 30-90 days
Low 14 days Best effort

Security Best Practices

When using Wan2.1, please follow these security best practices:

1. Model Checkpoints

  • Only load trusted checkpoints: Never load model weights from untrusted sources
  • Verify checksums: Always verify checkpoint checksums before loading
  • Use safe loading: The library now uses weights_only=True for all torch.load() calls

2. API Keys and Credentials

  • Environment Variables: Store API keys in environment variables, never in code
  • Key Rotation: Rotate API keys regularly
  • Minimal Permissions: Use API keys with minimal required permissions
# Good
export DASH_API_KEY="your-api-key"

# Bad - never commit keys to version control
DASH_API_KEY = "sk-abc123..."  # Don't do this!

3. Input Validation

  • Validate file paths: Always validate user-provided file paths
  • Sanitize inputs: Sanitize all user inputs before processing
  • Size limits: Enforce reasonable size limits on input files

4. Network Security

  • HTTPS only: Use HTTPS for all API communications
  • Verify SSL: Always verify SSL certificates
  • Timeout settings: Set appropriate timeouts for network requests

5. Dependency Management

  • Keep updated: Regularly update dependencies to get security patches
  • Audit dependencies: Run pip audit to check for known vulnerabilities
  • Pin versions: Pin dependency versions in production
# Check for vulnerabilities
pip install pip-audit
pip-audit

# Update dependencies
pip install --upgrade -r requirements.txt

6. Execution Environment

  • Sandboxing: Run in isolated environments when processing untrusted inputs
  • Resource limits: Set memory and computation limits
  • User permissions: Run with minimal required user permissions

Known Security Considerations

1. Model Checkpoint Loading

Fixed in v2.1.0: All torch.load() calls now use weights_only=True to prevent arbitrary code execution.

Before v2.1.0: Loading untrusted model checkpoints could lead to arbitrary code execution through pickle deserialization.

2. Temporary Files

Status: The library uses /tmp for video caching. Ensure proper permissions on temporary directories.

Mitigation: Set appropriate permissions on your system's temp directory, or configure a custom cache directory.

3. GPU Memory

Status: Processing very large videos can consume significant GPU memory, potentially causing denial of service.

Mitigation: Implement resource limits and input validation in production environments.

4. API Integration

Status: Integration with external APIs (DashScope) requires proper API key management.

Mitigation: Always use environment variables for API keys and never commit them to version control.

Security Updates

Security updates will be released as:

  • Patch releases for critical and high severity issues
  • Minor releases for medium severity issues
  • Major releases for issues requiring breaking changes

Subscribe to:

  • GitHub Security Advisories
  • Release notifications
  • Project announcements

Disclosure Policy

  • Private Disclosure: We practice responsible disclosure
  • Coordinated Release: Security fixes are coordinated with affected parties
  • Public Disclosure: After a fix is released, we publish a security advisory
  • CVE Assignment: We request CVEs for significant vulnerabilities

Bug Bounty Program

We currently do not have a formal bug bounty program. However, we deeply appreciate security researchers who report vulnerabilities responsibly and will acknowledge their contributions in:

  • Security advisories
  • Release notes
  • Project documentation

Security Checklist for Developers

When contributing to Wan2.1, please ensure:

  • No hardcoded credentials or API keys
  • Input validation for all user-provided data
  • Proper error handling without information leakage
  • Safe deserialization practices (weights_only=True)
  • No use of dangerous functions (eval, exec)
  • Dependency security scan passes
  • Security tests included for new features

Additional Resources

Questions?

For security-related questions that are not sensitive enough to require private disclosure, you may:

  • Open a GitHub Discussion
  • Contact maintainers through official channels

For all other security matters, please use the private reporting methods described above.

Acknowledgments

We thank the security researchers and community members who help keep Wan2.1 secure.


Last updated: 2025-01-19