Common Weakness Enumeration

CWE-754

Allowed-with-Review

Improper Check for Unusual or Exceptional Conditions

Abstraction: Class · Status: Incomplete

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

954 vulnerabilities reference this CWE, most recent first.

GHSA-38RG-6V6G-2QMQ

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

An issue was discovered in res_http_websocket.c in Asterisk 15.x through 15.2.1. If the HTTP server is enabled (default is disabled), WebSocket payloads of size 0 are mishandled (with a busy loop).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-22T00:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in res_http_websocket.c in Asterisk 15.x through 15.2.1. If the HTTP server is enabled (default is disabled), WebSocket payloads of size 0 are mishandled (with a busy loop).",
  "id": "GHSA-38rg-6v6g-2qmq",
  "modified": "2022-05-13T01:53:18Z",
  "published": "2022-05-13T01:53:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7287"
    },
    {
      "type": "WEB",
      "url": "https://issues.asterisk.org/jira/browse/ASTERISK-27658"
    },
    {
      "type": "WEB",
      "url": "http://downloads.digium.com/pub/security/AST-2018-006.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103120"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040419"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-393F-2JR3-CP69

Vulnerability from github – Published: 2021-05-21 14:22 – Updated: 2024-10-30 23:22
VLAI
Summary
CHECK-fail in DrawBoundingBoxes
Details

Impact

An attacker can trigger a denial of service via a CHECK failure by passing an empty image to tf.raw_ops.DrawBoundingBoxes:

import tensorflow as tf

images = tf.fill([53, 0, 48, 1], 0.)
boxes = tf.fill([53, 31, 4], 0.)
boxes = tf.Variable(boxes)
boxes[0, 0, 0].assign(3.90621)
tf.raw_ops.DrawBoundingBoxes(images=images, boxes=boxes)

This is because the implementation uses CHECK_* assertions instead of OP_REQUIRES to validate user controlled inputs. Whereas OP_REQUIRES allows returning an error condition back to the user, the CHECK_* macros result in a crash if the condition is false, similar to assert.

const int64 max_box_row_clamp = std::min<int64>(max_box_row, height - 1);
... 
CHECK_GE(max_box_row_clamp, 0);

In this case, height is 0 from the images input. This results in max_box_row_clamp being negative and the assertion being falsified, followed by aborting program execution.

Patches

We have patched the issue in GitHub commit b432a38fe0e1b4b904a6c222cbce794c39703e87.

The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

For more information

Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution

This vulnerability has been reported by Yakun Zhang and Ying Wang of Baidu X-Team.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29533"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-18T22:50:31Z",
    "nvd_published_at": "2021-05-14T20:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\nAn attacker can trigger a denial of service via a `CHECK` failure by passing an empty image to `tf.raw_ops.DrawBoundingBoxes`:\n\n```python\nimport tensorflow as tf\n\nimages = tf.fill([53, 0, 48, 1], 0.)\nboxes = tf.fill([53, 31, 4], 0.)\nboxes = tf.Variable(boxes)\nboxes[0, 0, 0].assign(3.90621)\ntf.raw_ops.DrawBoundingBoxes(images=images, boxes=boxes)\n```\n\nThis is because the [implementation](https://github.com/tensorflow/tensorflow/blob/ea34a18dc3f5c8d80a40ccca1404f343b5d55f91/tensorflow/core/kernels/image/draw_bounding_box_op.cc#L148-L165) uses `CHECK_*` assertions instead of `OP_REQUIRES` to validate user controlled inputs. Whereas `OP_REQUIRES` allows returning an error condition back to the user, the `CHECK_*` macros result in a crash if the condition is false, similar to `assert`.\n\n```cc\nconst int64 max_box_row_clamp = std::min\u003cint64\u003e(max_box_row, height - 1);\n... \nCHECK_GE(max_box_row_clamp, 0);\n``` \n    \nIn this case, `height` is 0 from the `images` input. This results in `max_box_row_clamp` being negative and the assertion being falsified, followed by aborting program execution.\n    \n### Patches\nWe have patched the issue in GitHub commit [b432a38fe0e1b4b904a6c222cbce794c39703e87](https://github.com/tensorflow/tensorflow/commit/b432a38fe0e1b4b904a6c222cbce794c39703e87).\n\nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by Yakun Zhang and Ying Wang of Baidu X-Team.",
  "id": "GHSA-393f-2jr3-cp69",
  "modified": "2024-10-30T23:22:16Z",
  "published": "2021-05-21T14:22:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-393f-2jr3-cp69"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/b432a38fe0e1b4b904a6c222cbce794c39703e87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-461.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-659.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-170.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CHECK-fail in DrawBoundingBoxes"
}

GHSA-393V-J9Q3-P63R

Vulnerability from github – Published: 2025-04-09 21:31 – Updated: 2025-04-09 21:31
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in the pfe (packet forwarding engine) of Juniper Networks Junos OS on MX Series causes a port within a pool to be blocked leading to Denial of Service (DoS).

In a DS-Lite (Dual-Stack Lite) and NAT (Network Address Translation) scenario, when crafted IPv6 traffic is received and prefix-length is set to 56, the ports assigned to the user will not be freed.  Eventually, users cannot establish new connections. Affected FPC/PIC need to be manually restarted to recover. Following is the command to identify the issue: 

user@host> show services nat source port-block      Host_IP                     External_IP                   Port_Block      Ports_Used/       Block_State/                                                               Range           Ports_Total       Left_Time(s)     2001::                        x.x.x.x                     58880-59391     256/256*1         Active/-       >>>>>>>>port still usedThis issue affects Junos OS on MX Series: 

  • from 21.2 before 21.2R3-S8, 
  • from 21.4 before 21.4R3-S7, 
  • from 22.1 before 22.1R3-S6, 
  • from 22.2 before 22.2R3-S4, 
  • from 22.3 before 22.3R3-S3, 
  • from 22.4 before 22.4R3-S2, 
  • from 23.2 before 23.2R2-S1, 
  • from 23.4 before 23.4R1-S2, 23.4R2.

This issue does not affect versions before 20.2R1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-09T20:15:25Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the pfe (packet forwarding engine) of Juniper Networks Junos OS on MX Series causes a port within a pool to be blocked leading to Denial of Service (DoS).\n\nIn a DS-Lite (Dual-Stack Lite) and NAT (Network Address Translation) scenario, when crafted IPv6 traffic is received and\u00a0prefix-length is set to 56,\u00a0the ports assigned to the user will not be freed.\u00a0 Eventually, users cannot establish new connections. Affected FPC/PIC need to be manually restarted to recover.\nFollowing is the command to identify the issue:\u00a0\n\n\n\u00a0 \u00a0 user@host\u003e show services nat source port-block\u00a0\n\u2003\u2003\u2003\u2003Host_IP  \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0  External_IP  \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Port_Block\u00a0 \u00a0 \u00a0 Ports_Used/  \u00a0 \u00a0 \u00a0 Block_State/\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0  Range  \u00a0 \u00a0 \u00a0 \u00a0 \u00a0  Ports_Total  \u00a0 \u00a0 \u00a0 Left_Time(s)\n\u2003\u2003\u2003\u20032001::\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 x.x.x.x\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a058880-59391\u00a0 \u00a0 \u00a0256/256*1\u00a0 \u00a0 \u00a0 \u00a0 \u00a0Active/-  \u00a0 \u00a0 \u00a0 \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003eport still usedThis issue affects Junos OS on MX Series:\u00a0\n\n  *  from 21.2 before 21.2R3-S8,\u00a0\n  *  from 21.4 before 21.4R3-S7,\u00a0\n  *  from 22.1 before 22.1R3-S6,\u00a0\n  *  from 22.2 before 22.2R3-S4,\u00a0\n  *  from 22.3 before 22.3R3-S3,\u00a0\n  *  from 22.4 before 22.4R3-S2,\u00a0\n  *  from 23.2 before 23.2R2-S1,\u00a0\n  *  from 23.4 before 23.4R1-S2, 23.4R2.\n\n\nThis issue does not affect versions before 20.2R1.",
  "id": "GHSA-393v-j9q3-p63r",
  "modified": "2025-04-09T21:31:43Z",
  "published": "2025-04-09T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21594"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA96449"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3C2F-8CPM-89M3

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39
VLAI
Details

An improper check for unusual or exceptional conditions in Juniper Networks Junos OS and Junos OS Evolved Routing Protocol Daemon (RPD) service allows an attacker to send a valid BGP FlowSpec message thereby causing an unexpected change in the route advertisements within the BGP FlowSpec domain leading to disruptions in network traffic causing a Denial of Service (DoS) condition. Continued receipt of these update messages will cause a sustained Denial of Service condition. This issue affects Juniper Networks: Junos OS: All versions prior to 17.3R3-S10 with the exceptions of 15.1X49-D240 on SRX Series and 15.1R7-S8 on EX Series; 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R2-S12, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S6; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S6; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S3; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1; 19.4 versions prior to 19.4R1-S3, 19.4R2-S3, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S3 20.2R2; 20.3 versions prior to 20.3R1-S1, 20.3R2. Junos OS Evolved: All versions prior to 20.3R1-S1-EVO, 20.3R2-EVO.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-0211"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-15T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An improper check for unusual or exceptional conditions in Juniper Networks Junos OS and Junos OS Evolved Routing Protocol Daemon (RPD) service allows an attacker to send a valid BGP FlowSpec message thereby causing an unexpected change in the route advertisements within the BGP FlowSpec domain leading to disruptions in network traffic causing a Denial of Service (DoS) condition. Continued receipt of these update messages will cause a sustained Denial of Service condition. This issue affects Juniper Networks: Junos OS: All versions prior to 17.3R3-S10 with the exceptions of 15.1X49-D240 on SRX Series and 15.1R7-S8 on EX Series; 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R2-S12, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S6; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S6; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S3; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1; 19.4 versions prior to 19.4R1-S3, 19.4R2-S3, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S3 20.2R2; 20.3 versions prior to 20.3R1-S1, 20.3R2. Junos OS Evolved: All versions prior to 20.3R1-S1-EVO, 20.3R2-EVO.",
  "id": "GHSA-3c2f-8cpm-89m3",
  "modified": "2022-05-24T17:39:20Z",
  "published": "2022-05-24T17:39:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0211"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11101"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3C6G-F7WV-RH98

Vulnerability from github – Published: 2022-08-17 00:00 – Updated: 2022-08-19 00:00
VLAI
Details

XPDF commit ffaf11c was discovered to contain a segmentation violation via Lexer::getObj(Object*) at /xpdf/Lexer.cc.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-16T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "XPDF commit ffaf11c was discovered to contain a segmentation violation via Lexer::getObj(Object*) at /xpdf/Lexer.cc.",
  "id": "GHSA-3c6g-f7wv-rh98",
  "modified": "2022-08-19T00:00:38Z",
  "published": "2022-08-17T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38234"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jhcloos/xpdf/issues/12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3CHW-8JQ2-W769

Vulnerability from github – Published: 2023-01-30 00:30 – Updated: 2023-02-07 23:17
VLAI
Summary
Froxlor contains Unchecked Error Condition
Details

Unchecked Error Condition in GitHub repository froxlor/froxlor prior to 2.0.10.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "froxlor/froxlor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-391",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-01T01:38:31Z",
    "nvd_published_at": "2023-01-29T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Unchecked Error Condition in GitHub repository froxlor/froxlor prior to 2.0.10.",
  "id": "GHSA-3chw-8jq2-w769",
  "modified": "2023-02-07T23:17:55Z",
  "published": "2023-01-30T00:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/commit/7b08a71c59430d06c1efb012a6c6448262aacdb1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Froxlor/Froxlor"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/4ab24ee2-3ff6-4248-9555-0af3e5f754ec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Froxlor contains Unchecked Error Condition"
}

GHSA-3F5R-XJP9-9XRP

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

A CWE-248 Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a denial of Service when sending invalid debug parameters to the controller over Modbus.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-248 Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a denial of Service when sending invalid debug parameters to the controller over Modbus.",
  "id": "GHSA-3f5r-xjp9-9xrp",
  "modified": "2022-05-24T16:46:14Z",
  "published": "2022-05-24T16:46:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7854"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0765"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3F7H-8WG4-948W

Vulnerability from github – Published: 2026-05-13 18:30 – Updated: 2026-05-13 18:30
VLAI
Details

ELECOM wireless LAN access point devices do not check if language parameter has an appropriate value. If a user views a malicious page while logged in, the admin page on the user's web browser may become broken.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-42950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-13T13:16:44Z",
    "severity": "MODERATE"
  },
  "details": "ELECOM wireless LAN access point devices do not check if language parameter has an appropriate value. If a user views a malicious page while logged in, the admin page on the user\u0027s web browser may become broken.",
  "id": "GHSA-3f7h-8wg4-948w",
  "modified": "2026-05-13T18:30:53Z",
  "published": "2026-05-13T18:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42950"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN03037325"
    },
    {
      "type": "WEB",
      "url": "https://www.elecom.co.jp/news/security/20260512-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3H5R-928V-MXHH

Vulnerability from github – Published: 2021-04-19 14:49 – Updated: 2021-10-08 21:22
VLAI
Summary
Unauthorized client-side property update in UIDL request handler in Vaadin 10 and 11
Details

Missing check in UIDL request handler in com.vaadin:flow-server versions 1.0.0 through 1.0.5 (Vaadin 10.0.0 through 10.0.7, and 11.0.0 through 11.0.2) allows attacker to update element property values via crafted synchronization message.

  • https://vaadin.com/security/cve-2018-25007
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:vaadin-bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:vaadin-bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-16T23:14:45Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Missing check in UIDL request handler in `com.vaadin:flow-server` versions 1.0.0 through 1.0.5 (Vaadin 10.0.0 through 10.0.7, and 11.0.0 through 11.0.2) allows attacker to update element property values via crafted synchronization message.\n\n- https://vaadin.com/security/cve-2018-25007",
  "id": "GHSA-3h5r-928v-mxhh",
  "modified": "2021-10-08T21:22:53Z",
  "published": "2021-04-19T14:49:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/platform/security/advisories/GHSA-3h5r-928v-mxhh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vaadin/platform"
    },
    {
      "type": "WEB",
      "url": "https://vaadin.com/security/cve-2018-25007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unauthorized client-side property update in UIDL request handler in Vaadin 10 and 11"
}

GHSA-3J4H-H3FP-VWWW

Vulnerability from github – Published: 2024-06-17 21:24 – Updated: 2024-06-17 21:24
VLAI
Summary
LNbits improperly handles potential network and payment failures when using Eclair backend
Details

Summary

Paying invoices in Eclair that do not get settled within the internal timeout (about 30s) lead to a payment being considered failed, even though it may still be in flight.

Details

Using blocking: true on the API call will lead to a timeout error if a payment does not get settled in the 30s timeout with the error: Ask timed out on [Actor[akka://eclair-node/user/$l#134241942]] after [30000 ms]. Message of type [fr.acinq.eclair.payment.send.PaymentInitiator$SendPaymentToNode]. A typical reason for AskTimeoutException is that the recipient actor didn't send a reply. https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L138

This is considered a payment failure by parts of the code, and assumes the payment is not going to be settled after: https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L144 https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L141 https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L146

The best way to fix this is to check the payment status after an error, and when not sure, always consider a payment still in flight.

PoC

A very simple way to exploit this is: - Create a hold invoice - Pay the invoice with the LNbits server backed by an Eclair node, until it times out - Settle the hold invoice

Impact

This vulnerability can lead to a total loss of funds for the node backend.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lnbits"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-17T21:24:18Z",
    "nvd_published_at": "2024-06-14T15:15:50Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPaying invoices in Eclair that do not get settled within the internal timeout (about 30s) lead to a payment being considered failed, even though it may still be in flight.\n\n### Details\n\nUsing `blocking: true` on the API call will lead to a timeout error if a payment does not get settled in the 30s timeout with the error: `Ask timed out on [Actor[akka://eclair-node/user/$l#134241942]] after [30000 ms]. Message of type [fr.acinq.eclair.payment.send.PaymentInitiator$SendPaymentToNode]. A typical reason for AskTimeoutException is that the recipient actor didn\u0027t send a reply.`\nhttps://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L138\n\nThis is considered a payment failure by parts of the code, and assumes the payment is not going to be settled after:\nhttps://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L144\nhttps://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L141\nhttps://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L146\n\nThe best way to fix this is to check the payment status after an error, and when not sure, always consider a payment still in flight.\n\n### PoC\n\nA very simple way to exploit this is:\n- Create a hold invoice\n- Pay the invoice with the LNbits server backed by an Eclair node, until it times out\n- Settle the hold invoice\n\n### Impact\n\nThis vulnerability can lead to a total loss of funds for the node backend.\n",
  "id": "GHSA-3j4h-h3fp-vwww",
  "modified": "2024-06-17T21:24:18Z",
  "published": "2024-06-17T21:24:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lnbits/lnbits/security/advisories/GHSA-3j4h-h3fp-vwww"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34694"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lnbits/lnbits"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LNbits improperly handles potential network and payment failures when using Eclair backend"
}

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Implementation

Check the results of all functions that return a value and verify that the value is expected.

Mitigation
Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
  • Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
Architecture and Design Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Mitigation
Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

No CAPEC attack patterns related to this CWE.