akanealw/Charon
1
0
Fork 0
Code Issues Pull Requests Actions 16 Packages Projects Releases Wiki Activity

fix(security): enhance vulnerability reporting and documentation in SECURITY.md

Browse Source
This commit is contained in:
GitHub Actions
2026-03-20 18:13:09 +00:00
parent 15e9efeeae
commit 586f7cfc98
1 changed files with 264 additions and 384 deletions
Download Patch File Download Diff File Expand all files Collapse all files

648
SECURITY.md
View File

@@ -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 <https://github.com/Wikid82/charon/security/advisories/new>
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 <https://github.com/Wikid82/Charon/issues>
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:
<https://search.sigstore.dev/>
### 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**: <https://search.sigstore.dev/>
- **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**: <https://github.com/Wikid82/charon/security/advisories>
- **GitHub Discussions**: <https://github.com/Wikid82/charon/discussions>
- **GitHub Issues** (non-security): <https://github.com/Wikid82/charon/issues>
---
## 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