Common Weakness Enumeration

CWE-755

Discouraged

Improper Handling of Exceptional Conditions

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not handle or incorrectly handles an exceptional condition.

703 vulnerabilities reference this CWE, most recent first.

GHSA-X983-H22Q-4R7V

Vulnerability from github – Published: 2022-04-14 00:00 – Updated: 2022-04-22 00:01
VLAI
Details

An improper handling of exceptional conditions vulnerability exists in the DNS proxy feature of Palo Alto Networks PAN-OS software that enables a meddler-in-the-middle (MITM) to send specifically crafted traffic to the firewall that causes the service to restart unexpectedly. Repeated attempts to send this request result in denial-of-service to all PAN-OS services by restarting the device in maintenance mode. This issue does not impact Panorama appliances and Prisma Access customers. This issue impacts: PAN-OS 8.1 versions earlier than PAN-OS 8.1.22; PAN-OS 9.0 versions earlier than PAN-OS 9.0.16; PAN-OS 9.1 versions earlier than PAN-OS 9.1.13; PAN-OS 10.0 versions earlier than PAN-OS 10.0.10; PAN-OS 10.1 versions earlier than PAN-OS 10.1.5. This issue does not impact PAN-OS 10.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-0023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-13T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper handling of exceptional conditions vulnerability exists in the DNS proxy feature of Palo Alto Networks PAN-OS software that enables a meddler-in-the-middle (MITM) to send specifically crafted traffic to the firewall that causes the service to restart unexpectedly. Repeated attempts to send this request result in denial-of-service to all PAN-OS services by restarting the device in maintenance mode. This issue does not impact Panorama appliances and Prisma Access customers. This issue impacts: PAN-OS 8.1 versions earlier than PAN-OS 8.1.22; PAN-OS 9.0 versions earlier than PAN-OS 9.0.16; PAN-OS 9.1 versions earlier than PAN-OS 9.1.13; PAN-OS 10.0 versions earlier than PAN-OS 10.0.10; PAN-OS 10.1 versions earlier than PAN-OS 10.1.5. This issue does not impact PAN-OS 10.2.",
  "id": "GHSA-x983-h22q-4r7v",
  "modified": "2022-04-22T00:01:04Z",
  "published": "2022-04-14T00:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0023"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2022-0023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X9M8-F37F-RW74

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

In mintplex-labs/anything-llm, a vulnerability exists in the thread update process that allows users with Default or Manager roles to escalate their privileges to Administrator. The issue arises from improper input validation when handling HTTP POST requests to the endpoint /workspace/:slug/thread/:threadSlug/update. Specifically, the application fails to validate or check user input before passing it to the workspace_thread Prisma model for execution. This oversight allows attackers to craft a Prisma relation query operation that manipulates the users model to change a user's role to admin. Successful exploitation grants attackers the highest level of user privileges, enabling them to see and perform all actions within the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-3150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T19:16:00Z",
    "severity": "HIGH"
  },
  "details": "In mintplex-labs/anything-llm, a vulnerability exists in the thread update process that allows users with Default or Manager roles to escalate their privileges to Administrator. The issue arises from improper input validation when handling HTTP POST requests to the endpoint `/workspace/:slug/thread/:threadSlug/update`. Specifically, the application fails to validate or check user input before passing it to the `workspace_thread` Prisma model for execution. This oversight allows attackers to craft a Prisma relation query operation that manipulates the `users` model to change a user\u0027s role to admin. Successful exploitation grants attackers the highest level of user privileges, enabling them to see and perform all actions within the system.",
  "id": "GHSA-x9m8-f37f-rw74",
  "modified": "2024-06-06T21:30:37Z",
  "published": "2024-06-06T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mintplex-labs/anything-llm/commit/200bd7f0615347ed2efc07903d510e5a208b0afc"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/745f5c80-14ea-4055-9f15-a066ae93e5a3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XG58-75QF-9R67

Vulnerability from github – Published: 2024-11-25 19:35 – Updated: 2024-12-04 16:22
VLAI
Summary
Cilium's Layer 7 policy enforcement may not occur in policies with wildcarded port ranges
Details

Impact

For users with the following configuration:

then Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy.

This issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16.

For reference, an example of a pair of policies that would trigger this issue is:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "layer-3-and-4"
spec:
  endpointSelector:
    matchLabels:
      app: service
  ingress:
    - fromCIDR:
      - 192.168.60.0/24
      toPorts:
      - ports:
        - port: "80"
          endPort: 444
          protocol: TCP

and

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "layer-4-and-7"
spec:
  endpointSelector:
    matchLabels:
      app: service
  ingress:
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public"

In the above example, requests would be permitted to all HTTP paths on matching endpoints, rather than just GET requests to the /public path as intended by the layer-4-and-7 policy. In patched versions of Cilium, the layer-4-and-7 rule would take precedence over the layer-3-and-4 rule.

Patches

This issue is patched in https://github.com/cilium/cilium/pull/35150.

This issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive.

This issue is patched in Cilium v1.16.4.

Workarounds

Users with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for resolving this issue.

For more information

If you have any questions or comments about this advisory, please reach out on Slack.

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.

Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/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:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cilium/cilium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0"
            },
            {
              "fixed": "1.16.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-52529"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-25T19:35:10Z",
    "nvd_published_at": "2024-11-25T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nFor users with the following configuration:\n\n* An allow policy that selects a [Layer 3 identity](https://docs.cilium.io/en/v1.14/security/policy/language/#layer-3-examples) and a [port range](https://docs.cilium.io/en/stable/security/policy/language/#example-port-ranges) **AND**\n* A [Layer 7 allow policy](https://docs.cilium.io/en/latest/security/policy/language/#layer-7-examples) that selects a specific port within the first policy\u0027s range \n\nthen Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy.\n\nThis issue only affects users who use Cilium\u0027s port range functionality, which was introduced in Cilium v1.16.\n\nFor reference, an example of a pair of policies that would trigger this issue is:\n\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n  name: \"layer-3-and-4\"\nspec:\n  endpointSelector:\n    matchLabels:\n      app: service\n  ingress:\n    - fromCIDR:\n      - 192.168.60.0/24\n      toPorts:\n      - ports:\n        - port: \"80\"\n          endPort: 444\n          protocol: TCP\n```\nand\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n  name: \"layer-4-and-7\"\nspec:\n  endpointSelector:\n    matchLabels:\n      app: service\n  ingress:\n    toPorts:\n    - ports:\n      - port: \"80\"\n        protocol: TCP\n      rules:\n        http:\n        - method: \"GET\"\n          path: \"/public\"\n```\n\nIn the above example, requests would be permitted to all HTTP paths on matching endpoints, rather than just `GET` requests to the `/public` path as intended by the `layer-4-and-7` policy. In patched versions of Cilium, the `layer-4-and-7` rule would take precedence over the `layer-3-and-4` rule.\n\n### Patches\n\nThis issue is patched in https://github.com/cilium/cilium/pull/35150.\n\nThis issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive.\n\nThis issue is patched in Cilium v1.16.4.\n\n### Workarounds\n\nUsers with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.\n\n### Acknowledgements\nThe Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for resolving this issue.\n\n### For more information\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.\n",
  "id": "GHSA-xg58-75qf-9r67",
  "modified": "2024-12-04T16:22:27Z",
  "published": "2024-11-25T19:35:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cilium/cilium/security/advisories/GHSA-xg58-75qf-9r67"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52529"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cilium/cilium/pull/35150"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cilium/cilium"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/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:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Cilium\u0027s Layer 7 policy enforcement may not occur in policies with wildcarded port ranges"
}

GHSA-XG75-Q3Q5-CQMV

Vulnerability from github – Published: 2022-04-22 20:55 – Updated: 2024-03-04 18:35
VLAI
Summary
Denial of Service in http-swagger
Details

Impact

Allows an attacker to perform a DOS attack consisting of memory exhaustion on the host system.

Patches

Yes. Please upgrade to v1.2.6.

Workarounds

A workaround is to restrict the path prefix to the "GET" method. As shown below

func main() {
    r := mux.NewRouter()

    r.PathPrefix("/swagger/").Handler(httpSwagger.Handler(
        httpSwagger.URL("http://localhost:1323/swagger/doc.json"), //The url pointing to API definition
        httpSwagger.DeepLinking(true),
        httpSwagger.DocExpansion("none"),
        httpSwagger.DomID("#swagger-ui"),
    )).Methods(http.MethodGet)

References

Reporter dongguangli from https://www.huoxian.cn/ company

For more information

If you have any questions or comments about this advisory: * Open an issue in http-swagger

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/swaggo/http-swagger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24863"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-22T20:55:52Z",
    "nvd_published_at": "2022-04-18T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAllows an attacker to perform a DOS attack consisting of memory exhaustion on the host system.\n\n### Patches\nYes. Please upgrade to v1.2.6.\n\n### Workarounds\nA workaround is to restrict the path prefix to the \"GET\" method. As shown below\n```\nfunc main() {\n\tr := mux.NewRouter()\n\n\tr.PathPrefix(\"/swagger/\").Handler(httpSwagger.Handler(\n\t\thttpSwagger.URL(\"http://localhost:1323/swagger/doc.json\"), //The url pointing to API definition\n\t\thttpSwagger.DeepLinking(true),\n\t\thttpSwagger.DocExpansion(\"none\"),\n\t\thttpSwagger.DomID(\"#swagger-ui\"),\n\t)).Methods(http.MethodGet)\n```\n\n### References\nReporter dongguangli from https://www.huoxian.cn/ company\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [http-swagger](https://github.com/swaggo/http-swagger/issues)\n\n",
  "id": "GHSA-xg75-q3q5-cqmv",
  "modified": "2024-03-04T18:35:26Z",
  "published": "2022-04-22T20:55:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/swaggo/http-swagger/security/advisories/GHSA-xg75-q3q5-cqmv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24863"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swaggo/http-swagger/pull/62"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swaggo/http-swagger/commit/b7d83e8fba85a7a51aa7e45e8244b4173f15049e"
    },
    {
      "type": "WEB",
      "url": "https://cosmosofcyberspace.github.io/improper_http_method_leads_to_xss/poc.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/swaggo/http-swagger"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swaggo/http-swagger/releases/tag/v1.2.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in http-swagger"
}

GHSA-XH3C-6GCQ-G4RV

Vulnerability from github – Published: 2026-05-18 17:35 – Updated: 2026-05-18 17:35
VLAI
Summary
multiparty vulnerable to Denial of Service via Uncaught Exception in filename* parameter parsing
Details

Impact

multiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a Content-Disposition: filename*=utf-8'' header containing a malformed percent-encoding (e.g., %FF, %GG), the parser invokes decodeURI on the value without try/catch. The resulting URIError propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected.

Patches

Users should upgrade to multiparty@4.3.0 or higher.

Workarounds

None.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "multiparty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-8162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:35:24Z",
    "nvd_published_at": "2026-05-12T10:16:49Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nmultiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a `multipart/form-data` request with a `Content-Disposition: filename*=utf-8\u0027\u0027` header containing a malformed percent-encoding (e.g., `%FF`, `%GG`), the parser invokes `decodeURI` on the value without try/catch. The resulting `URIError` propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected.\n\n### Patches\n\nUsers should upgrade to multiparty@4.3.0 or higher.\n\n### Workarounds\n\nNone.",
  "id": "GHSA-xh3c-6gcq-g4rv",
  "modified": "2026-05-18T17:35:24Z",
  "published": "2026-05-18T17:35:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pillarjs/multiparty/security/advisories/GHSA-xh3c-6gcq-g4rv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8162"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pillarjs/multiparty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pillarjs/multiparty/releases/tag/v4.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "multiparty vulnerable to Denial of Service via Uncaught Exception in filename* parameter parsing"
}

GHSA-XHP9-4947-RQ78

Vulnerability from github – Published: 2022-06-03 00:01 – Updated: 2024-09-13 15:51
VLAI
Summary
Denial of service in bottle
Details

Bottle before 0.12.20 mishandles errors during early request binding.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "bottle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31799"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-03T22:31:26Z",
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Bottle before 0.12.20 mishandles errors during early request binding.",
  "id": "GHSA-xhp9-4947-rq78",
  "modified": "2024-09-13T15:51:00Z",
  "published": "2022-06-03T00:01:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31799"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bottlepy/bottle/commit/a2b0ee6bb4ce88895429ec4aca856616244c4c4c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bottlepy/bottle/commit/e140e1b54da721a660f2eb9d58a106b7b3ff2f00"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-xhp9-4947-rq78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bottlepy/bottle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bottlepy/bottle/compare/0.12.19...0.12.20"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/bottle/PYSEC-2022-227.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/06/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IE7U6J45PUEXIYYVWJKPM6QXIRKDK4HD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KTLOQGMDZEPIYTFC2G53OQV2ULCGYS3F"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5159"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Denial of service in bottle"
}

GHSA-XJGC-MVGW-P5QH

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2022-10-14 12:00
VLAI
Details

A CWE-248: Uncaught Exception vulnerability exists IN Modicon M580 all versions prior to V2.80, which could cause a possible denial of service when sending an appropriately timed HTTP request to the controller.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-6830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-17T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-248: Uncaught Exception vulnerability exists IN Modicon M580 all versions prior to V2.80, which could cause a possible denial of service when sending an appropriately timed HTTP request to the controller.",
  "id": "GHSA-xjgc-mvgw-p5qh",
  "modified": "2022-10-14T12:00:19Z",
  "published": "2022-05-24T16:56:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6830"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJGH-8JRF-3XGW

Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2025-10-22 00:32
VLAI
Details

Improper handling of address deregistration on failure can lead to new GPU address allocation failure. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-1906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-07T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper handling of address deregistration on failure can lead to new GPU address allocation failure. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
  "id": "GHSA-xjgh-8jrf-3xgw",
  "modified": "2025-10-22T00:32:15Z",
  "published": "2022-05-24T19:01:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1906"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-1906"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJHF-7833-3PM5

Vulnerability from github – Published: 2025-08-28 15:34 – Updated: 2025-11-05 20:41
VLAI
Summary
Volto affected by possible DoS by invoking specific URL by anonymous user
Details

Impact

When visiting a specific URL, an anonymous user could cause the NodeJS server part of Volto to quit with an error.

Patches

The problem has been patched and the patch has been backported to Volto major versions down until 16. It is advised to upgrade to the latest patch release of your respective current major version:

Workarounds

Make sure your setup automatically restarts processes that quit with an error. This won't prevent a crash, but it minimises downtime.

Report

The problem was discovered by FHNW, a client of Plone provider kitconcept, who shared it with the Plone Zope Security Team (security@plone.org).

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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@plone/volto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "16.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@plone/volto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "17.0.0"
            },
            {
              "fixed": "17.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@plone/volto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "fixed": "18.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@plone/volto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0-alpha.1"
            },
            {
              "fixed": "19.0.0-alpha.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-28T15:34:28Z",
    "nvd_published_at": "2025-08-28T18:15:33Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nWhen visiting a specific URL, an anonymous user could cause the NodeJS server part of Volto to quit with an error.\n\n### Patches\nThe problem has been patched and the patch has been backported to Volto major versions down until 16. It is advised to upgrade to the latest patch release of your respective current major version:\n\n- Volto 16: [16.34.0](https://github.com/plone/volto/releases/tag/16.34.0)\n- Volto 17: [17.22.1](https://github.com/plone/volto/releases/tag/17.22.1)\n- Volto 18: [18.24.0](https://github.com/plone/volto/releases/tag/18.24.0)\n- Volto 19: [19.0.0-alpha4](https://github.com/plone/volto/releases/tag/19.0.0-alpha.4)\n\n### Workarounds\nMake sure your setup automatically restarts processes that quit with an error. This won\u0027t prevent a crash, but it minimises downtime.\n\n### Report\nThe problem was discovered by FHNW, a client of Plone provider kitconcept, who shared it with the Plone Zope Security Team (security@plone.org).",
  "id": "GHSA-xjhf-7833-3pm5",
  "modified": "2025-11-05T20:41:12Z",
  "published": "2025-08-28T15:34:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/security/advisories/GHSA-xjhf-7833-3pm5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58047"
    },
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/commit/2789a287ac45ad9039fb9161d465ba13241fff0a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/plone/volto"
    },
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/releases/tag/16.34.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/releases/tag/17.22.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/releases/tag/18.24.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/plone/volto/releases/tag/19.0.0-alpha.4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/08/28/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Volto affected by possible DoS by invoking specific URL by anonymous user"
}

GHSA-XJHV-V822-PF94

Vulnerability from github – Published: 2026-02-24 20:44 – Updated: 2026-02-27 20:24
VLAI
Summary
Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future
Details

The affected versions of Wasmtime can panic if the host embedder drops the future returned by wasmtime::component::[Typed]Func::call_async before it resolves.

Details

Starting with Wasmtime 39.0.0, the component-model-async feature became the default, which brought with it a new implementation of [Typed]Func::call_async which made it capable of calling async-typed guest export functions. However, that implementation had a bug leading to a panic under certain circumstances:

  1. The host embedding calls [Typed]Func::call_async on a function exported by a component, polling the returned Future once.
  2. The component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using LinkerInstance::func_wrap_async which yields, or due an epoch interruption.
  3. The host embedding drops the Future after polling it once. This leaves the component instance in a non-reenterable state since the call never had a chance to complete.
  4. The host embedding calls [Typed]Func::call_async again, polling the returned Future. Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call.
  5. The host embedding ignores the trap and drops the Future. This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited.

Impact

When a host embedder using the affected versions of Wasmtime calls wasmtime::component::[Typed]Func::call_async on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the component-model-async compile-time feature disabled are unaffected.

Patches

Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected.

Workarounds

If an embedding is not actually using any component-model-async features then disabling the component-model-async Cargo feature can work around this issue. This issue can also be worked around by either ensuring every call_async future is awaited until it completes or refraining from using the Store again after dropping a not-yet-resolved call_async future.

Resources

This was first reported in https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "39.0.0"
            },
            {
              "fixed": "40.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "41.0.0"
            },
            {
              "fixed": "41.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T20:44:46Z",
    "nvd_published_at": "2026-02-24T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "The affected versions of Wasmtime can panic if the host embedder drops the future returned by `wasmtime::component::[Typed]Func::call_async` before it resolves.\n\n### Details\n\nStarting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions.  However, that implementation had a bug leading to a panic under certain circumstances:\n\n1. The host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once.\n2. The component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption.\n3. The host embedding drops the `Future` after polling it once.  This leaves the component instance in a non-reenterable state since the call never had a chance to complete.\n4. The host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`.  Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call.\n5. The host embedding ignores the trap and drops the `Future`.  This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited.\n\n### Impact\nWhen a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected.\n\n### Patches\nWasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected.\n\n### Workarounds\nIf an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.\n\n### Resources\nThis was first reported in https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29",
  "id": "GHSA-xjhv-v822-pf94",
  "modified": "2026-02-27T20:24:27Z",
  "published": "2026-02-24T20:44:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xjhv-v822-pf94"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/9e51c0d9a240a9613d279c061f82286bd11383fd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/d86b00736b9ece60b3c81e52f7a7e4cdd9f7d895"
    },
    {
      "type": "WEB",
      "url": "https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/.E2.9C.94.20Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29/with/574438798"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/releases/tag/v40.0.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/releases/tag/v41.0.4"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0022.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list