We release security updates for the following versions:

To report a security issue, use GitHub Private Security Advisories or open a GitHub Issue for non-sensitive disclosures.

Please include a description, reproduction steps, impact assessment, and a non-destructive proof of concept where possible.

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.

Last reviewed: 2026-03-24

What An OpenSSL TLS 1.3 server may fail to negotiate the intended key exchange group when the configuration includes the DEFAULT keyword, potentially allowing downgrade to weaker cipher suites. Affects Alpine 3.23.3 packages libcrypto3 and libssl3 at version 3.5.5-r0.

Who

• Discovered by: Automated scan (Grype)
• Reported: 2026-03-20
• Affects: Container runtime environment; Caddy reverse proxy TLS negotiation could be affected if default key group configuration is used

Where

• Component: Alpine 3.23.3 base image (libcrypto3 3.5.5-r0, libssl3 3.5.5-r0)
• Versions affected: Alpine 3.23.3 prior to a patched openssl APK release

When

• Discovered: 2026-03-20
• Disclosed (if public): 2026-03-13 (OpenSSL advisory)
• Target fix: When Alpine Security publishes a patched openssl APK

How When an OpenSSL TLS 1.3 server configuration uses the DEFAULT keyword for key exchange groups, the negotiation logic may select a weaker group than intended. Charon's Caddy TLS configuration does not use the DEFAULT keyword, which limits practical exploitability. The packages are present in the base image regardless of Caddy's configuration.

Planned Remediation Monitor https://security.alpinelinux.org/vuln/CVE-2026-2673 for a patched Alpine APK. Once available, update the pinned ALPINE_IMAGE digest in the Dockerfile, or add an explicit RUN apk upgrade --no-cache libcrypto3 libssl3 to the runtime stage.

What BusyBox wget through 1.37 accepts raw CR/LF and other C0 control bytes in the HTTP request-target, allowing request line splitting and header injection (CWE-284).

Who

• Discovered by: Automated scan (Grype)
• Reported: 2026-03-24
• Affects: Container runtime environment; Charon does not invoke busybox wget in application logic

Where

• Component: Alpine 3.23.3 base image (busybox 1.37.0-r30)
• Versions affected: All Charon images using Alpine 3.23.3 with busybox < patched version

When

• Discovered: 2026-03-24
• Disclosed (if public): Not yet publicly disclosed with fix
• Target fix: When Alpine Security publishes a patched busybox APK

How The vulnerable wget applet would need to be manually invoked inside the container with attacker-controlled URLs. Charon's application logic does not use busybox wget. EPSS score is 0.00064 (0.20 percentile), indicating extremely low exploitation probability.

Planned Remediation Monitor Alpine 3.23 for a patched busybox APK. No immediate action required. Practical risk to Charon users is negligible since the vulnerable code path is not exercised.

What filippo.io/edwards25519 v1.1.0 MultiScalarMult produces invalid results or undefined behavior if the receiver is not the identity point. Fix available at v1.1.1 but requires CrowdSec to rebuild.

Who

• Discovered by: Automated scan (Grype)
• Reported: 2026-03-24
• 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: CrowdSec builds using filippo.io/edwards25519 < v1.1.1

When

• Discovered: 2026-03-24
• Disclosed (if public): Public
• Target fix: When CrowdSec releases a build with updated dependency

How This is a rarely used advanced API within the edwards25519 library. CrowdSec does not directly expose MultiScalarMult to external input. EPSS score is 0.00018 (0.04 percentile).

Planned Remediation Awaiting CrowdSec upstream release with updated dependency. No action available for Charon maintainers.

What A critical Go standard library vulnerability affects CrowdSec binaries bundled in the Charon container image. The binaries were compiled against Go 1.25.6, which contains this flaw. Charon's own application code, compiled with Go 1.26.1, is unaffected.

Who

• Discovered by: Automated scan (Grype)
• Reported: 2026-03-20

Where

• Component: CrowdSec Agent (bundled cscli and crowdsec binaries)
• Versions affected: Charon container images with CrowdSec binaries compiled against Go < 1.25.7

When

• Discovered: 2026-03-20
• Patched: 2026-03-24
• Time to patch: 4 days

How The vulnerability resides entirely within CrowdSec's compiled binary artifacts. Exploitation is limited to the CrowdSec agent's internal execution paths, which are not externally exposed through Charon's API or network interface.

Resolution CrowdSec binaries now compiled with Go 1.26.1 (was 1.25.6).

What Multiple CVEs in Go standard library packages continue to accumulate in CrowdSec binaries bundled with Charon. The cluster originated when CrowdSec was compiled against Go 1.25.1; subsequent CrowdSec updates advanced the toolchain to Go 1.25.6/1.25.7, resolving earlier CVEs but introducing new ones. The cluster now includes a Critical-severity finding (CVE-2025-68121, tracked separately above). All issues resolve when CrowdSec is rebuilt against Go ≥ 1.26.2. Charon's own application code is unaffected.

Who

• Discovered by: Automated scan (Trivy, Grype)
• Reported: 2025-12-01 (original cluster); expanded 2026-03-20

Where

• Component: CrowdSec Agent (bundled cscli and crowdsec binaries)
• Versions affected: All Charon versions shipping CrowdSec binaries compiled against Go < 1.26.2

When

• Discovered: 2025-12-01
• Patched: 2026-03-24
• Time to patch: 114 days

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.

Resolution CrowdSec binaries now compiled with Go 1.26.1.

What zlib before 1.3.2 allows unbounded CPU consumption (denial of service) via the crc32_combine64 and crc32_combine_gen64 functions. An internal helper x2nmodp performs right-shifts inside a loop with no termination condition when given a specially crafted input, causing a CPU spin (CWE-1284).

Who

• Discovered by: 7aSecurity audit (commissioned by OSTIF)
• Reported: 2026-02-17

Where

• Component: Alpine 3.23.3 base image (zlib package, version 1.3.1-r2)
• Versions affected: zlib < 1.3.2; all current Charon images using Alpine 3.23.3

When

• Discovered: 2026-02-17
• Patched: 2026-03-24
• Time to patch: 35 days

How Exploitation requires local access (CVSS vector AV:L) and the ability to pass a crafted value to the crc32_combine-family functions. This code path is not invoked by Charon's reverse proxy or backend API. The vulnerability is non-blocking under the project's CI severity policy.

Resolution Alpine now ships zlib 1.3.2-r0 (fix threshold was 1.3.2).

What Seven HIGH-severity CVEs in Debian Trixie base image system libraries (glibc, libtasn1-6, libtiff). These vulnerabilities resided in the container's OS-level packages with no fixes available from the Debian Security Team.

Who

• Discovered by: Automated scan (Trivy)
• Reported: 2026-02-04

Where

• Component: Debian Trixie base image (libc6, libc-bin, libtasn1-6, libtiff)
• Versions affected: Charon container images built on Debian Trixie base (prior to Alpine migration)

When

• Discovered: 2026-02-04
• Patched: 2026-03-20
• Time to patch: 44 days

How The affected packages were OS-level shared libraries bundled in the Debian Trixie container base image. Exploitation would have required local container access or a prior application-level compromise. Caddy reverse proxy ingress filtering and container isolation significantly reduced the effective attack surface throughout the exposure window.

Resolution Reverted to Alpine Linux base image (Alpine 3.23.3). Alpine's patch of CVE-2025-60876 (busybox heap overflow) removed the original blocker for the Alpine migration. Post-migration scan confirmed zero HIGH/CRITICAL CVEs from this cluster.

• Spec: docs/plans/alpine_migration_spec.md
• Advisory: docs/security/advisory_2026-02-04_debian_cves_temporary.md

Credit Internal remediation; no external reporter.

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

Credit Internal remediation; no external reporter.

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.

• Private network access (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Cloud provider metadata endpoints (AWS, Azure, GCP: 169.254.169.254)
• Localhost and loopback addresses (127.0.0.0/8, ::1/128)
• Link-local addresses (169.254.0.0/16, fe80::/10)
• IPv6-mapped IPv4 bypass attempts (::ffff:127.0.0.1)
• Protocol bypass attacks (file://, ftp://, gopher://, data:)

1. URL Format Validation: Scheme, syntax, and structure checks
2. DNS Resolution: Hostname resolution with timeout protection
3. IP Range Validation: ALL resolved IPs checked against 13+ CIDR blocks
4. Connection-Time Validation: Re-validation at TCP dial (prevents DNS rebinding)
5. Redirect Validation: Each redirect target validated before following

• Security notification webhooks
• Custom webhook notifications
• CrowdSec hub synchronization
• External URL connectivity testing (admin-only)

• SSRF Protection Guide
• Manual Test Plan
• QA Audit Report

• JWT-based authentication: Secure token-based sessions
• Role-based access control: Admin vs. user permissions
• Session management: Automatic expiration and renewal
• Secure cookie attributes: HttpOnly, Secure (HTTPS), SameSite

• Database encryption: Sensitive data encrypted at rest
• Secure credential storage: Hashed passwords, encrypted API keys
• Input validation: All user inputs sanitized and validated
• Output encoding: XSS protection via proper encoding

• 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
• No unnecessary services: Single-purpose container design

• Coraza WAF integration: OWASP Core Rule Set support
• Rate limiting: Protection against brute-force and DoS
• IP allowlisting/blocklisting: Network access control
• CrowdSec integration: Collaborative threat intelligence

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).

All official Charon images are signed with Sigstore Cosign:

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.

# 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

# 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

All signatures are recorded in the public Sigstore Rekor transparency log: https://search.sigstore.dev/

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.

• User Guide
• Developer Guide
• Sigstore Documentation
• SLSA Framework

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.

• Security code reviews for all major features
• Peer review of security-sensitive changes
• Third-party security audits (planned)

1. Use HTTPS: Always deploy behind a reverse proxy with TLS
2. Restrict Admin Access: Limit admin panel to trusted IPs
3. Regular Updates: Keep Charon and dependencies up to date
4. Secure Webhooks: Only use trusted webhook endpoints
5. Strong Passwords: Enforce password complexity policies
6. Backup Encryption: Encrypt backup files before storage

services:
  charon:
    image: ghcr.io/wikid82/charon:latest
    restart: unless-stopped
    environment:
      - CHARON_ENV=production
      - LOG_LEVEL=info
    volumes:
      - ./charon-data:/app/data:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - charon-internal
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,nodev

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 (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.
• Validate Gotify endpoints over HTTPS only.
• Rotate tokens immediately on suspected exposure.

• Firewall Rules: Only expose necessary ports (80, 443, 8080)
• VPN Access: Use VPN for admin access in production
• Fail2Ban: Consider fail2ban for brute-force protection
• Intrusion Detection: Enable CrowdSec for threat detection

We recognize security researchers who help improve Charon:

• Your name could be here!

Last Updated: 2026-03-24