https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:47:30 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-09332 bdu:2026-09332 https://cve.radiocsirt.org/vuln/bdu:2026-09332 https://cve.radiocsirt.org/vuln/brew-krane-cve-2026-45363 <p><strong>Affected:</strong> Homebrew: krane</p> <p>`JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;)` accepts an attacker-forged token. `OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload)` returns a valid digest under an empty key, and no `raise InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.</p> <p>``` JWT.decode(token, &#34;&#34;, true, algorithm: &#39;HS256&#39;) -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#34;&#34;, signing_input) == signature ```</p> <p>The same path is reached when a keyfinder block or key_finder: argument returns &#34;&#34;, nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to &#34;&#34; (signing_key ||= &#39;&#39;) before signing.</p> <p>``` JWT.decode(token, nil, true, algorithms: [&#39;HS256&#39;]) { |_h| &#34;&#34; } -&gt; find_key returns &#34;&#34; # &#34;&#34; &amp;&amp; !Array(&#34;&#34;).empty? == true -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; verifies ``` Common application patterns that produce the unsafe value: `redis.get(&#34;kid:#{kid}&#34;).to_s`, ORM string columns with `default: &#39;&#39;`, `ENV[&#39;SECRET&#39;] || &#39;&#39;, Hash.new(&#39;&#39;)` lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.</p> <p>The existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.</p> <p>Affects HS256/HS384/H…</p> <p><strong>Affected:</strong> Homebrew: krane</p> <p>`JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;)` accepts an attacker-forged token. `OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload)` returns a valid digest under an empty key, and no `raise InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.</p> <p>``` JWT.decode(token, &#34;&#34;, true, algorithm: &#39;HS256&#39;) -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#34;&#34;, signing_input) == signature ```</p> <p>The same path is reached when a keyfinder block or key_finder: argument returns &#34;&#34;, nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to &#34;&#34; (signing_key ||= &#39;&#39;) before signing.</p> <p>``` JWT.decode(token, nil, true, algorithms: [&#39;HS256&#39;]) { |_h| &#34;&#34; } -&gt; find_key returns &#34;&#34; # &#34;&#34; &amp;&amp; !Array(&#34;&#34;).empty? == true -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; verifies ``` Common application patterns that produce the unsafe value: `redis.get(&#34;kid:#{kid}&#34;).to_s`, ORM string columns with `default: &#39;&#39;`, `ENV[&#39;SECRET&#39;] || &#39;&#39;, Hash.new(&#39;&#39;)` lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.</p> <p>The existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.</p> <p>Affects HS256/HS384/H…</p> https://cve.radiocsirt.org/vuln/brew-krane-cve-2026-45363 https://cve.radiocsirt.org/vuln/euvd-2026-372633 EUVD-2026-372633 https://cve.radiocsirt.org/vuln/euvd-2026-372633 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45363 <p>ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;) accepts an attacker-forged token because OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.</p> <p>ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;) accepts an attacker-forged token because OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45363 https://cve.radiocsirt.org/vuln/ghsa-c32j-vqhx-rx3x <p><strong>Affected:</strong> RubyGems: jwt</p> <p>`JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;)` accepts an attacker-forged token. `OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload)` returns a valid digest under an empty key, and no `raise InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.</p> <p>``` JWT.decode(token, &#34;&#34;, true, algorithm: &#39;HS256&#39;) -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#34;&#34;, signing_input) == signature ```</p> <p>The same path is reached when a keyfinder block or key_finder: argument returns &#34;&#34;, nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to &#34;&#34; (signing_key ||= &#39;&#39;) before signing.</p> <p>``` JWT.decode(token, nil, true, algorithms: [&#39;HS256&#39;]) { |_h| &#34;&#34; } -&gt; find_key returns &#34;&#34; # &#34;&#34; &amp;&amp; !Array(&#34;&#34;).empty? == true -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; verifies ``` Common application patterns that produce the unsafe value: `redis.get(&#34;kid:#{kid}&#34;).to_s`, ORM string columns with `default: &#39;&#39;`, `ENV[&#39;SECRET&#39;] || &#39;&#39;, Hash.new(&#39;&#39;)` lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.</p> <p>The existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.</p> <p>Affects HS256/HS384/H…</p> <p><strong>Affected:</strong> RubyGems: jwt</p> <p>`JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;)` accepts an attacker-forged token. `OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload)` returns a valid digest under an empty key, and no `raise InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.</p> <p>``` JWT.decode(token, &#34;&#34;, true, algorithm: &#39;HS256&#39;) -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#34;&#34;, signing_input) == signature ```</p> <p>The same path is reached when a keyfinder block or key_finder: argument returns &#34;&#34;, nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to &#34;&#34; (signing_key ||= &#39;&#39;) before signing.</p> <p>``` JWT.decode(token, nil, true, algorithms: [&#39;HS256&#39;]) { |_h| &#34;&#34; } -&gt; find_key returns &#34;&#34; # &#34;&#34; &amp;&amp; !Array(&#34;&#34;).empty? == true -&gt; JWA::Hmac.verify(verification_key: &#34;&#34;, ...) -&gt; verifies ``` Common application patterns that produce the unsafe value: `redis.get(&#34;kid:#{kid}&#34;).to_s`, ORM string columns with `default: &#39;&#39;`, `ENV[&#39;SECRET&#39;] || &#39;&#39;, Hash.new(&#39;&#39;)` lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.</p> <p>The existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.</p> <p>Affects HS256/HS384/H…</p> https://cve.radiocsirt.org/vuln/ghsa-c32j-vqhx-rx3x https://cve.radiocsirt.org/vuln/rhsa-2026:63327 <p>jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() ruby-jwt: ruby-jwt: Authentication bypass due to empty key in HMAC verification jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via incomplete fix in async JSON parser aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses</p> <p>jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() ruby-jwt: ruby-jwt: Authentication bypass due to empty key in HMAC verification jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via incomplete fix in async JSON parser aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses</p> https://cve.radiocsirt.org/vuln/rhsa-2026:63327 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45363 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-jwt, Ubuntu:18.04:LTS: ruby-jwt, Ubuntu:20.04:LTS: ruby-jwt, Ubuntu:22.04:LTS: ruby-jwt, Ubuntu:24.04:LTS: ruby-jwt, Ubuntu:26.04:LTS: ruby-jwt</p> <p>ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;) accepts an attacker-forged token because OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-jwt, Ubuntu:18.04:LTS: ruby-jwt, Ubuntu:20.04:LTS: ruby-jwt, Ubuntu:22.04:LTS: ruby-jwt, Ubuntu:24.04:LTS: ruby-jwt, Ubuntu:26.04:LTS: ruby-jwt</p> <p>ruby-jwt is a Ruby implementation of the RFC 7519 OAuth JSON Web Token standard. Prior to 2.10.3 and 3.2.0, JWT.decode(token, &#39;&#39;, true, algorithm: &#39;HS256&#39;) accepts an attacker-forged token because OpenSSL::HMAC.digest(&#39;SHA256&#39;, &#39;&#39;, payload) returns a valid digest under an empty key and no empty-key precondition exists in the HMAC algorithm. The same path is reached when a keyfinder block or key_finder: argument returns an empty string, nil, or an array containing nil for an unknown key, affecting HS256, HS384, and HS512 verification through JWT.decode and JWT::EncodedToken#verify_signature!. This issue is fixed in versions 2.10.3 and 3.2.0.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45363