https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 29 Oct 2026 20:11:56 +0000 https://db.gcve.eu/vuln/ghsa-gg6h-894w-4m9c <p><strong>Affected:</strong> npm: re2js</p> <p>### Summary</p> <p>Using the opt-in `LOOKBEHINDS` flag together with any repeated-matching API (`matcher().find()` in a loop, `matchAll()`, `split()`, `matcher().replaceAll()`) causes quadratic-time (Θ(n²)) matching, contradicting the library&#39;s own &#34;linear time matching&#34; guarantee. A single call with a 16,000-character input takes **36.7–38.7 seconds of CPU**.</p> <p>### Description</p> <p>#### Root cause</p> <p>In `build/index.cjs`, `Machine.match`:</p> <p>```js let currentPos = this.prog.numLb &gt; 0 ? 0 : pos; // ~line 1907 ... if (this.ncap === 0 &amp;&amp; this.matched) break; // ~line 1953 ```</p> <p>Any pattern containing a lookbehind sets `prog.numLb &gt; 0`, which forces the scan to **always restart at offset 0**, regardless of the requested start position — the lookbehind automaton is re-seeded and the whole input is re-walked on every single `find()` call. The early-exit optimization that would otherwise stop at the first match only fires when `ncap === 0`, but every `Matcher`-based API (`find`/`matchAll`/`split`/`replaceAll`) always requests `ncap = 2` (one capture group slot) **even for a captureless lookbehind pattern** — so the early exit never triggers through those APIs, and the scan continues to the end of the input on every find.</p> <p>A find-loop over *k* matches in an *n*-character string therefore costs *k* × Θ(*n*); for dense matches *k* ∝ *n*, giving **Θ(n²)** total.</p> <p>#### Isolating control</p> <p>Identical find-loop, identical input sizes, same 2-character literal pattern *shape* — but **without** the…</p> <p><strong>Affected:</strong> npm: re2js</p> <p>### Summary</p> <p>Using the opt-in `LOOKBEHINDS` flag together with any repeated-matching API (`matcher().find()` in a loop, `matchAll()`, `split()`, `matcher().replaceAll()`) causes quadratic-time (Θ(n²)) matching, contradicting the library&#39;s own &#34;linear time matching&#34; guarantee. A single call with a 16,000-character input takes **36.7–38.7 seconds of CPU**.</p> <p>### Description</p> <p>#### Root cause</p> <p>In `build/index.cjs`, `Machine.match`:</p> <p>```js let currentPos = this.prog.numLb &gt; 0 ? 0 : pos; // ~line 1907 ... if (this.ncap === 0 &amp;&amp; this.matched) break; // ~line 1953 ```</p> <p>Any pattern containing a lookbehind sets `prog.numLb &gt; 0`, which forces the scan to **always restart at offset 0**, regardless of the requested start position — the lookbehind automaton is re-seeded and the whole input is re-walked on every single `find()` call. The early-exit optimization that would otherwise stop at the first match only fires when `ncap === 0`, but every `Matcher`-based API (`find`/`matchAll`/`split`/`replaceAll`) always requests `ncap = 2` (one capture group slot) **even for a captureless lookbehind pattern** — so the early exit never triggers through those APIs, and the scan continues to the end of the input on every find.</p> <p>A find-loop over *k* matches in an *n*-character string therefore costs *k* × Θ(*n*); for dense matches *k* ∝ *n*, giving **Θ(n²)** total.</p> <p>#### Isolating control</p> <p>Identical find-loop, identical input sizes, same 2-character literal pattern *shape* — but **without** the…</p> https://db.gcve.eu/vuln/ghsa-gg6h-894w-4m9c