<?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://vulnerability.circl.lu</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, 05 Oct 2026 16:30:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-69207 — Hono: ReDoS in CORS middleware via Access-Control-Request-Headers</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-69207</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; honojs hono&lt;/p&gt;
&lt;p&gt;Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.34, the built-in CORS middleware, hono/cors, is vulnerable to a regular expression denial of service (ReDoS). During a preflight OPTIONS request, the middleware parses the attacker-controlled Access-Control-Request-Headers header using a whitespace-tolerant regular expression whose backtracking makes its running time quadratic in the input length. Because the header value is bounded only by the deployment&amp;#39;s maximum HTTP header size, a single preflight carrying a long run of whitespace can consume seconds of CPU and block request processing. On runtimes that share one execution thread across requests, this stalls concurrent requests as well, and repeated requests can render the service unresponsive. This affects the default configuration, since the vulnerable path is reached whenever cors() is used with an unset or empty allowHeaders. Applications that set a non-empty allowHeaders are not affected. This issue is fixed in version 4.12.34.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; honojs hono&lt;/p&gt;
&lt;p&gt;Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.34, the built-in CORS middleware, hono/cors, is vulnerable to a regular expression denial of service (ReDoS). During a preflight OPTIONS request, the middleware parses the attacker-controlled Access-Control-Request-Headers header using a whitespace-tolerant regular expression whose backtracking makes its running time quadratic in the input length. Because the header value is bounded only by the deployment&amp;#39;s maximum HTTP header size, a single preflight carrying a long run of whitespace can consume seconds of CPU and block request processing. On runtimes that share one execution thread across requests, this stalls concurrent requests as well, and repeated requests can render the service unresponsive. This affects the default configuration, since the vulnerable path is reached whenever cors() is used with an unset or empty allowHeaders. Applications that set a non-empty allowHeaders are not affected. This issue is fixed in version 4.12.34.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-69207</guid>
    </item>
    <item>
      <title>GHSA-5p4m-2wfm-xmqj — JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-5p4m-2wfm-xmqj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: js-yaml&lt;/p&gt;
&lt;p&gt;# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear
scan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution
**O(n²)** in the number of entries. A modestly sized YAML document therefore
consumes disproportionate CPU inside `yaml.load()`, giving a denial of service
against any consumer that parses untrusted YAML.&lt;/p&gt;
&lt;p&gt;`!!omap` is registered in the **default schema**
(`lib/schema/default.js` → `require(&amp;#39;../type/omap&amp;#39;)`), so a plain
`yaml.load(untrustedInput)` with no options is affected — no custom schema or
non-default configuration is required.&lt;/p&gt;
&lt;p&gt;**This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was
fixed in the 5.x line in 5.2.1. That fix was never backported: both currently
maintained legacy lines still carry the original implementation.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;| Line | Latest tested | Status |
|---|---|---|
| 3.x | **3.15.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` |
| 4.x | **4.3.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` |
| 5.x | 5.2.2 | **Not affected** — fixed in 5.2.1 (uses a `Set`) |&lt;/p&gt;
&lt;p&gt;Both figures are the newest release of each line at the time of writing, so
this is not a &amp;#34;you are on an old version&amp;#34; issue.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`lib/type/omap.js` (js-yaml 4.3.0):&lt;/p&gt;
&lt;p&gt;```js
if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)
else return false
```&lt;/p&gt;
&lt;p&gt;`obj…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: js-yaml&lt;/p&gt;
&lt;p&gt;# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear
scan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution
**O(n²)** in the number of entries. A modestly sized YAML document therefore
consumes disproportionate CPU inside `yaml.load()`, giving a denial of service
against any consumer that parses untrusted YAML.&lt;/p&gt;
&lt;p&gt;`!!omap` is registered in the **default schema**
(`lib/schema/default.js` → `require(&amp;#39;../type/omap&amp;#39;)`), so a plain
`yaml.load(untrustedInput)` with no options is affected — no custom schema or
non-default configuration is required.&lt;/p&gt;
&lt;p&gt;**This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was
fixed in the 5.x line in 5.2.1. That fix was never backported: both currently
maintained legacy lines still carry the original implementation.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;| Line | Latest tested | Status |
|---|---|---|
| 3.x | **3.15.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` |
| 4.x | **4.3.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` |
| 5.x | 5.2.2 | **Not affected** — fixed in 5.2.1 (uses a `Set`) |&lt;/p&gt;
&lt;p&gt;Both figures are the newest release of each line at the time of writing, so
this is not a &amp;#34;you are on an old version&amp;#34; issue.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`lib/type/omap.js` (js-yaml 4.3.0):&lt;/p&gt;
&lt;p&gt;```js
if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)
else return false
```&lt;/p&gt;
&lt;p&gt;`obj…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-5p4m-2wfm-xmqj</guid>
    </item>
  </channel>
</rss>
