Skip to content

← Public intelligence

Maven package

io.github.davidalmeidac:sealed-env-core

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Critical, CVSS 9.1MavenAmendedPublished

    sealed-env: TOTP secret embedded in unseal token payload (enterprise mode)

    CVE-2026-45091 · GHSA-x3r2-fj3r-g5mv

    Affected
    • Maven io.github.davidalmeidac:sealed-env-core < 0.1.0-alpha.4
    Fixed in
    0.1.0-alpha.4· Vendor fix available
    Issue
    In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator's literal TOTP secret in the JWS payload of every minted unseal token. JWS payload is base64-encoded JSON, NOT encrypted. Any party who could observe a minted token (CI build logs, container env dumps, kubectl describe pod, Sentry/Rollbar stack traces, log aggregators) could decode the payload and extract the TOTP secret in plaintext. An attacker with (a) the master key (e.g. from a separate compromise such as a leaked CI secret) and (b) any single leaked unseal token can use the extracted TOTP secret to mint new valid unseal tokens for any future deploy indefinitely, breaking the second-factor property the library claimed. Patched in 0.1.0-alpha.4 by replacing the embedded secret with a salt-bound HMAC derivative (enterpriseepoch = HMAC(totpSecret, salt || "epoch-v1")). The TOTP secret never leaves the operator's machine in the new design. The wire format change is incompatible — files…

    Recommended action: Upgrade to 0.1.0-alpha.4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →