| Version | Supported |
|---|---|
| 1.0.x | ✅ |
The Throttle team takes security vulnerabilities seriously. We appreciate your efforts to responsibly disclose your findings.
Please do NOT report security vulnerabilities through public GitHub issues.
Instead, please report security vulnerabilities by:
- Opening a private security advisory on GitHub
- Or emailing the maintainers (see contact information below)
Please include the following information in your report:
- Type of vulnerability
- Full paths of source file(s) related to the vulnerability
- Location of the affected source code (tag/branch/commit or direct URL)
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit it
- Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours.
- Assessment: We will assess the vulnerability and determine its impact within 7 days.
- Fix Timeline: We will work to fix confirmed vulnerabilities as quickly as possible:
- Critical: Within 7 days
- High: Within 14 days
- Medium/Low: Within 30 days
- Disclosure: We will notify you when the vulnerability is fixed and coordinate public disclosure.
When using Throttle:
-
Resource Thresholds: Set appropriate CPU and memory thresholds for your environment to prevent system overload.
-
Task Implementation: Ensure your task implementations:
- Don't expose sensitive data in task IDs or metrics
- Handle exceptions properly in
processChunk() - Don't store sensitive information in task state
-
Queue Capacity: Configure appropriate queue capacity and overflow policies to prevent denial-of-service via task submission flooding.
-
Monitoring: Use the built-in metrics to detect anomalous behavior:
- Unusually high task failure rates
- Excessive pause/resume cycles
- Queue saturation
-
Thread Pools: Provide appropriately sized thread pools to prevent resource exhaustion.
-
Custom Monitors: If implementing custom resource monitors, ensure they:
- Don't leak sensitive information
- Handle exceptions gracefully
- Don't block indefinitely
The executor is designed to prevent resource exhaustion, but:
- Malicious tasks can still consume resources during chunk execution
- Extremely small chunk sizes can cause overhead
- Very large queues can consume significant memory
Mitigation: Configure appropriate thresholds, queue sizes, and task termination policies.
Task metrics and IDs may contain sensitive information if your task implementation includes it.
Mitigation: Don't include sensitive data in task IDs or observable fields.
Security updates will be released as patch versions (e.g., 1.0.1) and announced via:
- GitHub Security Advisories
- Release notes in CHANGELOG.md
- GitHub Releases page
For security-related questions or concerns, please open a GitHub issue (for non-sensitive questions) or contact the maintainers directly (for sensitive matters).
We appreciate the security research community and will acknowledge reporters who responsibly disclose vulnerabilities (with their permission).