Common Weakness Enumeration

CWE-617

Allowed

Reachable Assertion

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-RVGJ-FPWG-2M28

Vulnerability from github – Published: 2022-05-01 07:41 – Updated: 2024-02-08 03:32
VLAI
Details

KsIRC 1.3.12 allows remote attackers to cause a denial of service (crash) via a long PRIVMSG string when connecting to an Internet Relay Chat (IRC) server, which causes an assertion failure and results in a NULL pointer dereference. NOTE: this issue was originally reported as a buffer overflow.

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

{
  "affected": [],
  "aliases": [
    "CVE-2006-6811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-12-29T11:28:00Z",
    "severity": "MODERATE"
  },
  "details": "KsIRC 1.3.12 allows remote attackers to cause a denial of service (crash) via a long PRIVMSG string when connecting to an Internet Relay Chat (IRC) server, which causes an assertion failure and results in a NULL pointer dereference.  NOTE: this issue was originally reported as a buffer overflow.",
  "id": "GHSA-rvgj-fpwg-2m28",
  "modified": "2024-02-08T03:32:44Z",
  "published": "2022-05-01T07:41:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-6811"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/31134"
    },
    {
      "type": "WEB",
      "url": "https://issues.rpath.com/browse/RPL-922"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/3023"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/33443"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200701-26.xml"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1017453"
    },
    {
      "type": "WEB",
      "url": "http://www.addict3d.org/index.php?page=viewarticle\u0026trace=0\u0026type=security\u0026ID=8468"
    },
    {
      "type": "WEB",
      "url": "http://www.kde.org/info/security/advisory-20070109-1.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2007:009"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/456379/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/21790"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-409-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/5199"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RVJR-2WM5-538Q

Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30
VLAI
Details

In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T03:16:17Z",
    "severity": "MODERATE"
  },
  "details": "In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.",
  "id": "GHSA-rvjr-2wm5-538q",
  "modified": "2025-12-02T15:30:30Z",
  "published": "2025-12-02T03:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20757"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RWR2-3254-JMGR

Vulnerability from github – Published: 2025-07-29 15:31 – Updated: 2025-07-30 18:31
VLAI
Details

FlashMQ v1.14.0 was discovered to contain an assertion failure in the function PublishCopyFactory::getNewPublish, which occurs when the QoS value of the publish object is greater than 0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-42644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-29T14:15:34Z",
    "severity": "HIGH"
  },
  "details": "FlashMQ v1.14.0 was discovered to contain an assertion failure in the function PublishCopyFactory::getNewPublish, which occurs when the QoS value of the publish object is greater than 0.",
  "id": "GHSA-rwr2-3254-jmgr",
  "modified": "2025-07-30T18:31:32Z",
  "published": "2025-07-29T15:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/halfgaar/FlashMQ"
    },
    {
      "type": "WEB",
      "url": "https://github.com/songxpu/bug_report/blob/master/MQTT/FlashMQ/cve-2024-42644.md"
    },
    {
      "type": "WEB",
      "url": "https://www.flashmq.org/2024/06/17/flashmq-1-15-1-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RWW7-2GPW-FV6J

Vulnerability from github – Published: 2022-02-09 23:28 – Updated: 2024-11-13 22:46
VLAI
Summary
Crash when type cannot be specialized in Tensorflow
Details

Impact

Under certain scenarios, TensorFlow can fail to specialize a type during shape inference:

void InferenceContext::PreInputInit(
    const OpDef& op_def, const std::vector<const Tensor*>& input_tensors,
    const std::vector<ShapeHandle>& input_tensors_as_shapes) {
  const auto ret = full_type::SpecializeType(attrs_, op_def);
  DCHECK(ret.status().ok()) << "while instantiating types: " << ret.status();
  ret_types_ = ret.ValueOrDie();
  // ... 
}

However, DCHECK is a no-op in production builds and an assertion failure in debug builds. In the first case execution proceeds to the ValueOrDie line. This results in an assertion failure as ret contains an error Status, not a value. In the second case we also get a crash due to the assertion failure.

Patches

We have patched the issue in GitHub commit cb164786dc891ea11d3a900e90367c339305dc7b.

The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, and TensorFlow 2.6.3, 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.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-04T18:58:49Z",
    "nvd_published_at": "2022-02-04T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUnder certain scenarios, TensorFlow can fail to specialize a type during [shape inference](https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/framework/shape_inference.cc#L168-L174):\n\n```cc\nvoid InferenceContext::PreInputInit(\n    const OpDef\u0026 op_def, const std::vector\u003cconst Tensor*\u003e\u0026 input_tensors,\n    const std::vector\u003cShapeHandle\u003e\u0026 input_tensors_as_shapes) {\n  const auto ret = full_type::SpecializeType(attrs_, op_def);\n  DCHECK(ret.status().ok()) \u003c\u003c \"while instantiating types: \" \u003c\u003c ret.status();\n  ret_types_ = ret.ValueOrDie();\n  // ... \n}\n```\n\nHowever, `DCHECK` is a no-op in production builds and an assertion failure in debug builds. In the first case execution proceeds to the `ValueOrDie` line. This results in an assertion failure as `ret` contains an error `Status`, not a value. In the second case we also get a crash due to the assertion failure.\n### Patches\nWe have patched the issue in GitHub commit [cb164786dc891ea11d3a900e90367c339305dc7b](https://github.com/tensorflow/tensorflow/commit/cb164786dc891ea11d3a900e90367c339305dc7b).\n\nThe fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, and TensorFlow 2.6.3, 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.",
  "id": "GHSA-rww7-2gpw-fv6j",
  "modified": "2024-11-13T22:46:57Z",
  "published": "2022-02-09T23:28:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-rww7-2gpw-fv6j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/cb164786dc891ea11d3a900e90367c339305dc7b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2022-81.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2022-136.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/framework/shape_inference.cc#L168-L174"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Crash when type cannot be specialized in Tensorflow"
}

GHSA-RX8R-F2XX-98H9

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

PuTTY 0.71 before 0.84 has an assertion failure in ECDSA signature verification.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-25T21:16:35Z",
    "severity": "LOW"
  },
  "details": "PuTTY 0.71 before 0.84 has an assertion failure in ECDSA signature verification.",
  "id": "GHSA-rx8r-f2xx-98h9",
  "modified": "2026-05-26T13:30:51Z",
  "published": "2026-05-26T13:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48852"
    },
    {
      "type": "WEB",
      "url": "https://lists.tartarus.org/pipermail/putty-announce/2026/000042.html"
    },
    {
      "type": "WEB",
      "url": "https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ecdsa-remotely-triggerable-assertion.html"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXRQ-FV76-26PR

Vulnerability from github – Published: 2026-05-08 22:44 – Updated: 2026-06-08 23:47
VLAI
Summary
free5GC's NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)
Details

Summary

free5GC's NEF terminates the entire process when a stored PFD-subscription notifyUri cannot be reached. In PfdChangeNotifier.FlushNotifications(), the notifier calls NnefPFDmanagementNotify(...) and on any delivery error invokes logger.PFDManageLog.Fatal(err), which is os.Exit(1)-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen notifyUri and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status 1, dropping NEF's entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch Fatal).

The trigger uses three POSTs that are reachable without an Authorization header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the Fatal-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.

Details

Validated against the NEF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nef:v4.2.1 - Runtime NEF commit: 5ce35eab - Docker validation date: 2026-03-20 (container log timestamp 2026-03-20T16:00:03Z) - NEF endpoint: http://10.100.200.19:8000

Vulnerable notifier path:

_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(
    context.TODO(), nc.notifier.getSubURI(id), notifyReq)
if err != nil {
    logger.PFDManageLog.Fatal(err)   // <-- os.Exit(1)-equivalent
}

The failing branch is reached whenever NEF's outbound POST to the subscriber's notifyUri returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns 201 Created and only then does NEF die.

Code evidence (paths in free5gc/nef): - Notifier dispatch: - NFs/nef/internal/sbi/notifier/pfd_notifier.go:135 - Fatal call site (process exit): - NFs/nef/internal/sbi/notifier/pfd_notifier.go:142

PoC

Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 -- three unauthenticated POSTs, the third one indirectly triggers async notify -> Fatal -> process exit.

  1. Create an AF context (no Authorization header):
curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"afAppId":"app-nef-dos","anyUeInd":true}'

HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1
  1. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):
curl -i -X POST 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"applicationIds":["app-nef-dos"],"notifyUri":"http://127.0.0.1:1/notify"}'

HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1
  1. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:
curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions' \
  -H 'Content-Type: application/json' \
  --data '{"pfdDatas":{"app-nef-dos":{"externalAppId":"app-nef-dos","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any","permit out ip from any to 10.68.28.39 80"]}}}}}'

The PFD POST itself returns 201, but immediately afterward NEF exits.

  1. Confirm the NEF container is dead (exited, exit=1):
docker inspect nef --format 'status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}'

status=exited restart=0 exit=1
  1. NEF container logs (docker logs --since 2026-03-20T16:00:03Z nef) show the [FATA] line that terminated the process:
[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added
[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |
[FATA][NEF][PFDMng] Post "http://127.0.0.1:1/notify": dial tcp 127.0.0.1:1: connect: connection refused

Impact

Reachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied notifyUri. logger.Fatal is os.Exit(1)-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.

In v4.2.1, the trigger chain is reachable without an Authorization header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can: - Submit the three-step trigger anonymously and immediately terminate the NEF process. - Repeat the trigger after every restart to sustain the outage. - Pick any unreachable notifyUri (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same Fatal, so partial fixes that block one URI do not close the family.

No Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/924 Upstream fix: https://github.com/free5gc/nef/pull/25

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/free5gc/nef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-617",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:44:35Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NEF terminates the entire process when a stored PFD-subscription `notifyUri` cannot be reached. In `PfdChangeNotifier.FlushNotifications()`, the notifier calls `NnefPFDmanagementNotify(...)` and on any delivery error invokes `logger.PFDManageLog.Fatal(err)`, which is `os.Exit(1)`-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen `notifyUri` and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status `1`, dropping NEF\u0027s entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch `Fatal`).\n\nThe trigger uses three POSTs that are reachable without an `Authorization` header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the `Fatal`-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.1`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-20 (container log timestamp `2026-03-20T16:00:03Z`)\n- NEF endpoint: `http://10.100.200.19:8000`\n\nVulnerable notifier path:\n```go\n_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(\n    context.TODO(), nc.notifier.getSubURI(id), notifyReq)\nif err != nil {\n    logger.PFDManageLog.Fatal(err)   // \u003c-- os.Exit(1)-equivalent\n}\n```\n\nThe failing branch is reached whenever NEF\u0027s outbound POST to the subscriber\u0027s `notifyUri` returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns `201 Created` and only then does NEF die.\n\nCode evidence (paths in `free5gc/nef`):\n- Notifier dispatch:\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:135`\n- Fatal call site (process exit):\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:142`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` -- three unauthenticated POSTs, the third one indirectly triggers async notify -\u003e Fatal -\u003e process exit.\n\n1. Create an AF context (no Authorization header):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"afAppId\":\"app-nef-dos\",\"anyUeInd\":true}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1\n```\n\n2. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"applicationIds\":[\"app-nef-dos\"],\"notifyUri\":\"http://127.0.0.1:1/notify\"}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1\n```\n\n3. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"pfdDatas\":{\"app-nef-dos\":{\"externalAppId\":\"app-nef-dos\",\"pfds\":{\"pfd1\":{\"pfdId\":\"pfd1\",\"flowDescriptions\":[\"permit in ip from 10.68.28.39 80 to any\",\"permit out ip from any to 10.68.28.39 80\"]}}}}}\u0027\n```\nThe PFD POST itself returns `201`, but immediately afterward NEF exits.\n\n4. Confirm the NEF container is dead (`exited`, `exit=1`):\n```\ndocker inspect nef --format \u0027status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}\u0027\n```\n```\nstatus=exited restart=0 exit=1\n```\n\n5. NEF container logs (`docker logs --since 2026-03-20T16:00:03Z nef`) show the `[FATA]` line that terminated the process:\n```\n[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added\n[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |\n[FATA][NEF][PFDMng] Post \"http://127.0.0.1:1/notify\": dial tcp 127.0.0.1:1: connect: connection refused\n```\n\n### Impact\nReachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied `notifyUri`. `logger.Fatal` is `os.Exit(1)`-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.\n\nIn v4.2.1, the trigger chain is reachable without an `Authorization` header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can:\n- Submit the three-step trigger anonymously and immediately terminate the NEF process.\n- Repeat the trigger after every restart to sustain the outage.\n- Pick any unreachable `notifyUri` (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same `Fatal`, so partial fixes that block one URI do not close the family.\n\nNo Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/924\nUpstream fix: https://github.com/free5gc/nef/pull/25",
  "id": "GHSA-rxrq-fv76-26pr",
  "modified": "2026-06-08T23:47:12Z",
  "published": "2026-05-08T22:44:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-rxrq-fv76-26pr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44319"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/924"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/pull/25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/commit/f110517b1189801950b50668a593398687049074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "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": "free5GC\u0027s NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)"
}

GHSA-RXVX-VX9W-JW3J

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-09-06 00:00
VLAI
Details

eth_get_gso_type in net/eth.c in QEMU 4.2.1 allows guest OS users to trigger an assertion failure. A guest can crash the QEMU process via packet data that lacks a valid Layer 3 protocol.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-27617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-06T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "eth_get_gso_type in net/eth.c in QEMU 4.2.1 allows guest OS users to trigger an assertion failure. A guest can crash the QEMU process via packet data that lacks a valid Layer 3 protocol.",
  "id": "GHSA-rxvx-vx9w-jw3j",
  "modified": "2022-09-06T00:00:28Z",
  "published": "2022-05-24T17:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27617"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00047.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg05731.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201202-0002"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/11/02/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V297-429X-XXGH

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

The TIFFWriteDirectorySec() function in tif_dirwrite.c in LibTIFF through 4.0.9 allows remote attackers to cause a denial of service (assertion failure and application crash) via a crafted file, a different vulnerability than CVE-2017-13726.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-10T02:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The TIFFWriteDirectorySec() function in tif_dirwrite.c in LibTIFF through 4.0.9 allows remote attackers to cause a denial of service (assertion failure and application crash) via a crafted file, a different vulnerability than CVE-2017-13726.",
  "id": "GHSA-v297-429x-xxgh",
  "modified": "2022-05-13T01:48:59Z",
  "published": "2022-05-13T01:48:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10963"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2053"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/07/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3864-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4349"
    },
    {
      "type": "WEB",
      "url": "http://bugzilla.maptools.org/show_bug.cgi?id=2795"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2CQ-8XV3-3VQ4

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

A specifically crafted packet sent by an attacker to EIPStackGroup OpENer EtherNet/IP commits and versions prior to Feb 10, 2021 may result in a denial-of-service condition.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-27500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-12T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A specifically crafted packet sent by an attacker to EIPStackGroup OpENer EtherNet/IP commits and versions prior to Feb 10, 2021 may result in a denial-of-service condition.",
  "id": "GHSA-v2cq-8xv3-3vq4",
  "modified": "2022-05-24T00:01:41Z",
  "published": "2022-05-13T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/EIPStackGroup/OpENer"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-105-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2M7-67CW-FX97

Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2022-12-15 18:30
VLAI
Details

Denial of service in Modem due to reachable assertion in Snapdragon Mobile

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-25689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Denial of service in Modem due to reachable assertion in Snapdragon Mobile",
  "id": "GHSA-v2m7-67cw-fx97",
  "modified": "2022-12-15T18:30:19Z",
  "published": "2022-12-13T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25689"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/december-2022-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)

Mitigation
Implementation

Strategy: Input Validation

Perform input validation on user data.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list