<?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>Mon, 12 Oct 2026 08:27:04 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-256733</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-256733</link>
      <description>EUVD-2026-256733</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-256733</guid>
    </item>
    <item>
      <title>fkie_cve-2025-62610</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-62610</link>
      <description>&lt;p&gt;Hono is a Web application framework that provides support for any JavaScript runtime. In versions from 1.1.0 to before 4.10.2, Hono’s JWT Auth Middleware does not provide a built-in aud (Audience) verification option, which can cause confused-deputy / token-mix-up issues: an API may accept a valid token that was issued for a different audience (e.g., another service) when multiple services share the same issuer/keys. This can lead to unintended cross-service access. Hono’s docs list verification options for iss/nbf/iat/exp only, with no aud support; RFC 7519 requires that when an aud claim is present, tokens MUST be rejected unless the processing party identifies itself in that claim. This issue has been patched in version 4.10.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Hono is a Web application framework that provides support for any JavaScript runtime. In versions from 1.1.0 to before 4.10.2, Hono’s JWT Auth Middleware does not provide a built-in aud (Audience) verification option, which can cause confused-deputy / token-mix-up issues: an API may accept a valid token that was issued for a different audience (e.g., another service) when multiple services share the same issuer/keys. This can lead to unintended cross-service access. Hono’s docs list verification options for iss/nbf/iat/exp only, with no aud support; RFC 7519 requires that when an aud claim is present, tokens MUST be rejected unless the processing party identifies itself in that claim. This issue has been patched in version 4.10.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-62610</guid>
    </item>
    <item>
      <title>GHSA-m732-5p4w-x69g — Hono Improper Authorization vulnerability</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-m732-5p4w-x69g</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: hono&lt;/p&gt;
&lt;p&gt;### Improper Authorization in Hono (JWT Audience Validation)&lt;/p&gt;
&lt;p&gt;Hono’s JWT authentication middleware did not validate the `aud` (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up).&lt;/p&gt;
&lt;p&gt;The issue is addressed by adding a new `verification.aud` configuration option to allow RFC 7519–compliant audience validation. This change is classified as a **security hardening improvement**, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification.&lt;/p&gt;
&lt;p&gt;### Recommended secure configuration&lt;/p&gt;
&lt;p&gt;You can enable RFC 7519–compliant audience validation using the new `verification.aud` option:&lt;/p&gt;
&lt;p&gt;```ts
import { Hono } from &amp;#39;hono&amp;#39;
import { jwt } from &amp;#39;hono/jwt&amp;#39;&lt;/p&gt;
&lt;p&gt;const app = new Hono()&lt;/p&gt;
&lt;p&gt;app.use(
  &amp;#39;/api/*&amp;#39;,
  jwt({
    secret: &amp;#39;my-secret&amp;#39;,
    verification: {
      // Require this API to only accept tokens with aud = &amp;#39;service-a&amp;#39;
      aud: &amp;#39;service-a&amp;#39;,
    },
  })
)
```&lt;/p&gt;
&lt;p&gt;Below is the original description by the reporter. For security reasons, it does not include PoC reproduction steps, as the vulnerability can be clearly understood from the technical description.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## The original description by the reporter&lt;/p&gt;
&lt;p&gt;### Summary
Hono’s **JWT Auth Middleware does not provide a built-in `aud` (Audience) verification option**, which can cause **confused-deputy / token-mix-up** issues: an API ma…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: hono&lt;/p&gt;
&lt;p&gt;### Improper Authorization in Hono (JWT Audience Validation)&lt;/p&gt;
&lt;p&gt;Hono’s JWT authentication middleware did not validate the `aud` (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up).&lt;/p&gt;
&lt;p&gt;The issue is addressed by adding a new `verification.aud` configuration option to allow RFC 7519–compliant audience validation. This change is classified as a **security hardening improvement**, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification.&lt;/p&gt;
&lt;p&gt;### Recommended secure configuration&lt;/p&gt;
&lt;p&gt;You can enable RFC 7519–compliant audience validation using the new `verification.aud` option:&lt;/p&gt;
&lt;p&gt;```ts
import { Hono } from &amp;#39;hono&amp;#39;
import { jwt } from &amp;#39;hono/jwt&amp;#39;&lt;/p&gt;
&lt;p&gt;const app = new Hono()&lt;/p&gt;
&lt;p&gt;app.use(
  &amp;#39;/api/*&amp;#39;,
  jwt({
    secret: &amp;#39;my-secret&amp;#39;,
    verification: {
      // Require this API to only accept tokens with aud = &amp;#39;service-a&amp;#39;
      aud: &amp;#39;service-a&amp;#39;,
    },
  })
)
```&lt;/p&gt;
&lt;p&gt;Below is the original description by the reporter. For security reasons, it does not include PoC reproduction steps, as the vulnerability can be clearly understood from the technical description.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## The original description by the reporter&lt;/p&gt;
&lt;p&gt;### Summary
Hono’s **JWT Auth Middleware does not provide a built-in `aud` (Audience) verification option**, which can cause **confused-deputy / token-mix-up** issues: an API ma…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-m732-5p4w-x69g</guid>
    </item>
  </channel>
</rss>
