https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 23:41:45 +0000 https://cve.radiocsirt.org/vuln/cleanstart-2026-be61221 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opensearch-dashboards-fips</p> <p>Multiple security vulnerabilities affect the opensearch-dashboards-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opensearch-dashboards-fips</p> <p>Multiple security vulnerabilities affect the opensearch-dashboards-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-be61221 https://cve.radiocsirt.org/vuln/euvd-2026-329300 EUVD-2026-329300 https://cve.radiocsirt.org/vuln/euvd-2026-329300 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44459 <p>Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18.</p> <p>Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-44459 https://cve.radiocsirt.org/vuln/ghsa-hm8q-7f3q-5f36 <p><strong>Affected:</strong> npm: hono</p> <p>### Summary</p> <p>Improper validation of the JWT NumericDate claims `exp`, `nbf`, and `iat` in `hono/utils/jwt` allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches `verify()` — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control.</p> <p>### Details</p> <p>The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected:</p> <p>- A falsy numeric value short-circuited the presence check. - A non-finite numeric value compared as never-after-now and never-expired. - A non-numeric type produced NaN comparisons that evaluated false.</p> <p>This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value.</p> <p>### Impact</p> <p>An actor able to issue tokens accepted by the application may craft tokens whose `exp`, `nbf`, or `iat` claims silently bypass time-based enforcement. This may lead to:</p> <p>- Tokens treated as never expiring even with `exp` configured on the verifier. - Tokens with a future `nbf` accepted as currently valid. - Tokens with a future `iat` accepted as legitimately issued.</p> <p>Deployments using a well-formed token issuer and protecting the signing key are not affected.</p> <p><strong>Affected:</strong> npm: hono</p> <p>### Summary</p> <p>Improper validation of the JWT NumericDate claims `exp`, `nbf`, and `iat` in `hono/utils/jwt` allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches `verify()` — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control.</p> <p>### Details</p> <p>The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected:</p> <p>- A falsy numeric value short-circuited the presence check. - A non-finite numeric value compared as never-after-now and never-expired. - A non-numeric type produced NaN comparisons that evaluated false.</p> <p>This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value.</p> <p>### Impact</p> <p>An actor able to issue tokens accepted by the application may craft tokens whose `exp`, `nbf`, or `iat` claims silently bypass time-based enforcement. This may lead to:</p> <p>- Tokens treated as never expiring even with `exp` configured on the verifier. - Tokens with a future `nbf` accepted as currently valid. - Tokens with a future `iat` accepted as legitimately issued.</p> <p>Deployments using a well-formed token issuer and protecting the signing key are not affected.</p> https://cve.radiocsirt.org/vuln/ghsa-hm8q-7f3q-5f36