diff --git a/SECURITY.md b/SECURITY.md index 64457bdc..84178eda 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -11,60 +11,151 @@ We release security updates for the following versions: ## Reporting a Vulnerability -We take security seriously. If you discover a security vulnerability in Charon, please report it responsibly. +To report a security issue, use +[GitHub Private Security Advisories](https://github.com/Wikid82/charon/security/advisories/new) +or open a [GitHub Issue](https://github.com/Wikid82/Charon/issues) for non-sensitive disclosures. -### Where to Report +Please include a description, reproduction steps, impact assessment, and a non-destructive proof of +concept where possible. -**Preferred Method**: GitHub Security Advisory (Private) +We will acknowledge your report within **48 hours** and provide a remediation timeline within +**7 days**. Reporters are credited in release notes with their consent. We do not pursue legal +action against good-faith security researchers. Please allow **90 days** from initial report before +public disclosure. -1. Go to -2. Fill out the advisory form with: - - Vulnerability description - - Steps to reproduce - - Proof of concept (non-destructive) - - Impact assessment - - Suggested fix (if applicable) +--- -**Alternative Method**: GitHub Issues (Public) +## Known Vulnerabilities -1. Go to -2. Create a new issue with the same information as above +### [HIGH] CHARON-2026-001 · Debian Base Image CVE Cluster -### What to Include +| Field | Value | +|--------------|-------| +| **ID** | CHARON-2026-001 (aliases: CVE-2026-0861, CVE-2025-15281, CVE-2026-0915, CVE-2025-13151, and 2 libtiff HIGH CVEs) | +| **Severity** | High · 8.4 (highest per CVSS v3.1, preliminary) | +| **Status** | Fix In Progress | -Please provide: +**What** +Seven HIGH-severity CVEs in Debian Trixie base image system libraries (`glibc`, `libtasn1-6`, +`libtiff`). These vulnerabilities reside in the container's OS-level packages. No fixes are +available from the Debian Security Team. The project migrated from Alpine to Debian to avoid +CVE-2025-60876 (busybox heap overflow); now that Alpine has patched that CVE, migration back to +Alpine is underway to eliminate this cluster entirely. -1. **Description**: Clear explanation of the vulnerability -2. **Reproduction Steps**: Detailed steps to reproduce the issue -3. **Impact Assessment**: What an attacker could do with this vulnerability -4. **Environment**: Charon version, deployment method, OS, etc. -5. **Proof of Concept**: Code or commands demonstrating the vulnerability (non-destructive) -6. **Suggested Fix**: If you have ideas for remediation +**Who** +- Discovered by: Automated scan (Trivy) +- Reported: 2026-02-04 +- Affects: Container runtime environment; no known direct exploitation path through Charon's + application interface -### What Happens Next +**Where** +- Component: Debian Trixie base image (`libc6`, `libc-bin`, `libtasn1-6`, `libtiff`) +- Versions affected: All Charon container images built on Debian Trixie base -1. **Acknowledgment**: We'll acknowledge your report within **48 hours** -2. **Investigation**: We'll investigate and assess the severity -3. **Updates**: We'll provide regular status updates (weekly minimum) -4. **Fix Development**: We'll develop and test a fix -5. **Disclosure**: Coordinated disclosure after fix is released -6. **Credit**: We'll credit you in release notes (if desired) +**When** +- Discovered: 2026-02-04 +- Disclosed (if public): 2026-02-04 (internal advisory) +- Target fix: 2026-03-05 (Alpine base image migration) -### Responsible Disclosure +**How** +The affected packages are OS-level shared libraries bundled in the container base image. +Exploitation would require local access to the container or a prior application-level compromise +to reach the vulnerable library code. Caddy reverse proxy ingress filtering and container +isolation significantly reduce the effective attack surface. -We ask that you: +**Planned Remediation** +Revert to Alpine Linux base image (CVE-2025-60876 is now patched upstream). Expected outcome is +100% CVE reduction (7 HIGH → 0). -- ✅ Give us reasonable time to fix the issue before public disclosure (90 days preferred) -- ✅ Avoid destructive testing or attacks on production systems -- ✅ Not access, modify, or delete data that doesn't belong to you -- ✅ Not perform actions that could degrade service for others +- Spec: [docs/plans/alpine_migration_spec.md](docs/plans/alpine_migration_spec.md) +- Advisory: [docs/security/advisory_2026-02-04_debian_cves_temporary.md](docs/security/advisory_2026-02-04_debian_cves_temporary.md) +- Risk Assessment: [docs/security/VULNERABILITY_ACCEPTANCE.md](docs/security/VULNERABILITY_ACCEPTANCE.md) -We commit to: +--- -- ✅ Respond to your report within 48 hours -- ✅ Provide regular status updates -- ✅ Credit you in release notes (if desired) -- ✅ Not pursue legal action for good-faith security research +### [HIGH] CHARON-2025-001 · CrowdSec Bundled Binaries — Go Stdlib CVEs + +| Field | Value | +|--------------|-------| +| **ID** | CHARON-2025-001 (aliases: CVE-2025-58183, CVE-2025-58186, CVE-2025-58187, CVE-2025-61729) | +| **Severity** | High · (preliminary, CVSS scores pending upstream confirmation) | +| **Status** | Awaiting Upstream | + +**What** +Four HIGH-severity CVEs in Go standard library packages (HTTP/2 handling, TLS certificate +validation, archive parsing) present in CrowdSec binaries bundled with Charon. These vulnerabilities +exist because CrowdSec's distributed binaries were compiled against Go 1.25.1. Charon's own +application code is unaffected. + +**Who** +- Discovered by: Automated scan (Trivy) +- Reported: 2025-12-01 +- Affects: CrowdSec Agent component within the container; not directly exposed through Charon's + primary application interface + +**Where** +- Component: CrowdSec Agent (bundled `cscli` and `crowdsec` binaries) +- Versions affected: All Charon versions shipping CrowdSec binaries compiled against Go < 1.26.0 + +**When** +- Discovered: 2025-12-01 +- Disclosed (if public): Not yet publicly disclosed +- Target fix: Dependent on CrowdSec upstream release timeline + +**How** +The CVEs reside entirely within CrowdSec's compiled binaries and cover HTTP/2, TLS, and archive +processing paths that are not invoked by Charon's core application logic. The relevant network +interfaces are not externally exposed via Charon's API surface. + +**Planned Remediation** +Monitor CrowdSec releases for binaries built with Go 1.26.0+. Upgrade CrowdSec in Charon's build +pipeline as soon as a patched release is available. + +--- + +## Patched Vulnerabilities + +### ✅ [HIGH] CVE-2025-68156 · expr-lang/expr ReDoS + +| Field | Value | +|--------------|-------| +| **ID** | CVE-2025-68156 | +| **Severity** | High · 7.5 | +| **Patched** | 2026-01-11 | + +**What** +Regular Expression Denial of Service (ReDoS) vulnerability in the `expr-lang/expr` library used +by CrowdSec for expression evaluation. Malicious regular expressions in CrowdSec scenarios or +parsers could cause CPU exhaustion and service degradation through exponential backtracking. + +**Who** +- Discovered by: Automated scan (Trivy) +- Reported: 2026-01-11 + +**Where** +- Component: CrowdSec (via `expr-lang/expr` dependency) +- Versions affected: CrowdSec versions using `expr-lang/expr` < v1.17.7 + +**When** +- Discovered: 2026-01-11 +- Patched: 2026-01-11 +- Time to patch: 0 days + +**How** +Maliciously crafted regular expressions in CrowdSec scenario or parser rules could trigger +exponential backtracking in `expr-lang/expr`'s evaluation engine, causing CPU exhaustion and +denial of service. The vulnerability is in the upstream expression evaluation library, not in +Charon's own code. + +**Resolution** +Upgraded CrowdSec to build from source with the patched `expr-lang/expr` v1.17.7. Verification +confirmed via `go version -m ./cscli` showing the patched library version in compiled artifacts. +Post-patch Trivy scan reports 0 HIGH/CRITICAL vulnerabilities in application code. + +- Technical details: [docs/plans/crowdsec_source_build.md](docs/plans/crowdsec_source_build.md) + +**Credit** +Internal remediation; no external reporter. --- @@ -72,7 +163,8 @@ We commit to: ### Server-Side Request Forgery (SSRF) Protection -Charon implements industry-leading **5-layer defense-in-depth** SSRF protection to prevent attackers from using the application to access internal resources or cloud metadata. +Charon implements industry-leading **5-layer defense-in-depth** SSRF protection to prevent +attackers from using the application to access internal resources or cloud metadata. #### Protected Against @@ -100,8 +192,6 @@ Charon implements industry-leading **5-layer defense-in-depth** SSRF protection #### Learn More -For complete technical details, see: - - [SSRF Protection Guide](docs/security/ssrf-protection.md) - [Manual Test Plan](docs/issues/ssrf-manual-test-plan.md) - [QA Audit Report](docs/reports/qa_ssrf_remediation_report.md) @@ -124,7 +214,10 @@ For complete technical details, see: ### Infrastructure Security -- **Non-root by default**: Charon runs as an unprivileged user (`charon`, uid 1000) inside the container. Docker socket access is granted via a minimal supplemental group matching the host socket's GID—never by running as root. If the socket GID is `0` (root group), Charon requires explicit opt-in before granting access. +- **Non-root by default**: Charon runs as an unprivileged user (`charon`, uid 1000) inside the + container. Docker socket access is granted via a minimal supplemental group matching the host + socket's GID — never by running as root. If the socket GID is `0` (root group), Charon requires + explicit opt-in before granting access. - **Container isolation**: Docker-based deployment - **Minimal attack surface**: Alpine Linux base image - **Dependency scanning**: Regular Trivy and govulncheck scans @@ -139,6 +232,126 @@ For complete technical details, see: --- +## Supply Chain Security + +Charon implements comprehensive supply chain security measures to ensure the integrity and +authenticity of releases. Every release includes cryptographic signatures, SLSA provenance +attestation, and a Software Bill of Materials (SBOM). + +### Verification Commands + +#### Verify Container Image Signature + +All official Charon images are signed with Sigstore Cosign: + +```bash +cosign verify \ + --certificate-identity-regexp='https://github.com/Wikid82/charon' \ + --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ + ghcr.io/wikid82/charon:latest +``` + +Successful verification confirms the image was built by GitHub Actions from the official +repository and has not been tampered with since signing. + +#### Verify SLSA Provenance + +```bash +# Download provenance from release assets +curl -LO https://github.com/Wikid82/charon/releases/latest/download/provenance.json + +slsa-verifier verify-artifact \ + --provenance-path provenance.json \ + --source-uri github.com/Wikid82/charon \ + ./backend/charon-binary +``` + +#### Inspect the SBOM + +```bash +# Download SBOM from release assets +curl -LO https://github.com/Wikid82/charon/releases/latest/download/sbom.spdx.json + +# Scan for known vulnerabilities +grype sbom:sbom.spdx.json +``` + +### Transparency Log (Rekor) + +All signatures are recorded in the public Sigstore Rekor transparency log: + + +### Digest Pinning Policy + +**Scope (Required):** + +- CI workflows: `.github/workflows/*.yml` +- CI compose files: `.docker/compose/*.yml` +- CI helper actions with container refs: `.github/actions/**/*.yml` + +CI workflows and CI compose files MUST use digest-pinned images for third-party services. +Tag+digest pairs are preferred for human-readable references with immutable resolution. +Self-built images MUST propagate digests to downstream jobs and tests. + +**Local Development Exceptions:** + +Local-only overrides (e.g., `CHARON_E2E_IMAGE`, `CHARON_IMAGE`, `CHARON_DEV_IMAGE`) MAY use tags +for developer iteration. Tag-only overrides MUST NOT be used in CI contexts. + +**Documented Exceptions & Compensating Controls:** + +1. **Go toolchain shim** (`golang.org/dl/goX.Y.Z@latest`) — Uses `@latest` to install the shim; + compensated by the target toolchain version being pinned in `go.work` with Renovate tracking. +2. **Unpinnable dependencies** — Require documented justification; prefer vendor checksums or + signed releases; keep SBOM/vulnerability scans in CI. + +### Learn More + +- [User Guide](docs/guides/supply-chain-security-user-guide.md) +- [Developer Guide](docs/guides/supply-chain-security-developer-guide.md) +- [Sigstore Documentation](https://docs.sigstore.dev/) +- [SLSA Framework](https://slsa.dev/) + +--- + +## Security Audits & Scanning + +### Automated Scanning + +| Tool | Purpose | +|------|---------| +| Trivy | Container image vulnerability scanning | +| CodeQL | Static analysis for Go and JavaScript | +| govulncheck | Go module vulnerability scanning | +| golangci-lint (gosec) | Go code linting | +| npm audit | Frontend dependency scanning | + +### Scanning Workflows + +**Docker Build & Scan** (`.github/workflows/docker-build.yml`) — runs on every commit to `main`, +`development`, and `feature/beta-release`, and on all PRs targeting those branches. Performs Trivy +scanning, generates an SBOM, creates SBOM attestations, and uploads SARIF results to the GitHub +Security tab. + +**Supply Chain Verification** (`.github/workflows/supply-chain-verify.yml`) — triggers +automatically via `workflow_run` after a successful docker-build. Runs SBOM completeness checks, +Grype vulnerability scans, and (on releases) Cosign signature and SLSA provenance validation. + +**Weekly Security Rebuild** (`.github/workflows/security-weekly-rebuild.yml`) — runs every Sunday +at 02:00 UTC. Performs a full no-cache rebuild, scans for all severity levels, and retains JSON +artifacts for 90 days. + +**PR-Specific Scanning** — extracts and scans only the Charon application binary on each pull +request. Fails the PR if CRITICAL or HIGH vulnerabilities are found in application code. + +### Manual Reviews + +- Security code reviews for all major features +- Peer review of security-sensitive changes +- Third-party security audits (planned) + +--- + ## Security Best Practices ### Deployment Recommendations @@ -153,26 +366,25 @@ For complete technical details, see: ### Configuration Hardening ```yaml -# Recommended docker-compose.yml settings services: charon: image: ghcr.io/wikid82/charon:latest restart: unless-stopped environment: - CHARON_ENV=production - - LOG_LEVEL=info # Don't use debug in production + - LOG_LEVEL=info volumes: - ./charon-data:/app/data:rw - - /var/run/docker.sock:/var/run/docker.sock:ro # Read-only! + - /var/run/docker.sock:/var/run/docker.sock:ro networks: - - charon-internal # Isolated network + - charon-internal cap_drop: - ALL cap_add: - - NET_BIND_SERVICE # Only if binding to ports < 1024 + - NET_BIND_SERVICE security_opt: - no-new-privileges:true - read_only: true # If possible + read_only: true tmpfs: - /tmp:noexec,nosuid,nodev ``` @@ -182,9 +394,8 @@ services: Gotify application tokens are secrets and must be handled with strict confidentiality. - Never echo, print, log, or return token values in API responses or errors. -- Never expose tokenized endpoint query strings (for example, - `...?token=...`) in logs, diagnostics, examples, screenshots, - tickets, or reports. +- Never expose tokenized endpoint query strings (e.g., `...?token=...`) in logs, diagnostics, + examples, screenshots, tickets, or reports. - Always redact query parameters in diagnostics and examples before display or storage. - Use write-only token inputs in operator workflows and UI forms. - Store tokens only in environment variables or a dedicated secret manager. @@ -200,322 +411,6 @@ Gotify application tokens are secrets and must be handled with strict confidenti --- -## Supply Chain Security - -Charon implements comprehensive supply chain security measures to ensure the integrity and authenticity of releases. Every release includes cryptographic signatures, SLSA provenance attestation, and Software Bill of Materials (SBOM). - -### Verification Commands - -#### Verify Container Image Signature - -All official Charon images are signed with Sigstore Cosign: - -```bash -# Install cosign (if not already installed) -curl -LO https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -sudo mv cosign-linux-amd64 /usr/local/bin/cosign -sudo chmod +x /usr/local/bin/cosign - -# Verify image signature -cosign verify \ - --certificate-identity-regexp='https://github.com/Wikid82/charon' \ - --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ - ghcr.io/wikid82/charon:latest -``` - -Successful verification output confirms: - -- The image was built by GitHub Actions -- The build came from the official Charon repository -- The image has not been tampered with since signing - -#### Verify SLSA Provenance - -SLSA (Supply-chain Levels for Software Artifacts) provenance provides tamper-proof evidence of how the software was built: - -```bash -# Install slsa-verifier (if not already installed) -curl -LO https://github.com/slsa-framework/slsa-verifier/releases/latest/download/slsa-verifier-linux-amd64 -sudo mv slsa-verifier-linux-amd64 /usr/local/bin/slsa-verifier -sudo chmod +x /usr/local/bin/slsa-verifier - -# Download provenance from release assets -curl -LO https://github.com/Wikid82/charon/releases/latest/download/provenance.json - -# Verify provenance -slsa-verifier verify-artifact \ - --provenance-path provenance.json \ - --source-uri github.com/Wikid82/charon \ - ./backend/charon-binary -``` - -#### Inspect Software Bill of Materials (SBOM) - -Every release includes a comprehensive SBOM in SPDX format: - -```bash -# Download SBOM from release assets -curl -LO https://github.com/Wikid82/charon/releases/latest/download/sbom.spdx.json - -# View SBOM contents -cat sbom.spdx.json | jq . - -# Check for known vulnerabilities (requires Grype) -grype sbom:sbom.spdx.json -``` - -### Transparency Log (Rekor) - -All signatures are recorded in the public Sigstore Rekor transparency log, providing an immutable audit trail: - -- **Search the log**: -- **Query by image**: Search for `ghcr.io/wikid82/charon` -- **View entry details**: Each entry includes commit SHA, workflow run, and signing timestamp - -### Automated Verification in CI/CD - -Integrate supply chain verification into your deployment pipeline: - -```yaml -# Example GitHub Actions workflow -- name: Verify Charon Image - run: | - cosign verify \ - --certificate-identity-regexp='https://github.com/Wikid82/charon' \ - --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ - ghcr.io/wikid82/charon:${{ env.VERSION }} -``` - -### What's Protected - -- **Container Images**: All `ghcr.io/wikid82/charon:*` images are signed -- **Release Binaries**: Backend binaries include provenance attestation -- **Build Process**: SLSA Level 3 compliant build provenance -- **Dependencies**: Complete SBOM including all direct and transitive dependencies - -### Digest Pinning Policy - -Charon uses digest pinning to reduce supply chain risk and ensure CI runs against immutable artifacts. - -**Scope (Required):** - -- **CI workflows**: `.github/workflows/*.yml`, `.github/workflows/*.yaml` -- **CI compose files**: `.docker/compose/*.yml`, `.docker/compose/*.yaml`, `.docker/compose/docker-compose*.yml`, `.docker/compose/docker-compose*.yaml` -- **CI helper actions with container refs**: `.github/actions/**/*.yml`, `.github/actions/**/*.yaml` -- CI workflows and CI compose files MUST use digest-pinned images for third-party services. -- Tag+digest pairs are preferred for human-readable references with immutable resolution. -- Self-built images MUST propagate digests to downstream jobs and tests. - -**Rationale:** - -- Prevent tag drift and supply chain substitution in automated runs. -- Ensure deterministic builds, reproducible scans, and stable SBOM generation. -- Reduce rollback risk by guaranteeing CI uses immutable artifacts. - -**Local Development Exceptions:** - -- Local-only overrides (e.g., `CHARON_E2E_IMAGE`, `CHARON_IMAGE`, `CHARON_DEV_IMAGE`) MAY use tags for developer iteration. -- Tag-only overrides MUST NOT be used in CI contexts. - -**Documented Exceptions & Compensating Controls:** - -1. **Go toolchain shim** (`golang.org/dl/goX.Y.Z@latest`) - - **Exception:** Uses `@latest` to install the shim. - - **Compensating controls:** The target toolchain version is pinned in - `go.work`, and Renovate tracks the required version for updates. - -2. **Unpinnable dependencies** (no stable digest or checksum source) - - **Exception:** Dependency cannot be pinned by digest. - - **Compensating controls:** Require documented justification, prefer - vendor-provided checksums or signed releases when available, and keep - SBOM/vulnerability scans in CI. - -### Learn More - -- **[User Guide](docs/guides/supply-chain-security-user-guide.md)**: Step-by-step verification instructions -- **[Developer Guide](docs/guides/supply-chain-security-developer-guide.md)**: Integration into development workflow -- **[Sigstore Documentation](https://docs.sigstore.dev/)**: Technical details on signing and verification -- **[SLSA Framework](https://slsa.dev/)**: Supply chain security framework overview - ---- - -## Security Audits & Scanning - -### Automated Scanning - -We use the following tools: - -- **Trivy**: Container image vulnerability scanning -- **CodeQL**: Static code analysis for Go and JavaScript -- **govulncheck**: Go module vulnerability scanning -- **golangci-lint**: Go code linting (including gosec) -- **npm audit**: Frontend dependency vulnerability scanning - -### Security Scanning Workflows - -Charon implements multiple layers of automated security scanning: - -#### Docker Build & Scan (Per-Commit) - -**Workflow**: `.github/workflows/docker-build.yml` - -- Runs on every commit to `main`, `development`, and `feature/beta-release` branches -- Runs on all pull requests targeting these branches -- Performs Trivy vulnerability scanning on built images -- Generates SBOM (Software Bill of Materials) for supply chain transparency -- Creates SBOM attestations for verifiable build provenance -- Verifies Caddy security patches (CVE-2025-68156) -- Uploads SARIF results to GitHub Security tab - -**Note**: This workflow replaced the previous `docker-publish.yml` (deleted Dec 21, 2025) with enhanced security features. - -#### Supply Chain Verification - -**Workflow**: `.github/workflows/supply-chain-verify.yml` - -**Trigger Timing**: Runs automatically after `docker-build.yml` completes successfully via `workflow_run` trigger. - -**Branch Coverage**: Triggers on **ALL branches** where docker-build completes, including: - -- `main` (default branch) -- `development` -- `feature/*` branches (including `feature/beta-release`) -- Pull request branches - -**Why No Branch Filter**: GitHub Actions has a platform limitation where `branches` filters in `workflow_run` triggers only match the default branch. To ensure comprehensive supply chain verification across all branches and PRs, we intentionally omit the branch filter. The workflow file must exist on the branch to execute, preventing untrusted code execution. - -**Verification Steps**: - -1. SBOM completeness verification -2. Vulnerability scanning with Grype -3. Results uploaded as workflow artifacts -4. PR comments with vulnerability summary (when applicable) -5. For releases: Cosign signature verification and SLSA provenance validation - -**Additional Triggers**: - -- Runs on all published releases -- Scheduled weekly on Mondays at 00:00 UTC -- Can be triggered manually via `workflow_dispatch` - -#### Weekly Security Rebuild - -**Workflow**: `.github/workflows/security-weekly-rebuild.yml` - -- Runs every Sunday at 02:00 UTC -- Performs full rebuild with no cache to ensure latest base images -- Scans with Trivy for CRITICAL, HIGH, MEDIUM, and LOW vulnerabilities -- Uploads results to GitHub Security tab -- Stores JSON artifacts for 90-day retention -- Checks Alpine package versions for security updates - -#### PR-Specific Scanning - -**Workflow**: `.github/workflows/docker-build.yml` (trivy-pr-app-only job) - -- Runs on all pull requests -- Extracts and scans only the Charon application binary -- Fails PR if CRITICAL or HIGH vulnerabilities found in application code -- Faster feedback loop for developers during code review - -### Workflow Orchestration - -The security scanning workflows use a coordinated orchestration pattern: - -1. **Build Phase**: `docker-build.yml` builds the image and performs initial Trivy scan -2. **Verification Phase**: `supply-chain-verify.yml` triggers automatically via `workflow_run` after successful build -3. **Verification Timing**: - - On feature branches: Runs after docker-build completes on push events - - On pull requests: Runs after docker-build completes on PR synchronize events - - No delay or gaps: verification starts immediately after build success -4. **Weekly Maintenance**: `security-weekly-rebuild.yml` provides ongoing monitoring - -This pattern ensures: - -- Images are built before verification attempts to scan them -- No race conditions between build and verification -- Comprehensive coverage across all branches and PRs -- Efficient resource usage (verification only runs after successful builds) - -### Manual Reviews - -- Security code reviews for all major features -- Peer review of security-sensitive changes -- Third-party security audits (planned) - -### Continuous Monitoring - -- GitHub Dependabot alerts -- Weekly security scans in CI/CD -- Community vulnerability reports -- Automated supply chain verification on every build - ---- - -## Recently Resolved Vulnerabilities - -Charon maintains transparency about security issues and their resolution. Below is a comprehensive record of recently patched vulnerabilities. - -### CVE-2025-68156 (expr-lang/expr ReDoS) - -- **Severity**: HIGH (CVSS 7.5) -- **Component**: expr-lang/expr (used by CrowdSec for expression evaluation) -- **Vulnerability**: Regular Expression Denial of Service (ReDoS) -- **Description**: Malicious regular expressions in CrowdSec scenarios or parsers could cause CPU exhaustion and service degradation through exponential backtracking in vulnerable regex patterns. -- **Fixed Version**: expr-lang/expr v1.17.7 -- **Resolution Date**: January 11, 2026 -- **Remediation**: Upgraded CrowdSec to build from source with patched expr-lang/expr v1.17.7 -- **Verification**: - - Binary inspection: `go version -m ./cscli` confirms v1.17.7 in compiled artifacts - - Container scan: Trivy reports 0 HIGH/CRITICAL vulnerabilities in application code - - Runtime testing: CrowdSec scenarios and parsers load successfully with patched library -- **Impact**: No known exploits in Charon deployments; preventive upgrade completed -- **Status**: ✅ **PATCHED** — Verified in all release artifacts -- **Technical Details**: See [CrowdSec Source Build Documentation](docs/plans/crowdsec_source_build.md) - ---- - -## Known Security Considerations - -### Debian Base Image CVEs (2026-02-04) — TEMPORARY - -**Status**: ⚠️ 7 HIGH severity CVEs in Debian Trixie base image. **Alpine migration in progress.** - -**Background**: Migrated from Alpine → Debian due to CVE-2025-60876 (busybox heap overflow). Debian now has worse CVE posture with no fixes available. Reverting to Alpine as Alpine CVE-2025-60876 is now patched. - -**Affected Packages**: -- **libc6/libc-bin** (glibc): CVE-2026-0861 (CVSS 8.4), CVE-2025-15281, CVE-2026-0915 -- **libtasn1-6**: CVE-2025-13151 (CVSS 7.5) -- **libtiff**: 2 additional HIGH CVEs - -**Fix Status**: ❌ No fixes available from Debian Security Team - -**Risk Assessment**: 🟢 **LOW actual risk** -- CVEs affect system libraries, NOT Charon application code -- Container isolation limits exploit surface area -- No direct exploit paths identified in Charon's usage patterns -- Network ingress filtered through Caddy proxy - -**Mitigation**: Alpine base image migration -- **Spec**: [`docs/plans/alpine_migration_spec.md`](docs/plans/alpine_migration_spec.md) -- **Security Advisory**: [`docs/security/advisory_2026-02-04_debian_cves_temporary.md`](docs/security/advisory_2026-02-04_debian_cves_temporary.md) -- **Timeline**: 2-3 weeks (target completion: March 5, 2026) -- **Expected Outcome**: 100% CVE reduction (7 HIGH → 0) - -**Review Date**: 2026-02-11 (Phase 1 Alpine CVE verification) - -**Details**: See [VULNERABILITY_ACCEPTANCE.md](docs/security/VULNERABILITY_ACCEPTANCE.md) for complete risk assessment and monitoring plan. - -### Third-Party Dependencies - -**CrowdSec Binaries**: As of December 2025, CrowdSec binaries shipped with Charon contain 4 HIGH-severity CVEs in Go stdlib (CVE-2025-58183, CVE-2025-58186, CVE-2025-58187, CVE-2025-61729). These are upstream issues in Go 1.25.1 and will be resolved when CrowdSec releases binaries built with go 1.26.0+. - -**Impact**: Low. These vulnerabilities are in CrowdSec's third-party binaries, not in Charon's application code. They affect HTTP/2, TLS certificate handling, and archive parsing—areas not directly exposed to attackers through Charon's interface. - -**Mitigation**: Monitor CrowdSec releases for updated binaries. Charon's own application code has zero vulnerabilities. - ---- - ## Security Hall of Fame We recognize security researchers who help improve Charon: @@ -525,19 +420,4 @@ We recognize security researchers who help improve Charon: --- -## Security Contact - -- **GitHub Security Advisories**: -- **GitHub Discussions**: -- **GitHub Issues** (non-security): - ---- - -## License - -This security policy is part of the Charon project, licensed under the MIT License. - ---- - -**Last Updated**: January 30, 2026 -**Version**: 1.2 +**Last Updated**: 2026-03-20