| Version | Supported |
|---|---|
| 1.x | ✅ |
Please do not report security vulnerabilities through public GitHub issues.
Instead, please report them via email to: scot.floess@gmail.com
You should receive a response within 48 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
Please include:
- Type of issue (e.g., path traversal, remote code execution, arbitrary class loading)
- Full paths of source file(s) related to the issue
- 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 attack scenario
JClassLoader loads and executes classes from potentially untrusted sources. Users should:
- Validate URLs before adding them as class sources
- Use HTTPS instead of HTTP for remote sources
- Verify authentication credentials are secure
JClassLoader validates class names to prevent path traversal:
- Rejects class names containing
.. - Rejects class names with path separators (
/,\)
Remote sources use default SSL/TLS validation:
- Certificate chain validation enabled
- Hostname verification enabled
- No custom trust managers that bypass validation
When using authenticated sources:
- Use environment variables for credentials (not hardcoded)
- Rotate credentials regularly
- Use least-privilege access (read-only when possible)
When we receive a security report, we will:
- Confirm the problem and determine affected versions
- Audit code to find similar problems
- Prepare fixes for all supported versions
- Release patches as quickly as possible
- Publish security advisories on GitHub
We ask that you:
- Give us reasonable time to fix the issue before public disclosure (90 days)
- Make a good faith effort to avoid privacy violations and data destruction
- Do not exploit the vulnerability beyond proof-of-concept
- Arbitrary Code Execution: By design, JClassLoader loads and executes arbitrary classes. Only use with trusted sources.
- Hot Reload: Improper hot reload can leak memory (see issue #27 for mitigation)
- Man-in-the-Middle: Use HTTPS and verify certificates
- Credential Exposure: Never log or expose authentication credentials
- Cache Poisoning: Validate class bytes before caching
- Stale Classes: Clear cache when updating remote sources
Security updates are released as patch versions (e.g., 1.0.1, 1.1.2) and announced via:
- GitHub Security Advisories
- Release notes
- This SECURITY.md file (updates section)
For security concerns, contact the project maintainer through GitHub or the email address listed in the project's pom.xml.