• Security Policy
  • Reporting a Vulnerability
  • Severity Rating
  • Known Vulnerabilities
    • 2026
    • 2025
  • Summary Table
  • Security Best Practices
  • FIPS Compliance
  • Security Audits
  • Contact

We take the security of Cosmian KMS seriously. If you discover a security vulnerability, please report it responsibly:

1. Do not report security vulnerabilities through public GitHub issues.
2. GitHub Security Advisories (preferred): Use the private vulnerability reporting feature.
3. Email: Send details to [email protected].

What to include: A clear description, steps to reproduce, potential impact, and suggested fix if available.

Response timeline:

• Acknowledgement: within 48 hours
• Investigation: within 5 business days
• Fix: as quickly as possible, coordinated disclosure with reporter

Summary: The tracing crate's span.enter() guard was held across .await points in asynchronous request handlers. Under concurrent load (~10 parallel requests with valid JWTs), this caused worker thread panics or full server hangs. A stack trace was exposed in the HTTP error response.

Impact: Denial of Service. Any authenticated user can crash or hang the server.

Mitigation: Upgrade to 5.21.1. The fix replaces span.enter() with tracing::Instrument.

Summary: The Microsoft DKE route scope was not wrapped with the full authentication middleware stack (JWT, TLS client cert, API token). An attacker with network access could call DKE endpoints without authentication.

Impact: Authentication bypass for DKE key unwrap operations.

Mitigation: Upgrade to 5.21.1. DKE scope now includes EnsureAuth, JWT, TLS, and API token middleware.

Summary: When a key was revoked or destroyed, its decrypted material remained in the unwrap cache. Subsequent operations could still use the cached plaintext key material even after the key had been revoked.

Impact: Revoked or destroyed keys could continue to be used for cryptographic operations until cache eviction.

Mitigation: Upgrade to 5.21.1. Cache is now cleared immediately when key state transitions to Revoked, Destroyed, or Compromised.

Summary: The Google CSE rewrap endpoint accepted an attacker-controlled original_kacls_url without validation. An authenticated CSE Migrator could supply http://169.254.169.254/... or other internal URLs, causing the server to make requests to internal services (SSRF).

Impact: Server-Side Request Forgery — access to cloud metadata services, internal APIs, and private network resources.

Mitigation: Upgrade to 5.21.1. URL validation now enforces HTTPS scheme and rejects private/loopback IP ranges and internal hostnames.

Summary: When ui_session_salt was not configured, the session cookie encryption key was derived from a hardcoded default salt combined with the public URL. An attacker knowing the deployment URL could compute the session key and forge session cookies.

Impact: Session cookie forgery in deployments without explicit salt configuration.

Mitigation: Upgrade to 5.21.1. Session key derivation now incorporates private server-side configuration (database connection parameters) so that attackers cannot reproduce the key from publicly known information alone.

Summary: The Activate and Revoke operations performed object update and state change as two separate database calls. A concurrent request between the two calls could observe an inconsistent state (object updated but state unchanged).

Impact: Time-of-check-to-time-of-use race condition leading to potential state inconsistencies under concurrent load.

Mitigation: Upgrade to 5.21.1. Both operations now use AtomicOperation to batch object update and state change in a single transaction.

Summary: The /server-info endpoint was registered in the public (unauthenticated) scope, exposing server version, build information, and configuration details to unauthenticated clients.

Impact: Information disclosure — attackers can fingerprint the server version and configuration without credentials.

Mitigation: Upgrade to 5.21.1. Endpoint moved behind authentication middleware.

Summary: Server error responses (5xx) included the full internal error message, potentially leaking database connection strings, file paths, internal stack traces, and implementation details.

Impact: Information disclosure aiding further exploitation.

Mitigation: Upgrade to 5.21.1. 5xx responses now return a generic "Internal server error" message; details are logged server-side only.

Summary: The ServerParams struct's Debug implementation printed api_token_id, google_cse_migration_key, and key_wrapping_key in plaintext to logs and error messages.

Impact: Secrets leaked to log files accessible to operators or log aggregation systems.

Mitigation: Upgrade to 5.21.1. Sensitive fields are now masked as [configured] in Debug output.

Summary: ~10% of parallel malicious requests with a valid JWT could bypass authentication due to thread-safety issues and algorithm confusion in the alcoholic_jwt library (OWASP A07-1).

Impact: Authentication bypass under concurrent load.

Mitigation: Upgrade to 5.21.0. Migrated to jsonwebtoken crate with strict algorithm validation and rate-limiting via actix-governor.

Summary: When the OTLP collector is configured with an HTTP (non-TLS) endpoint, all tracing spans — including Encrypt/Decrypt operation parameters — are transmitted in cleartext, leaking query metadata (object IDs, operation types, user identifiers) to network observers.

Impact: Complete loss of confidentiality for encryption operation metadata.

Mitigation: Upgrade to 5.21.1 which rejects http:// OTLP endpoints by default. Use --otlp-allow-insecure / KMS_OTLP_ALLOW_INSECURE=true only for local development.

Summary: The KMIP Import operation with replace_existing=true did not verify ownership. Any authenticated user could overwrite any key by knowing its unique identifier.

Impact: Total key malleability — any authenticated user could replace keys belonging to other users.

Mitigation: Upgrade to 5.17.0. Ownership verification added before replacement.

Summary: The unwrap cache used SipHash with a zero key, making the hash function predictable and enabling hash-collision DoS attacks.

Impact: Denial of Service via hash flooding and potential cache poisoning.

Mitigation: Upgrade to 5.17.0. SipHash now uses a cryptographically random RandomState.

Summary: Session cookie encryption key was regenerated randomly on each restart. In multi-instance deployments, each instance used a different key, breaking session portability.

Impact: Session hijacking in load-balanced deployments; forced session re-creation on restart.

Mitigation: Upgrade to 5.15.0. Key now derived from public URL and user-provided salt.

Summary: The rsa crate was vulnerable to the Marvin Attack — a timing side-channel in PKCS#1 v1.5 signature verification enabling potential key recovery.

Impact: RSA private key recovery or signature forgery via timing analysis.

Mitigation: Upgrade to 5.15.0. The rsa crate was removed entirely; RSA operations use OpenSSL constant-time implementations.

Summary: JWT token was not forwarded to downstream services (HSM backends, delegated stores), causing them to operate without access control.

Impact: Privilege escalation — downstream services bypassed tenant isolation.

Mitigation: Upgrade to 5.14.0.

Summary: HSM-backed key unwrap operations did not enforce KMS-level permission checks. Any authenticated user could unwrap any HSM key.

Impact: Complete bypass of KMS authorization for HSM-backed keys across all tenants.

Mitigation: Upgrade to 5.13.0.

Summary: The Google CSE privilegedunwrap endpoint (administrative key recovery) was not properly guarded. Any CSE-authenticated user could invoke it.

Impact: Privilege escalation — any CSE user could unwrap any CSE-protected key.

Mitigation: Upgrade to 5.8.0. Access restricted to users with administrative permissions.

Summary: If the OIDC IDP's TLS certificate was not in the system trust store, discovery silently failed and the server operated without authentication.

Impact: Complete authentication bypass — unauthenticated access to all KMS operations.

Mitigation: Upgrade to 5.6.2. Server now fails hard on TLS errors with configurable CA certificates.

Summary: OAuth2 flow did not implement PKCE, making authorization codes vulnerable to interception and replay.

Impact: Token theft via authorization code interception.

Mitigation: Upgrade to 5.1.0. PKCE with S256 challenge method implemented.

Summary: Only the first JWT/OIDC configuration was checked during authorization. Multi-provider setups could allow bypass.

Impact: Authorization bypass in multi-provider deployments.

Mitigation: Upgrade to 5.1.1. All configured providers are now iterated.

Summary: Bundled OpenSSL upgraded to 3.6.0, addressing multiple upstream CVEs in X.509 parsing, PKCS#7 processing, and TLS handling.

Impact: Various — DoS via malformed certificates to potential RCE. See OpenSSL advisories.

Mitigation: Upgrade to 5.15.0.

Summary: Docker/package builds used glibc 2.28 with CVE-2024-2961 (iconv buffer overflow), CVE-2024-33600/33601 (nscd cache issues).

Impact: Potential RCE or DoS via crafted locale conversion or DNS resolution.

Mitigation: Upgrade to 5.16.0 (glibc 2.34).

Summary: KMS could generate X.509 certificates with negative serial numbers (non-compliant with RFC 5280), causing validation failures in strict TLS implementations.

Impact: Certificate interoperability failures.

Mitigation: Upgrade to 5.12.1.

Summary: Concurrent Google CSE key migration requests could produce inconsistent or duplicated key pairs.

Impact: Data loss — documents encrypted during the race window may become permanently undecryptable.

Mitigation: Upgrade to 5.8.0.

When using Cosmian KMS, we recommend:

1. Keep Updated: Always use the latest supported version
2. Secure Configuration: Follow the security configuration guidelines in our documentation
3. Network Security: Deploy KMS behind appropriate network security controls
4. Access Control: Implement proper authentication and authorization mechanisms
5. Monitoring: Enable logging and monitoring for security events
6. TLS Everywhere: Use TLS for all endpoints including OTLP collectors

Cosmian KMS supports FIPS 140-3 compliance when built with FIPS features enabled. KMS links against OpenSSL 3.6.0, but the FIPS build still uses the OpenSSL 3.1.2 FIPS provider for cryptographic operations because it is the official FIPS provider version available today (no more recent FIPS provider version).

This project undergoes regular security assessments. The configuration files .cargo/audit.toml and deny.toml are maintained to track and manage security advisories affecting our dependencies.

For general security questions or concerns, please contact us at [email protected].

For immediate security issues, please use the private reporting methods described above.