If you discover a security vulnerability in lean-ctx, please report it privately:
- Email: yves@pounce.ch
- GitHub: Create a private security advisory
- Response time: We aim to acknowledge reports within 48 hours
- Disclosure: We follow responsible disclosure practices (90-day embargo)
Please do NOT:
- Open public GitHub issues for security vulnerabilities
- Disclose vulnerabilities on social media or forums before we've had a chance to address them
lean-ctx is a local-only CLI tool and MCP server. Understanding its scope helps assess risk:
Does:
- Read files from your local filesystem (only files you explicitly request)
- Execute shell commands (only commands you or your AI tool explicitly invoke)
- Cache file contents in memory during a session
- Store statistics in
~/.lean-ctx/stats.json(command counts, token savings) - Store session state in
~/.lean-ctx/sessions/(task context, findings)
Optional network activity (fully disableable):
- Update check: a lightweight daily GET to
leanctx.com/version.txtto notify you of new versions. Sends only the current version as User-Agent. Disable withupdate_check_disabled = truein~/.lean-ctx/config.tomlorLEAN_CTX_NO_UPDATE_CHECK=1. - Anonymous stats sharing (opt-in, off by default): if you enable
contribute_enabledin setup, anonymized compression statistics (token counts, compression ratios — no file names, no code, no PII) are periodically sent toapi.leanctx.com.
Does NOT:
- Collect tracking analytics, fingerprints, or PII
- Access files outside of requested paths
- Store or transmit credentials, API keys, or secrets
- Require elevated privileges (runs as your user)
Every push and pull request triggers our CI security pipeline:
cargo audit— Scans dependencies for known CVEscargo clippy— Enforces Rust safety lints (warnings = errors)- Dangerous pattern scan — Detects potentially unsafe code patterns:
- Shell injection vectors (
Command::new("sh")with user input) - Network operations (
reqwest::,std::net::,hyper::) - Unsafe code blocks (
unsafe {) - Environment manipulation (
.env("LD_PRELOAD")) - Hardcoded secrets or obfuscated strings
- Shell injection vectors (
cargo test— Full test suite must pass
Changes to these files receive extra scrutiny:
| File | Risk | Why |
|---|---|---|
rust/src/shell/ |
Shell execution | Wraps your shell, executes commands |
rust/src/server/ |
MCP protocol | Handles all tool calls from AI editors/agents |
rust/src/hooks/ |
Editor integration | Installs hooks/config into Claude Code, Cursor, etc. |
rust/src/core/cache.rs |
File caching | Reads and stores file contents |
rust/Cargo.toml |
Supply chain | Dependency manifest |
.github/workflows/*.yml |
CI/CD | Release pipeline integrity |
All dependencies in Cargo.toml meet these criteria:
- Established crates: All 29 dependencies are well-known, widely-used Rust crates
- License: MIT or Apache-2.0 compatible
- Active maintenance: Recent commits within 6 months
- Minimal network:
ureq(lightweight HTTP client) used only for version check and opt-in cloud sync
Key dependencies and their purpose:
| Crate | Purpose | Downloads |
|---|---|---|
rmcp |
MCP protocol (stdio transport only) | Rust MCP reference impl |
tiktoken-rs |
Token counting (o200k_base) | OpenAI's tokenizer |
tree-sitter + grammars |
AST parsing for 18 languages | Mozilla's parser |
tokio |
Async runtime (for MCP server) | 200M+ downloads |
serde / serde_json |
JSON serialization | 400M+ downloads |
similar |
Myers diff algorithm | Well-established |
walkdir |
Directory traversal | 100M+ downloads |
Rust binaries are frequently flagged by ML-based antivirus engines (particularly Microsoft Defender's Wacatac.B!ml classifier). This is a known issue affecting many Rust projects:
- Rust lang discussion on false positives
- 1/72 engines flagging = definitively a false positive
- The
!mlsuffix inWacatac.B!mlmeans "Machine Learning detection" (heuristic, not signature-based)
Why it happens:
- Statically linked binaries (~30 MB) are unusual for Windows
strip = true+lto = trueoptimizations alter binary structure- New/unsigned executables trigger ML classifiers trained on known-good signed software
How to verify lean-ctx yourself:
- Build from source:
cargo install lean-ctx(compiles on your machine) - Compare SHA256 checksums against our GitHub Releases
- Audit the source code: the entire codebase is open source
To verify that a release binary matches the source code:
# Clone and build
git clone https://github.com/yvgude/lean-ctx.git
cd lean-ctx/rust
cargo build --release
# Compare with installed version
lean-ctx --version
./target/release/lean-ctx --versionSHA256 checksums for all release binaries are published in each GitHub Release.
When vulnerabilities are reported:
- Day 0: Acknowledgment sent to reporter
- Day 7: Severity assessment completed
- Day 14: Patch development begins
- Day 30: Patch released + CVE filed (if applicable)
- Day 90: Public disclosure
Critical vulnerabilities (RCE, data exfiltration) are fast-tracked.
- Security issues: yves@pounce.ch
- General questions: GitHub Discussions
- Discord: Join our server
Last updated: 2026-04-27