Common Weakness Enumeration

CWE-436

Allowed-with-Review

Interpretation Conflict

Abstraction: Class · Status: Incomplete

Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.

199 vulnerabilities reference this CWE, most recent first.

GHSA-GCR4-WCQH-3624

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

Go before 1.12.11 and 1.3.x before 1.13.2 can panic upon an attempt to process network traffic containing an invalid DSA public key. There are several attack scenarios, such as traffic from a client to a server that verifies client certificates.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-17596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-24T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Go before 1.12.11 and 1.3.x before 1.13.2 can panic upon an attempt to process network traffic containing an invalid DSA public key. There are several attack scenarios, such as traffic from a client to a server that verifies client certificates.",
  "id": "GHSA-gcr4-wcqh-3624",
  "modified": "2022-05-24T16:59:54Z",
  "published": "2022-05-24T16:59:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17596"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/go/issues/34960"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0101"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0329"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/d/msg/golang-announce/lVEm7llp0w0/VbafyRkgCgAJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5VS3HPSE25ZSGS4RSOTADC67YNOHIGVV"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WVOWGM7IQGRO7DS2MCUMYZRQ4TYOZNAS"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20191122-0005"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisories/10134-security-advisory-46"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4551"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00043.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00044.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GM3X-23WP-HC2C

Vulnerability from github – Published: 2025-12-08 16:42 – Updated: 2025-12-17 00:44
VLAI
Summary
Path Normalization Bypass in Traefik Router + Middleware Rules
Details

Impact

There is a potential vulnerability in Traefik managing the requests using a PathPrefix, Path or PathRegex matcher.

When Traefik is configured to route the requests to a backend using a matcher based on the path; if the request path contains an encoded restricted character from the following set ('/', '\', 'Null', ';', '?', '#'), it’s possible to target a backend, exposed using another router, by-passing the middlewares chain.

Example

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: my-service
spec:
  routes:
    - match: PathPrefix(‘/admin/’)
      kind: Rule
      services:
        - name: service-a
          port: 8080
      middlewares:
        - name: my-security-middleware
    - match: PathPrefix(‘/’)
      kind: Rule
      services:
        - name: service-a
          port: 8080

In such a case, the request http://mydomain.example.com/admin%2F will reach the backend service-a without operating the middleware my-security-middleware and passing the security put in place for the /admin/ path.

Patches

  • https://github.com/traefik/traefik/releases/tag/v2.11.32
  • https://github.com/traefik/traefik/releases/tag/v3.6.4

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description### Summary A vulnerability exists in Traefik’s path matching logic that allows attackers to bypass access-control middleware (e.g., blocking rules) by using URL-encoded paths. I found this vulnerability while playing PwnSec CTF 2025 with my team @0xL4ugh ### Details Traefik evaluates router rules before decoding or normalizing the request path, but forwards the request after decoding to the backend service. As a result, routes meant to block access to sensitive endpoints (such as internal, beta, or admin endpoints) can be trivially bypassed. ### PoC Traefik configuration used in this issue : ```[http.routers.flask-router-report-deny] entryPoints = ["web"] rule = "PathPrefix(`/report_note`)" priority = 10 middlewares = ["block-access"] service = "flask-service" [http.middlewares.block-access.replacePathRegex] regex = ".*" replacement = "/blocked"
The intention is to block all access to /report_note.

However, the following request bypasses the block:
POST /%2freport_note HTTP/1.1 Host: localhost:62814 ``` ### Impact Access Control Bypass: Any endpoint intended to be blocked (e.g., admin/debug/beta APIs) can be accessed by URL-encoding slashes or other characters. This could lead to: - Unauthorized access to restricted endpoints - Execution of protected internal functionality - Potential privilege escalation - Bypass of security policies enforced via Traefik routing rules
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-08T16:42:30Z",
    "nvd_published_at": "2025-12-09T01:16:55Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nThere is a potential vulnerability in Traefik managing the requests using a `PathPrefix`, `Path` or `PathRegex` matcher.\n\nWhen Traefik is configured to route the requests to a backend using a matcher based on the path; if the request path contains an encoded restricted character from the following set **(\u0027/\u0027, \u0027\\\u0027, \u0027Null\u0027, \u0027;\u0027, \u0027?\u0027, \u0027#\u0027)**, it\u2019s possible to target a backend, exposed using another router, by-passing the middlewares chain.\n\n## Example\n\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: IngressRoute\nmetadata:\n  name: my-service\nspec:\n  routes:\n    - match: PathPrefix(\u2018/admin/\u2019)\n      kind: Rule\n      services:\n        - name: service-a\n          port: 8080\n      middlewares:\n        - name: my-security-middleware\n    - match: PathPrefix(\u2018/\u2019)\n      kind: Rule\n      services:\n        - name: service-a\n          port: 8080\n```\n\nIn such a case, the request `http://mydomain.example.com/admin%2F` will reach the backend `service-a` without operating the middleware `my-security-middleware` and passing the security put in place for the `/admin/` path.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.32\n- https://github.com/traefik/traefik/releases/tag/v3.6.4\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e### Summary\nA vulnerability exists in Traefik\u2019s path matching logic that allows attackers to bypass access-control middleware (e.g., blocking rules) by using URL-encoded paths. I found this vulnerability while playing PwnSec CTF 2025 with my team @0xL4ugh\n\n### Details\nTraefik evaluates router rules before decoding or normalizing the request path, but forwards the request after decoding to the backend service. As a result, routes meant to block access to sensitive endpoints (such as internal, beta, or admin endpoints) can be trivially bypassed.\n\n### PoC\nTraefik configuration used in this issue :\n```[http.routers.flask-router-report-deny]\n  entryPoints = [\"web\"]\n  rule = \"PathPrefix(`/report_note`)\"\n  priority = 10\n  middlewares = [\"block-access\"]\n  service = \"flask-service\"\n\n[http.middlewares.block-access.replacePathRegex]\n  regex = \".*\"\n  replacement = \"/blocked\"\n```\nThe intention is to block all access to /report_note.\n\nHowever, the following request bypasses the block:\n```\nPOST /%2freport_note HTTP/1.1\nHost: localhost:62814\n\n\n```\n### Impact\nAccess Control Bypass:\nAny endpoint intended to be blocked (e.g., admin/debug/beta APIs) can be accessed by URL-encoding slashes or other characters.\n\nThis could lead to:\n\n- Unauthorized access to restricted endpoints\n- Execution of protected internal functionality\n- Potential privilege escalation\n- Bypass of security policies enforced via Traefik routing rules\n\u003c/details\u003e",
  "id": "GHSA-gm3x-23wp-hc2c",
  "modified": "2025-12-17T00:44:50Z",
  "published": "2025-12-08T16:42:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-gm3x-23wp-hc2c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66490"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.32"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.4"
    }
  ],
  "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:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Path Normalization Bypass in Traefik Router + Middleware Rules"
}

GHSA-H6Q6-9HQW-RWFV

Vulnerability from github – Published: 2021-03-12 22:39 – Updated: 2023-01-02 21:51
VLAI
Summary
Misinterpretation of malicious XML input
Details

Impact

xmldom versions 0.4.0 and older do not correctly preserve system identifiers, FPIs or namespaces when repeatedly parsing and serializing maliciously crafted documents.

This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Patches

Update to 0.5.0 (once it is released)

Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

References

Similar to this one reported on the Go standard library:

  • https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/

For more information

If you have any questions or comments about this advisory:

  • Open an issue in xmldom/xmldom
  • Email us: send an email to all addresses that are shown by npm owner ls xmldom
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-115",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-12T16:21:24Z",
    "nvd_published_at": "2021-03-12T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nxmldom versions 0.4.0 and older do not correctly preserve [system identifiers](https://www.w3.org/TR/2008/REC-xml-20081126/#d0e4313), [FPIs](https://en.wikipedia.org/wiki/Formal_Public_Identifier) or [namespaces](https://www.w3.org/TR/xml-names11/) when repeatedly parsing and serializing maliciously crafted documents.\n\nThis may lead to unexpected syntactic changes during XML processing in some downstream applications.\n\n### Patches\n\nUpdate to 0.5.0 (once it is released)\n\n### Workarounds\n\nDownstream applications can validate the input and reject the maliciously crafted documents.\n\n### References\n\nSimilar to this one reported on the Go standard library:\n\n- https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [`xmldom/xmldom`](https://github.com/xmldom/xmldom)\n* Email us: send an email to **all** addresses that are shown by `npm owner ls xmldom`",
  "id": "GHSA-h6q6-9hqw-rwfv",
  "modified": "2023-01-02T21:51:19Z",
  "published": "2021-03-12T22:39:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-h6q6-9hqw-rwfv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21366"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/d4201b9dfbf760049f457f9f08a3888d48835135"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xmldom/xmldom"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.5.0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/xmldom"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Misinterpretation of malicious XML input"
}

GHSA-HG56-VQPV-9738

Vulnerability from github – Published: 2024-05-22 18:30 – Updated: 2024-05-22 18:30
VLAI
Details

A vulnerability in the activation of an access control list (ACL) on Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass the protection that is offered by a configured ACL on an affected device. This vulnerability is due to a logic error that occurs when an ACL changes from inactive to active in the running configuration of an affected device. An attacker could exploit this vulnerability by sending traffic through the affected device that should be denied by the configured ACL. The reverse condition is also true—traffic that should be permitted could be denied by the configured ACL. A successful exploit could allow the attacker to bypass configured ACL protections on the affected device, allowing the attacker to access trusted networks that the device might be protecting. Note: This vulnerability applies to both IPv4 and IPv6 traffic as well as dual-stack ACL configurations in which both IPv4 and IPv6 ACLs are configured on an interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20293"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T17:16:13Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the activation of an access control list (ACL) on Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass the protection that is offered by a configured ACL on an affected device. This vulnerability is due to a logic error that occurs when an ACL changes from inactive to active in the running configuration of an affected device. An attacker could exploit this vulnerability by sending traffic through the affected device that should be denied by the configured ACL. The reverse condition is also true\u2014traffic that should be permitted could be denied by the configured ACL. A successful exploit could allow the attacker to bypass configured ACL protections on the affected device, allowing the attacker to access trusted networks that the device might be protecting. Note: This vulnerability applies to both IPv4 and IPv6 traffic as well as dual-stack ACL configurations in which both IPv4 and IPv6 ACLs are configured on an interface.",
  "id": "GHSA-hg56-vqpv-9738",
  "modified": "2024-05-22T18:30:42Z",
  "published": "2024-05-22T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20293"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ogsnsg-aclbyp-3XB8q6jX"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HGV6-X3P4-Q38V

Vulnerability from github – Published: 2023-10-10 18:31 – Updated: 2024-04-04 08:30
VLAI
Details

A interpretation conflict in Fortinet IPS Engine versions 7.321, 7.166 and 6.158 allows attacker to evade IPS features via crafted TCP packets.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-40718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-10T17:15:12Z",
    "severity": "HIGH"
  },
  "details": "A interpretation conflict in Fortinet IPS Engine versions 7.321, 7.166 and 6.158 allows attacker to evade IPS features via crafted TCP packets.",
  "id": "GHSA-hgv6-x3p4-q38v",
  "modified": "2024-04-04T08:30:20Z",
  "published": "2023-10-10T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40718"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-23-090"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HH82-3PMQ-7FRP

Vulnerability from github – Published: 2022-12-12 21:25 – Updated: 2023-01-10 23:07
VLAI
Summary
Netty vulnerable to HTTP Response splitting from assigning header value iterator
Details

Impact

When calling DefaultHttpHeaders.set with an iterator of values (as opposed to a single given value), header value validation was not performed, allowing malicious header values in the iterator to perform HTTP Response Splitting.

Patches

The necessary validation was added in Netty 4.1.86.Final.

Workarounds

Integrators can work around the issue by changing the DefaultHttpHeaders.set(CharSequence, Iterator<?>) call, into a remove() call, and call add() in a loop over the iterator of values.

References

HTTP Response Splitting CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers

For more information

If you have any questions or comments about this advisory: * Open an issue in [example link to repo](https://github.com/netty/netty) * Email us at netty-security@googlegroups.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.83.Final"
            },
            {
              "fixed": "4.1.86.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T21:25:44Z",
    "nvd_published_at": "2022-12-13T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nWhen calling `DefaultHttpHeaders.set` with an _iterator_ of values (as opposed to a single given value), header value validation was not performed, allowing malicious header values in the iterator to perform [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting).\n\n### Patches\nThe necessary validation was added in Netty 4.1.86.Final.\n\n### Workarounds\nIntegrators can work around the issue by changing the `DefaultHttpHeaders.set(CharSequence, Iterator\u003c?\u003e)` call, into a `remove()` call, and call `add()` in a loop over the iterator of values.\n\n### References\n[HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting)\n[CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [[example link to repo](https://github.com/netty/netty)](https://github.com/netty/netty)\n* Email us at [netty-security@googlegroups.com](mailto:netty-security@googlegroups.com)\n",
  "id": "GHSA-hh82-3pmq-7frp",
  "modified": "2023-01-10T23:07:13Z",
  "published": "2022-12-12T21:25:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-hh82-3pmq-7frp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41915"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/issues/13084"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/12760"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/c37c637f096e7be3dffd36edee3455c8e90cb1b0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/fe18adff1c2b333acb135ab779a3b9ba3295a1c4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230113-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5316"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty vulnerable to HTTP Response splitting from assigning header value iterator"
}

GHSA-HRWM-HGMJ-7P9C

Vulnerability from github – Published: 2026-04-16 01:03 – Updated: 2026-04-16 01:03
VLAI
Summary
@fastify/express's middleware path doubling causes authentication bypass in child plugin scopes
Details

Summary

@fastify/express v4.0.4 contains a path handling bug in the onRegister function that causes middleware paths to be doubled when inherited by child plugins. This results in complete bypass of Express middleware security controls for all routes defined within child plugin scopes that share a prefix with parent-scoped middleware. No special configuration is required — this affects the default Fastify configuration.

Details

The vulnerability exists in the onRegister function at index.js lines 92-101. When a child plugin is registered with a prefix, the onRegister hook copies middleware from the parent scope and re-registers it using instance.use(...middleware). However, the middleware paths stored in kMiddlewares are already prefixed from their original registration.

The call flow demonstrates the problem: 1. Parent scope registers middleware: app.use('/admin', authFn)use() calculates path as '' + '/admin' = '/admin' — stores ['/admin', authFn] in kMiddlewares 2. Child plugin registers with { prefix: '/admin' } — triggers onRegister(instance) 3. onRegister copies parent middleware and calls instance.use('/admin', authFn) on child 4. Child's use() function calculates path as '/admin' + '/admin' = '/admin/admin' — registers middleware with doubled path 5. Routes in child scope use the child's Express instance, where middleware is registered under the incorrect path /admin/admin 6. Requests to /admin/secret don't match /admin/admin — middleware is silently skipped

The root cause is in the use() function at lines 25-26, which always prepends this.prefix to string paths, combined with onRegister re-calling use() with already-prefixed paths.

PoC

const fastify = require('fastify');
const http = require('http');

function get(port, url) {
  return new Promise((resolve, reject) => {
    http.get('http://localhost:' + port + url, (res) => {
      let data = '';
      res.on('data', (chunk) => data += chunk);
      res.on('end', () => resolve({ status: res.statusCode, body: data }));
    }).on('error', reject);
  });
}

async function test() {
  const app = fastify({ logger: false });
  await app.register(require('@fastify/express'));

  // Middleware enforcing auth on /admin routes
  app.use('/admin', function(req, res, next) {
    if (!req.headers.authorization) {
      res.statusCode = 403;
      res.setHeader('content-type', 'application/json');
      res.end(JSON.stringify({ error: 'Forbidden' }));
      return;
    }
    next();
  });

  // Root scope route — middleware works correctly
  app.get('/admin/root-data', async () => ({ data: 'root-secret' }));

  // Child scope route — middleware BYPASSED
  await app.register(async function(child) {
    child.get('/secret', async () => ({ data: 'child-secret' }));
  }, { prefix: '/admin' });

  await app.listen({ port: 19876, host: '0.0.0.0' });

  // Root scope: correctly blocked
  let r = await get(19876, '/admin/root-data');
  console.log('/admin/root-data (no auth):', r.status, r.body);
  // Output: 403 {"error":"Forbidden"}

  // Child scope: BYPASSED — secret data returned without auth
  r = await get(19876, '/admin/secret');
  console.log('/admin/secret (no auth):', r.status, r.body);
  // Output: 200 {"data":"child-secret"}

  await app.close();
}
test();

Actual output:

/admin/root-data (no auth): 403 {"error":"Forbidden"}
/admin/secret (no auth): 200 {"data":"child-secret"}

Impact

Complete bypass of Express middleware security controls for all routes defined in child plugin scopes. Authentication, authorization, rate limiting, CSRF protection, audit logging, and any other middleware-based security mechanisms are silently skipped for affected routes.

  • No special request crafting is required — normal requests bypass the middleware
  • It affects the idiomatic Fastify plugin pattern commonly used in production
  • The bypass is silent with no errors or warnings
  • Developers' basic testing of root-scoped routes will pass, masking the vulnerability
  • Any child plugin scope that shares a prefix with middleware is affected

Applications using @fastify/express with path-scoped middleware and child plugins with matching prefixes are vulnerable in default configurations.

Affected Versions

  • @fastify/express v4.0.4 (latest at time of discovery)
  • Fastify 5.x in default configuration
  • No special router options required (ignoreDuplicateSlashes not needed)
  • Affects any child plugin registration where the prefix overlaps with middleware path scoping
  • Does NOT affect middleware registered without path scoping (global middleware)
  • Does NOT affect middleware registered on root path (/) due to special case handling

Variant Testing

Scenario Middleware Path Child Prefix Result
Root route /admin/root-data /admin N/A Middleware runs (403)
Child route /admin/secret /admin /admin BYPASS (200)
Child route /api/data /api /api BYPASS (200)
Nested child /admin/sub/data /admin /admin/sub BYPASS — path becomes /admin/sub/admin
Middleware on / with any child / /api No bypass — path === '/' && prefix.length > 0 special case

Suggested Fix

The onRegister function should store and re-use the original unprefixed middleware paths, or avoid re-calling the use() function entirely. Options include: 1. Store the original path and function separately in kMiddlewares before prefixing 2. Strip the parent prefix before re-registering in child scopes 3. Store already-constructed Express middleware objects rather than re-processing paths

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.0.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/express"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T01:03:25Z",
    "nvd_published_at": "2026-04-15T10:16:48Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\n`@fastify/express` v4.0.4 contains a path handling bug in the `onRegister` function that causes middleware paths to be doubled when inherited by child plugins. This results in complete bypass of Express middleware security controls for all routes defined within child plugin scopes that share a prefix with parent-scoped middleware. No special configuration is required \u2014 this affects the default Fastify configuration.\n\n### Details\n\nThe vulnerability exists in the `onRegister` function at `index.js` lines 92-101. When a child plugin is registered with a prefix, the `onRegister` hook copies middleware from the parent scope and re-registers it using `instance.use(...middleware)`. However, the middleware paths stored in `kMiddlewares` are already prefixed from their original registration.\n\nThe call flow demonstrates the problem:\n1. Parent scope registers middleware: `app.use(\u0027/admin\u0027, authFn)` \u2014 `use()` calculates path as `\u0027\u0027 + \u0027/admin\u0027 = \u0027/admin\u0027` \u2014 stores `[\u0027/admin\u0027, authFn]` in `kMiddlewares`\n2. Child plugin registers with `{ prefix: \u0027/admin\u0027 }` \u2014 triggers `onRegister(instance)`\n3. `onRegister` copies parent middleware and calls `instance.use(\u0027/admin\u0027, authFn)` on child\n4. Child\u0027s `use()` function calculates path as `\u0027/admin\u0027 + \u0027/admin\u0027 = \u0027/admin/admin\u0027` \u2014 registers middleware with doubled path\n5. Routes in child scope use the child\u0027s Express instance, where middleware is registered under the incorrect path `/admin/admin`\n6. Requests to `/admin/secret` don\u0027t match `/admin/admin` \u2014 middleware is silently skipped\n\nThe root cause is in the `use()` function at lines 25-26, which always prepends `this.prefix` to string paths, combined with `onRegister` re-calling `use()` with already-prefixed paths.\n\n### PoC\n\n```javascript\nconst fastify = require(\u0027fastify\u0027);\nconst http = require(\u0027http\u0027);\n\nfunction get(port, url) {\n  return new Promise((resolve, reject) =\u003e {\n    http.get(\u0027http://localhost:\u0027 + port + url, (res) =\u003e {\n      let data = \u0027\u0027;\n      res.on(\u0027data\u0027, (chunk) =\u003e data += chunk);\n      res.on(\u0027end\u0027, () =\u003e resolve({ status: res.statusCode, body: data }));\n    }).on(\u0027error\u0027, reject);\n  });\n}\n\nasync function test() {\n  const app = fastify({ logger: false });\n  await app.register(require(\u0027@fastify/express\u0027));\n  \n  // Middleware enforcing auth on /admin routes\n  app.use(\u0027/admin\u0027, function(req, res, next) {\n    if (!req.headers.authorization) {\n      res.statusCode = 403;\n      res.setHeader(\u0027content-type\u0027, \u0027application/json\u0027);\n      res.end(JSON.stringify({ error: \u0027Forbidden\u0027 }));\n      return;\n    }\n    next();\n  });\n  \n  // Root scope route \u2014 middleware works correctly\n  app.get(\u0027/admin/root-data\u0027, async () =\u003e ({ data: \u0027root-secret\u0027 }));\n  \n  // Child scope route \u2014 middleware BYPASSED\n  await app.register(async function(child) {\n    child.get(\u0027/secret\u0027, async () =\u003e ({ data: \u0027child-secret\u0027 }));\n  }, { prefix: \u0027/admin\u0027 });\n  \n  await app.listen({ port: 19876, host: \u00270.0.0.0\u0027 });\n  \n  // Root scope: correctly blocked\n  let r = await get(19876, \u0027/admin/root-data\u0027);\n  console.log(\u0027/admin/root-data (no auth):\u0027, r.status, r.body);\n  // Output: 403 {\"error\":\"Forbidden\"}\n  \n  // Child scope: BYPASSED \u2014 secret data returned without auth\n  r = await get(19876, \u0027/admin/secret\u0027);\n  console.log(\u0027/admin/secret (no auth):\u0027, r.status, r.body);\n  // Output: 200 {\"data\":\"child-secret\"}\n  \n  await app.close();\n}\ntest();\n```\n\nActual output:\n```\n/admin/root-data (no auth): 403 {\"error\":\"Forbidden\"}\n/admin/secret (no auth): 200 {\"data\":\"child-secret\"}\n```\n\n### Impact\n\nComplete bypass of Express middleware security controls for all routes defined in child plugin scopes. Authentication, authorization, rate limiting, CSRF protection, audit logging, and any other middleware-based security mechanisms are silently skipped for affected routes.\n\n- No special request crafting is required \u2014 normal requests bypass the middleware\n- It affects the idiomatic Fastify plugin pattern commonly used in production\n- The bypass is silent with no errors or warnings\n- Developers\u0027 basic testing of root-scoped routes will pass, masking the vulnerability\n- Any child plugin scope that shares a prefix with middleware is affected\n\nApplications using `@fastify/express` with path-scoped middleware and child plugins with matching prefixes are vulnerable in default configurations.\n\n### Affected Versions\n\n- `@fastify/express` v4.0.4 (latest at time of discovery)\n- Fastify 5.x in default configuration\n- No special router options required (`ignoreDuplicateSlashes` not needed)\n- Affects any child plugin registration where the prefix overlaps with middleware path scoping\n- Does NOT affect middleware registered without path scoping (global middleware)\n- Does NOT affect middleware registered on root path (`/`) due to special case handling\n\n### Variant Testing\n\n| Scenario | Middleware Path | Child Prefix | Result |\n|---|---|---|---|\n| Root route `/admin/root-data` | `/admin` | N/A | Middleware runs (403) |\n| Child route `/admin/secret` | `/admin` | `/admin` | **BYPASS** (200) |\n| Child route `/api/data` | `/api` | `/api` | **BYPASS** (200) |\n| Nested child `/admin/sub/data` | `/admin` | `/admin/sub` | **BYPASS** \u2014 path becomes `/admin/sub/admin` |\n| Middleware on `/` with any child | `/` | `/api` | No bypass \u2014 `path === \u0027/\u0027 \u0026\u0026 prefix.length \u003e 0` special case |\n\n### Suggested Fix\n\nThe `onRegister` function should store and re-use the original unprefixed middleware paths, or avoid re-calling the `use()` function entirely. Options include:\n1. Store the original path and function separately in `kMiddlewares` before prefixing\n2. Strip the parent prefix before re-registering in child scopes\n3. Store already-constructed Express middleware objects rather than re-processing paths",
  "id": "GHSA-hrwm-hgmj-7p9c",
  "modified": "2026-04-16T01:03:25Z",
  "published": "2026-04-16T01:03:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-express/security/advisories/GHSA-hrwm-hgmj-7p9c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33807"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify-express"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@fastify/express\u0027s middleware path doubling causes authentication bypass in child plugin scopes"
}

GHSA-HWPQ-RRPF-PGCQ

Vulnerability from github – Published: 2026-03-02 23:33 – Updated: 2026-03-30 13:44
VLAI
Summary
OpenClaw: system.run approval identity mismatch could execute a different binary than displayed
Details

Summary

system.run approvals in OpenClaw used rendered command text as the approval identity while trimming argv token whitespace. Runtime execution still used raw argv. A crafted trailing-space executable token could therefore execute a different binary than what the approver saw.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.2.24
  • Patched versions: >= 2026.2.25

Impact

This is an approval-integrity bypass that can lead to unexpected command execution under the OpenClaw runtime user when an attacker can influence command argv and reuse/obtain a matching approval context.

Trust Model Note

OpenClaw does not treat adversarial multi-user sharing of one gateway host/config as a supported security boundary. This finding is still valid in supported deployments because it breaks the operator approval boundary itself (approved display command vs executed argv).

Fix Commit(s)

  • 03e689fc89bbecbcd02876a95957ef1ad9caa176

Release Process Note

patched_versions is pre-set to the release (2026.2.25). Advisory published with npm release 2026.2.25.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T23:33:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n`system.run` approvals in OpenClaw used rendered command text as the approval identity while trimming argv token whitespace. Runtime execution still used raw argv. A crafted trailing-space executable token could therefore execute a different binary than what the approver saw.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.24`\n- Patched versions: `\u003e= 2026.2.25`\n\n### Impact\nThis is an approval-integrity bypass that can lead to unexpected command execution under the OpenClaw runtime user when an attacker can influence `command` argv and reuse/obtain a matching approval context.\n\n### Trust Model Note\nOpenClaw does not treat adversarial multi-user sharing of one gateway host/config as a supported security boundary. This finding is still valid in supported deployments because it breaks the operator approval boundary itself (approved display command vs executed argv).\n\n### Fix Commit(s)\n- `03e689fc89bbecbcd02876a95957ef1ad9caa176`\n\n### Release Process Note\n`patched_versions` is pre-set to the release (`2026.2.25`). Advisory published with npm release `2026.2.25`.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-hwpq-rrpf-pgcq",
  "modified": "2026-03-30T13:44:16Z",
  "published": "2026-03-02T23:33:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hwpq-rrpf-pgcq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32065"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/03e689fc89bbecbcd02876a95957ef1ad9caa176"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-identity-mismatch-in-system-run-command-execution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: system.run approval identity mismatch could execute a different binary than displayed"
}

GHSA-J4H9-PM27-4RFW

Vulnerability from github – Published: 2026-06-23 18:03 – Updated: 2026-06-23 18:03
VLAI
Summary
OctoPrint has possible file exfiltration via query parameters on upload endpoints
Details

Impact

OctoPrint versions up until and including 1.11.7 as well as 2.0.0rc1 and 2.0.0rc2 contain a vulnerability that allows an attacker with the FILE_UPLOAD permission to exfiltrate files from the host that OctoPrint has read access to, by moving them into the upload folder where they then can be downloaded from. This vulnerability was already reported as GHSA-m9jh-jf9h-x3h2/CVE-2025-48067 but the fix provided in OctoPrint 1.11.2 turned out to be incomplete.

The primary risk lies in the potential exfiltration of secrets stored inside OctoPrint's config, or further system files. By removing important runtime files, this could also be used to impact the availability of the host after an attempted server restart. Given that the attacker requires a user account with file upload permissions, the actual impact of this should however hopefully be minimal in most cases.

Patches

The vulnerability has been patched in version 1.11.8 and 2.0.0rc3.

Details

OctoPrint's web application is implemented in Flask, but uploads are first intercepted by a custom upload handler built on Tornado that sits in front of it. The handler streams the upload to a temporary file on disk - so files larger than the available memory can be uploaded - and rewrites the request, adding internal form fields that tell Flask where to find that temporary file.

These fields are reserved and meant to be set only by the upload handler, never by the client. The previous fix from GHSA-m9jh-jf9h-x3h2/CVE-2025-48067 stripped them from the request received from the client when they were sent as multipart form fields, yet they could still reach Flask through other channels: as plain query parameters, or - since the Tornado handler and Flask did not parse requests identically - smuggled in via several "parser differentials" that looked harmless to the handler while Flask still saw the injected fields. Any of these let an attacker make OctoPrint treat an arbitrary file on the host as a freshly uploaded one and move it into the upload folder.

The following endpoints in OctoPrint are affected:

  • /api/files/{local|sdcard}
  • /api/languages
  • /plugin/backup/restore
  • /plugin/pluginmanager/upload_file

Further upload endpoints in third party plugins might be affected too.

The fix rejects requests carrying any of the reserved fields, aligns the Tornado handler's request parsing with Flask's (Werkzeug) to avoid any differential parsing, and re-validates the request rewritten by Tornado before forwarding it to Flask.

Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by Koh Jun Sheng and Jacopo Tediosi.

Timeline

2026-06-04: Report received 2026-06-04: Report acknowledged 2026-06-08: Report verified 2026-06-17: Fix ready for 1.11.x 2026-06-22: Fix ported to 2.0.0 2026-06-23: Fix released with 1.11.8 and 2.0.0rc3

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "OctoPrint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0rc2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "OctoPrint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0rc1"
            },
            {
              "fixed": "2.0.0rc3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T18:03:54Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nOctoPrint versions up until and including 1.11.7 as well as 2.0.0rc1 and 2.0.0rc2 contain a vulnerability that allows an attacker with the `FILE_UPLOAD` permission to exfiltrate files from the host that OctoPrint has read access to, by moving them into the upload folder where they then can be downloaded from. This vulnerability was already reported as [GHSA-m9jh-jf9h-x3h2/CVE-2025-48067](https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-m9jh-jf9h-x3h2) but the fix provided in OctoPrint 1.11.2 turned out to be incomplete.\n\nThe primary risk lies in the potential exfiltration of secrets stored inside OctoPrint\u0027s config, or further system files. By removing important runtime files, this could also be used to impact the availability of the host after an attempted server restart. Given that the attacker requires a user account with file upload permissions, the actual impact of this should however hopefully be minimal in most cases.\n\n### Patches\n\nThe vulnerability has been patched in version 1.11.8 and 2.0.0rc3.\n\n### Details\n\nOctoPrint\u0027s web application is implemented in Flask, but uploads are first intercepted by a custom upload handler built on Tornado that sits in front of it. The handler streams the upload to a temporary file on disk - so files larger than the available memory can be uploaded - and rewrites the request, adding internal form fields that tell Flask where to find that temporary file.\n\nThese fields are reserved and meant to be set only by the upload handler, never by the client. The previous fix from [GHSA-m9jh-jf9h-x3h2/CVE-2025-48067](https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-m9jh-jf9h-x3h2) stripped them from the request received from the client when they were sent as multipart form fields, yet they could still reach Flask through other channels: as plain query parameters, or - since the Tornado handler and Flask did not parse requests identically - smuggled in via several \"parser differentials\" that looked harmless to the handler while Flask still saw the injected fields. Any of these let an attacker make OctoPrint treat an arbitrary file on the host as a freshly uploaded one and move it into the upload folder.\n\nThe following endpoints in OctoPrint are affected:\n\n- `/api/files/{local|sdcard}`\n- `/api/languages`\n- `/plugin/backup/restore`\n- `/plugin/pluginmanager/upload_file`\n\nFurther upload endpoints in third party plugins might be affected too.\n\nThe fix rejects requests carrying any of the reserved fields, aligns the Tornado handler\u0027s request parsing with Flask\u0027s (Werkzeug) to avoid any differential parsing, and re-validates the request rewritten by Tornado before forwarding it to Flask.\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed to OctoPrint by Koh Jun Sheng and Jacopo Tediosi.\n\n### Timeline\n\n2026-06-04: Report received\n2026-06-04: Report acknowledged\n2026-06-08: Report verified\n2026-06-17: Fix ready for 1.11.x\n2026-06-22: Fix ported to 2.0.0\n2026-06-23: Fix released with 1.11.8 and 2.0.0rc3",
  "id": "GHSA-j4h9-pm27-4rfw",
  "modified": "2026-06-23T18:03:54Z",
  "published": "2026-06-23T18:03:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-j4h9-pm27-4rfw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OctoPrint/OctoPrint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OctoPrint has possible file exfiltration via query parameters on upload endpoints"
}

GHSA-JJ37-3377-M6VV

Vulnerability from github – Published: 2025-11-14 21:30 – Updated: 2026-05-13 13:45
VLAI
Summary
Duplicate Advisory: Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-mm7p-fcc7-pg87. This link is maintained to preserve external references.

Original Description

A vulnerability was identified in the email parsing library due to improper handling of specially formatted recipient email addresses. An attacker can exploit this flaw by crafting a recipient address that embeds an external address within quotes. This causes the application to misdirect the email to the attacker's external address instead of the intended internal recipient. This could lead to a significant data leak of sensitive information and allow an attacker to bypass security filters and access controls.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1286",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-17T17:17:33Z",
    "nvd_published_at": "2025-11-14T20:15:45Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-mm7p-fcc7-pg87. This link is maintained to preserve external references.\n\n## Original Description\nA vulnerability was identified in the email parsing library due to improper handling of specially formatted recipient email addresses. An attacker can exploit this flaw by crafting a recipient address that embeds an external address within quotes. This causes the application to misdirect the email to the attacker\u0027s external address instead of the intended internal recipient. This could lead to a significant data leak of sensitive information and allow an attacker to bypass security filters and access controls.",
  "id": "GHSA-jj37-3377-m6vv",
  "modified": "2026-05-13T13:45:17Z",
  "published": "2025-11-14T21:30:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-mm7p-fcc7-pg87"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13033"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/1150d99fba77280df2cfb1885c43df23109a8626"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:15979"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3751"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-13033"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2402179"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict",
  "withdrawn": "2025-11-17T17:17:33Z"
}

No mitigation information available for this CWE.

CAPEC-105: HTTP Request Splitting

An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).

See CanPrecede relationships for possible consequences.

CAPEC-273: HTTP Response Smuggling

An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).

See CanPrecede relationships for possible consequences.

CAPEC-34: HTTP Response Splitting

An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.

See CanPrecede relationships for possible consequences.