<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 07 Oct 2026 13:09:40 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-317333</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-317333</link>
      <description>EUVD-2026-317333</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-317333</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45091</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45091</link>
      <description>&lt;p&gt;sealed-env is a cross-stack, zero-trust secret management library for Node.js and Java/Spring Boot. In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator&amp;#39;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. This vulnerability is fixed in 0.1.0-alpha.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;sealed-env is a cross-stack, zero-trust secret management library for Node.js and Java/Spring Boot. In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator&amp;#39;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. This vulnerability is fixed in 0.1.0-alpha.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45091</guid>
    </item>
    <item>
      <title>GHSA-x3r2-fj3r-g5mv — sealed-env: TOTP secret embedded in unseal token payload (enterprise mode)</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-x3r2-fj3r-g5mv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: sealed-env, Maven: io.github.davidalmeidac:sealed-env-core&lt;/p&gt;
&lt;p&gt;In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Patched in 0.1.0-alpha.4 by replacing the embedded secret with a salt-bound HMAC derivative (`enterprise_epoch = HMAC(totpSecret, salt || &amp;#34;epoch-v1&amp;#34;)`). The TOTP secret never leaves the operator&amp;#39;s machine in the new design. The wire format change is incompatible — files sealed by affected versions must be re-sealed and the TOTP secret rotated. Full migration playbook in CHANGELOG.md.&lt;/p&gt;
&lt;p&gt;Reported by an external reviewer who decoded the payload of a real minted token and confirmed bit-for-bit equality with the operator&amp;#39;s .env.local TOTP secret.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: sealed-env, Maven: io.github.davidalmeidac:sealed-env-core&lt;/p&gt;
&lt;p&gt;In sealed-env enterprise mode, versions 0.1.0-alpha.1 through 0.1.0-alpha.3 embedded the operator&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Patched in 0.1.0-alpha.4 by replacing the embedded secret with a salt-bound HMAC derivative (`enterprise_epoch = HMAC(totpSecret, salt || &amp;#34;epoch-v1&amp;#34;)`). The TOTP secret never leaves the operator&amp;#39;s machine in the new design. The wire format change is incompatible — files sealed by affected versions must be re-sealed and the TOTP secret rotated. Full migration playbook in CHANGELOG.md.&lt;/p&gt;
&lt;p&gt;Reported by an external reviewer who decoded the payload of a real minted token and confirmed bit-for-bit equality with the operator&amp;#39;s .env.local TOTP secret.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-x3r2-fj3r-g5mv</guid>
    </item>
  </channel>
</rss>
