damp is in active development. Security fixes are applied to the latest release and main.

Please do not open a public issue for security vulnerabilities. Instead, use GitHub's private vulnerability reporting:

1. Go to the repository's Security tab.
2. Click Report a vulnerability to open a private advisory.

We will acknowledge the report, investigate, and coordinate a fix and disclosure timeline with you.

• damp is primarily a desktop GUI and CLI mastering tool. Its main inputs are local audio files; processing happens locally.
• The optional REST API server (damp_server) is experimental and not built or shipped by default (build with -DBUILD_REST_SERVER=ON). When enabled it binds to 127.0.0.1 by default. Do not expose it on a public interface without authentication (--api_key); the advertised TLS options are not yet implemented.
• Loading untrusted preset JSON files is outside the current trust boundary — treat preset files like any other untrusted input and only load presets you trust. (Preset/config JSON is parsed with picojson, which has no nesting-depth limit; a pathological file can crash the process. This is a local crash, not code execution, but is another reason presets are trusted input.)
• sound_quality2_cache and resource/analysis_data archives are trusted input. The cache is a Boost.Serialization binary archive; deserializing an attacker-controlled archive is unsafe (comparable to unpickling untrusted data in Python, and Boost has no upstream fix for improper type validation — CVE-2026-11460 affects all Boost versions). Only use cache files generated locally by damp_analyzer or shipped with an official release.
• Untrusted audio-format decoding is largely delegated to ffmpeg (the copy on your PATH, or the one the GUI downloads with SHA-256 verification). Keeping ffmpeg up to date matters more for real-world attack surface than any library bundled with damp.