- Security Policy
- Reporting a Vulnerability
- Severity Rating
- Known Vulnerabilities
- 2026
- COSMIAN-2026-018 — Activate operation uses overly permissive authorization check
- COSMIAN-2026-017 — ReKey / ReKeyKeyPair authorization bypass via raw object retrieval
- COSMIAN-2026-016 — Attribute-mutation authorization bypass via incorrect operation type
- COSMIAN-2026-015 — KEK plaintext leak via
UsageLimitspersist in Decrypt and Sign - COSMIAN-2026-014 — Sensitive configuration values exposed in Debug output
- COSMIAN-2026-013 — Internal error details leaked in HTTP 5xx responses
- COSMIAN-2026-012 —
/server-infoendpoint accessible without authentication - COSMIAN-2026-011 — Non-atomic state transitions enable TOCTOU races
- COSMIAN-2026-010 — Predictable default session cookie salt
- COSMIAN-2026-009 — Google CSE rewrap SSRF via
original_kacls_url - COSMIAN-2026-008 — Unwrap cache not invalidated on key revocation/destruction
- COSMIAN-2026-007 — MS DKE scope missing authentication middleware
- COSMIAN-2026-006 — Server crash under concurrent requests due to tracing span misuse
- COSMIAN-2026-005 — JWT decoding race condition causing intermittent authentication bypass
- COSMIAN-2026-004 — OTLP telemetry exported over plaintext HTTP leaks encryption queries
- COSMIAN-2026-003 — KMIP Import
replace_existingbypasses ownership verification - COSMIAN-2026-002 — SipHash key hardcoded to zero in unwrap cache
- 2025
- COSMIAN-2025-003 — glibc CVEs in container base image (CVE-2024-2961, CVE-2024-33600, CVE-2024-33601)
- COSMIAN-2025-012 — Session cookie encryption key randomly regenerated on each restart
- COSMIAN-2025-011 — RUSTSEC-2023-0071: RSA Marvin Attack timing side-channel
- COSMIAN-2025-004 — OpenSSL 3.x CVEs addressed by upgrade to 3.6.2
- COSMIAN-2025-010 — JWT authentication token not forwarded to downstream services
- COSMIAN-2025-009 — HSM unwrap operation bypasses KMS permission checks
- COSMIAN-2025-002 — Negative X.509 certificate serial numbers
- COSMIAN-2025-008 — Google CSE
privilegedunwrapendpoint unrestricted access - COSMIAN-2025-001 — CSE migration key pair race condition
- COSMIAN-2025-007 — OpenID Connect authentication silently falls back to no-auth on TLS failure
- COSMIAN-2025-006 — Missing PKCE in OAuth2 authentication flow
- COSMIAN-2025-005 — JWT authorization config loop — only first OIDC provider checked
- 2026
- 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:
- Do not report security vulnerabilities through public GitHub issues.
- GitHub Security Advisories (preferred): Use the private vulnerability reporting feature.
- Email: Send details to tech@cosmian.com.
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
| Rating | Description |
|---|---|
| Critical | Directly impacts key confidentiality, integrity, or authentication bypass for any authenticated user |
| High | Impacts availability or enables privilege escalation under realistic attack conditions |
| Moderate | Requires specific conditions, limited scope, or no direct key compromise |
| Low | Minimal practical impact or very difficult to exploit |
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 26 May 2026 |
| Affected | from 5.0.0 before 5.23.0 |
| Fixed in | 5.23.0 |
| Found by | Copilot code review (GitHub PR #961) |
| References | #961 |
Summary: The KMIP Activate operation passed KmipOperation::GetAttributes as the operation type to retrieve_object_for_operation. The permission check for GetAttributes grants access to any user holding any operation grant on the object. This meant a user with only Encrypt permission could activate a PreActive key, changing its lifecycle state — a security-relevant state transition that should require explicit authorization.
Impact: Privilege escalation: a user with a minimal grant (e.g., encrypt-only) could force-activate a key that was intentionally kept in PreActive state (e.g., with a future activation date), bypassing the key lifecycle controls set by the key owner.
Mitigation: Upgrade to 5.23.0. A new KmipOperation::Activate variant is introduced and the Activate operation now uses it for the permission check, requiring explicit Activate grant, Get wildcard, or ownership.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 26 May 2026 |
| Affected | from 5.0.0 before 5.23.0 |
| Fixed in | 5.23.0 |
| Found by | Copilot code review (GitHub PR #961) |
| References | #961 |
Summary: The KMIP ReKey operation for symmetric keys called database.retrieve_objects() without ownership or permission verification. Any authenticated user who knew (or guessed) another user's key UID could invoke ReKey to: (1) create a replacement key owned by the attacker, (2) strip the Name attribute from the victim's original key, and (3) set cross-links between the old and new key. The ReKeyKeyPair operation (Covercrypt) had the same raw retrieval pattern, though downstream kms.get() calls provided a secondary authorization barrier.
Impact: Full authorization bypass for ReKey: any authenticated user can rekey any symmetric key in the system, effectively taking control of the replacement key and disrupting the original key's metadata. For ReKeyKeyPair, the impact is limited to information leakage (object existence/type disclosure) since downstream operations enforce authorization.
Mitigation: Upgrade to 5.23.0. Both operations now call user_can_perform_operation() immediately after object retrieval, verifying that the caller owns the target key or has been explicitly granted the Rekey operation.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 25 May 2026 |
| Affected | from 5.0.0 before 5.23.0 |
| Fixed in | 5.23.0 |
| Found by | Copilot code review (GitHub PR #959) |
| References | #960 |
Summary: The SetAttribute, ModifyAttribute, AddAttribute, and DeleteAttribute KMIP operations all passed KmipOperation::GetAttributes as the operation type to retrieve_object_for_operation. That function's permission check uses a relaxed "any-permission" policy for GetAttributes, so any user holding any grant on an object (e.g., Encrypt-only) could mutate its attributes — including security-sensitive attributes such as CryptographicUsageMask — without the required Modify or full-access grant.
Impact: Privilege escalation: a user with a limited grant (e.g., encrypt-only) could change key attributes, potentially widening the usage mask, altering sensitive metadata, or compromising the key's intended usage restrictions.
Mitigation: Upgrade to 5.23.0. Each attribute-mutation operation now uses its own KmipOperation variant (SetAttribute, ModifyAttribute, AddAttribute, DeleteAttribute), which enforces the correct permission check (explicit grant or Get wildcard required).
| Field | Value |
|---|---|
| Severity | High |
| Published | 25 May 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian engineering |
| References | #959 |
Summary: The decrypt.rs and sign.rs operations called unwrap_and_enforce_policy on the fetched key object, which decrypted the key material in-place. The subsequent decrement_usage_limits call then persisted this modified (plaintext) object back to the database, silently stripping the KEK encryption at rest. Any key with a UsageLimits attribute and an active KEK wrapping was vulnerable.
Impact: Loss of encryption-at-rest for keys protected by a Key Encryption Key (KEK). After the first Decrypt or Sign operation on such a key, the database stored its plaintext material, making future database-level protection ineffective.
Mitigation: Upgrade to 5.22.0. The fix decouples the usage-limit decrement from the unwrapped object path: decrement_usage_limits now operates on the original wrapped object fetched directly from the database, never on the in-place-unwrapped copy.
| Field | Value |
|---|---|
| Severity | Low |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. Sensitive fields are now masked as [configured] in Debug output.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. 5xx responses now return a generic "Internal server error" message; details are logged server-side only.
| Field | Value |
|---|---|
| Severity | Low |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. Endpoint moved behind authentication middleware.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. Both operations now use AtomicOperation to batch object update and state change in a single transaction.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 25 April 2026 |
| Affected | from 5.15.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. Session key derivation now incorporates private server-side configuration (database connection parameters) so that attackers cannot reproduce the key from publicly known information alone.
| Field | Value |
|---|---|
| Severity | High |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. URL validation now enforces HTTPS scheme and rejects private/loopback IP ranges and internal hostnames.
| Field | Value |
|---|---|
| Severity | High |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. Cache is now cleared immediately when key state transitions to Revoked, Destroyed, or Compromised.
| Field | Value |
|---|---|
| Severity | High |
| Published | 25 April 2026 |
| Affected | from 5.0.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0. DKE scope now includes EnsureAuth, JWT, TLS, and API token middleware.
| Field | Value |
|---|---|
| Severity | High |
| Published | 25 April 2026 |
| Affected | from 5.17.0 before 5.22.0 |
| Fixed in | 5.22.0 |
| Found by | Cosmian engineering |
| References | #928 |
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.22.0. The fix replaces span.enter() with tracing::Instrument.
| Field | Value |
|---|---|
| Severity | High |
| Published | 21 April 2026 |
| Affected | from 5.17.0 before 5.21.0 |
| Fixed in | 5.21.0 |
| Found by | Cosmian OWASP security audit |
| References | #916 |
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.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 21 April 2026 |
| Affected | from 5.0.0 before 5.22.0 (when OTLP configured with http:// endpoint) |
| Fixed in | 5.22.0 |
| Found by | Cosmian security audit |
| References | #928 |
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.22.0 which rejects http:// OTLP endpoints by default. Use --otlp-allow-insecure / KMS_OTLP_ALLOW_INSECURE=true only for local development.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 14 March 2026 |
| Affected | from 5.0.0 before 5.17.0 |
| Fixed in | 5.17.0 |
| Found by | Cosmian engineering |
| References | #735 |
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.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 14 March 2026 |
| Affected | from 5.0.0 before 5.17.0 |
| Fixed in | 5.17.0 |
| Found by | Cosmian engineering |
| References | #778 |
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.
COSMIAN-2025-003 — glibc CVEs in container base image (CVE-2024-2961, CVE-2024-33600, CVE-2024-33601)
| Field | Value |
|---|---|
| Severity | High |
| Published | 15 February 2026 |
| Affected | from 5.0.0 before 5.16.0 |
| Fixed in | 5.16.0 |
| Found by | SBOM vulnerability scan |
| References | #709 |
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).
| Field | Value |
|---|---|
| Severity | High |
| Published | 22 January 2026 |
| Affected | from 5.0.0 before 5.15.0 |
| Fixed in | 5.15.0 |
| Found by | Cosmian engineering |
| References | #664 |
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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 22 January 2026 |
| Affected | from 5.0.0 before 5.15.0 |
| Fixed in | 5.15.0 |
| Found by | RustSec Advisory Database |
| References | RUSTSEC-2023-0071, #646 |
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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 22 January 2026 |
| Affected | from 5.0.0 before 5.15.0 |
| Fixed in | 5.15.0 |
| Found by | OpenSSL project |
| References | #667 |
Summary: Bundled OpenSSL upgraded to 3.6.2, 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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 15 December 2025 |
| Affected | from 5.0.0 before 5.14.0 |
| Fixed in | 5.14.0 |
| Found by | Cosmian engineering |
| References | #629 |
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.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 7 December 2025 |
| Affected | from 5.0.0 before 5.13.0 |
| Fixed in | 5.13.0 |
| Found by | Cosmian engineering |
| References | #621 |
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.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 19 November 2025 |
| Affected | from 5.0.0 before 5.12.1 |
| Fixed in | 5.12.1 |
| Found by | Cosmian engineering |
| References | #609 |
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.
| Field | Value |
|---|---|
| Severity | Critical |
| Published | 5 September 2025 |
| Affected | from 5.0.0 before 5.8.0 |
| Fixed in | 5.8.0 |
| Found by | Cosmian engineering |
| References | #517 |
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.
| Field | Value |
|---|---|
| Severity | Moderate |
| Published | 5 September 2025 |
| Affected | from 5.0.0 before 5.8.0 |
| Fixed in | 5.8.0 |
| Found by | Cosmian engineering |
| References | #519 |
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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 23 July 2025 |
| Affected | from 5.0.0 before 5.6.2 |
| Fixed in | 5.6.2 |
| Found by | Cosmian engineering |
| References | #489 |
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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 23 May 2025 |
| Affected | from 5.0.0 before 5.1.0 |
| Fixed in | 5.1.0 |
| Found by | Cosmian engineering |
| References | #429 |
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.
| Field | Value |
|---|---|
| Severity | High |
| Published | 23 May 2025 |
| Affected | from 5.0.0 before 5.1.1 |
| Fixed in | 5.1.1 |
| Found by | Cosmian engineering |
| References | #431 |
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.
| ID | Severity | Affected | Fixed in | Title |
|---|---|---|---|---|
| COSMIAN-2026-018 | Moderate | 5.0.0 – 5.22.x | 5.23.0 | Activate uses overly permissive authorization check |
| COSMIAN-2026-017 | Critical | 5.0.0 – 5.22.x | 5.23.0 | ReKey / ReKeyKeyPair authorization bypass |
| COSMIAN-2026-016 | Moderate | 5.0.0 – 5.22.x | 5.23.0 | Attribute-mutation authorization bypass via incorrect op type |
| COSMIAN-2026-015 | High | 5.0.0 – 5.21.x | 5.22.0 | KEK plaintext leak via UsageLimits persist in Decrypt/Sign |
| COSMIAN-2026-014 | Low | 5.0.0 – 5.21.0 | 5.22.0 | Sensitive config values exposed in Debug output |
| COSMIAN-2026-013 | Moderate | 5.0.0 – 5.21.0 | 5.22.0 | Internal error details leaked in HTTP 5xx responses |
| COSMIAN-2026-012 | Low | 5.0.0 – 5.21.0 | 5.22.0 | /server-info endpoint accessible without authentication |
| COSMIAN-2026-011 | Moderate | 5.0.0 – 5.21.0 | 5.22.0 | Non-atomic state transitions enable TOCTOU races |
| COSMIAN-2026-010 | Moderate | 5.15.0 – 5.21.0 | 5.22.0 | Predictable default session cookie salt |
| COSMIAN-2026-009 | High | 5.0.0 – 5.21.0 | 5.22.0 | Google CSE rewrap SSRF via original_kacls_url |
| COSMIAN-2026-008 | High | 5.0.0 – 5.21.0 | 5.22.0 | Unwrap cache not invalidated on key revocation/destruction |
| COSMIAN-2026-007 | High | 5.0.0 – 5.21.0 | 5.22.0 | MS DKE scope missing authentication middleware |
| COSMIAN-2026-006 | High | 5.17.0 – 5.21.0 | 5.22.0 | Server crash via tracing span misuse |
| COSMIAN-2026-005 | High | 5.17.0 – 5.20.1 | 5.21.0 | JWT race condition / algorithm confusion |
| COSMIAN-2026-004 | Critical | 5.0.0+ (with HTTP OTLP) | 5.22.0 | Plaintext OTLP export leaks encryption query metadata |
| COSMIAN-2026-003 | Critical | 5.0.0 – 5.16.2 | 5.17.0 | Import replace_existing ownership bypass |
| COSMIAN-2026-002 | Critical | 5.0.0 – 5.16.2 | 5.17.0 | SipHash key hardcoded to zero |
| COSMIAN-2025-012 | High | 5.0.0 – 5.14.1 | 5.15.0 | Session cookie key randomly regenerated on restart |
| COSMIAN-2025-011 | High | 5.0.0 – 5.14.1 | 5.15.0 | RUSTSEC-2023-0071: RSA Marvin Attack timing side-channel |
| COSMIAN-2025-010 | High | 5.0.0 – 5.13.0 | 5.14.0 | JWT token not forwarded to downstream services |
| COSMIAN-2025-009 | Critical | 5.0.0 – 5.12.0 | 5.13.0 | HSM unwrap bypasses KMS permission checks |
| COSMIAN-2025-008 | Critical | 5.0.0 – 5.7.0 | 5.8.0 | Google CSE privilegedunwrap unrestricted access |
| COSMIAN-2025-007 | High | 5.0.0 – 5.6.1 | 5.6.2 | OIDC silently falls back to no-auth on TLS failure |
| COSMIAN-2025-006 | High | 5.0.0 – 5.0.0 | 5.1.0 | Missing PKCE in OAuth2 authentication flow |
| COSMIAN-2025-005 | High | 5.0.0 – 5.1.0 | 5.1.1 | JWT config loop — only first OIDC provider checked |
| COSMIAN-2025-004 | High | 5.0.0 – 5.14.1 | 5.15.0 | OpenSSL 3.x CVEs (upgrade to 3.6.2) |
| COSMIAN-2025-003 | High | 5.0.0 – 5.15.0 | 5.16.0 | glibc CVEs in container base image |
| COSMIAN-2025-002 | Moderate | 5.0.0 – 5.12.0 | 5.12.1 | Negative X.509 certificate serial numbers |
| COSMIAN-2025-001 | Moderate | 5.0.0 – 5.7.0 | 5.8.0 | CSE migration key pair race condition |
When using Cosmian KMS, we recommend:
- Keep Updated: Always use the latest supported version
- Secure Configuration: Follow the security configuration guidelines in our documentation
- Network Security: Deploy KMS behind appropriate network security controls
- Access Control: Implement proper authentication and authorization mechanisms
- Monitoring: Enable logging and monitoring for security events
- 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.2, 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 tech@cosmian.com.
For immediate security issues, please use the private reporting methods described above.