Common Weakness Enumeration

CWE-706

Allowed-with-Review

Use of Incorrectly-Resolved Name or Reference

Abstraction: Class · Status: Incomplete

The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.

189 vulnerabilities reference this CWE, most recent first.

GHSA-4JCH-X64F-4WHQ

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

The IBM Cloud APM 8.1.4 server will issue a DNS request to resolve any hostname specified in the Cloud Event Management Webhook URL configuration definition. This could enable an authenticated user with admin authorization to create DNS query strings that are not hostnames. IBM X-Force ID: 187861.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-02T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The IBM Cloud APM 8.1.4 server will issue a DNS request to resolve any hostname specified in the Cloud Event Management Webhook URL configuration definition. This could enable an authenticated user with admin authorization to create DNS query strings that are not hostnames. IBM X-Force ID: 187861.",
  "id": "GHSA-4jch-x64f-4whq",
  "modified": "2022-05-24T17:43:27Z",
  "published": "2022-05-24T17:43:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4719"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/187861"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6417137"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4MH3-H929-W968

Vulnerability from github – Published: 2026-02-10 00:25 – Updated: 2026-02-10 02:56
VLAI
Summary
File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL
Details

Summary

An authenticated user can bypass the application's "Disallow" file path rules by modifying the request URL. By adding multiple slashes (e.g., //private/) to the path, the authorization check fails to match the rule, while the underlying filesystem resolves the path correctly, granting unauthorized access to restricted files.

Details

The vulnerability allows users to bypass "Disallow" rules defined by administrators.

The issue stems from how the application handles URL path normalization and rule matching:

  1. Router Configuration: The router in http/http.go is configured with r.SkipClean(true). This prevents the automatic collapse of multiple slashes (e.g., // becoming /) before the request reaches the handler.
  2. Insecure Rule Matching: The rule enforcement logic in rules/rules.go relies on a simple string prefix match: strings.HasPrefix(path, r.Path). If a rule disallows /private, a request for //private fails this check because //private does not strictly start with /private.
  3. Filesystem Resolution: After bypassing the rule check, the non-normalized path is passed to the filesystem. The filesystem treats the multiple slashes as a single separator, successfully resolving //private/secret.txt and serving the file.

PoC

Python minimal PoC

The following steps demonstrate the vulnerability: 1. Setup: - Admin user creates a folder /private and adds a file /private/secret.txt. Screenshot_20260123_151608 Screenshot_20260123_151551 - Admin adds a Disallow rule for user bob on the path /private. Screenshot_20260123_151502

  1. Verification:
  2. User bob requests GET /api/resources/private/secret.txt.
  3. Server responds: 403 Forbidden. Screenshot_20260123_154446
  4. Exploit:
  5. User bob requests GET /api/resources//private/secret.txt.
  6. Server responds: 200 OK (Bypass successful). Screenshot_20260123_154544 Screenshot_20260123_154618

Impact

This vulnerability impacts the confidentiality and integrity of data stored in filebrowser. - Confidentiality: Users can read files they are explicitly forbidden from accessing. - Integrity: If the user has general write permissions but is restricted from specific directories via rules, they can bypass these restrictions to rename, delete, or modify files.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.57.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.57.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-10T00:25:17Z",
    "nvd_published_at": "2026-02-09T22:16:03Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn authenticated user can bypass the application\u0027s \"Disallow\" file path rules by modifying the request URL. By adding multiple slashes (e.g., //private/) to the path, the authorization check fails to match the rule, while the underlying filesystem resolves the path correctly, granting unauthorized access to restricted files.\n\n### Details\nThe vulnerability allows users to bypass \"Disallow\" rules defined by administrators.\n\nThe issue stems from how the application handles URL path normalization and rule matching:\n\n1. Router Configuration: The router in `http/http.go` is configured with `r.SkipClean(true)`. This prevents the automatic collapse of multiple slashes (e.g., // becoming /) before the request reaches the handler.\n2. Insecure Rule Matching: The rule enforcement logic in `rules/rules.go` relies on a simple string prefix match: `strings.HasPrefix(path, r.Path)`. If a rule disallows /private, a request for //private fails this check because //private does not strictly start with /private.\n3. Filesystem Resolution: After bypassing the rule check, the non-normalized path is passed to the filesystem. The filesystem treats the multiple slashes as a single separator, successfully resolving //private/secret.txt and serving the file.\n\n### PoC\n[Python minimal PoC](https://github.com/user-attachments/files/24823114/poc.py)\n\nThe following steps demonstrate the vulnerability:\n1. Setup:\n  - Admin user creates a folder /private and adds a file /private/secret.txt.\n\u003cimg width=\"971\" height=\"719\" alt=\"Screenshot_20260123_151608\" src=\"https://github.com/user-attachments/assets/2071c92e-2bbe-46f8-a338-05b0f53d381a\" /\u003e\n\u003cimg width=\"890\" height=\"386\" alt=\"Screenshot_20260123_151551\" src=\"https://github.com/user-attachments/assets/1def540a-de26-4666-a6ab-058d5927bfbe\" /\u003e\n  - Admin adds a Disallow rule for user bob on the path /private.\n\u003cimg width=\"1005\" height=\"1126\" alt=\"Screenshot_20260123_151502\" src=\"https://github.com/user-attachments/assets/e9b57d59-f4ab-41d8-b056-8ffdaa219963\" /\u003e\n\n2. Verification:\n  - User bob requests GET /api/resources/private/secret.txt.\n  - Server responds: 403 Forbidden.\n\u003cimg width=\"1193\" height=\"721\" alt=\"Screenshot_20260123_154446\" src=\"https://github.com/user-attachments/assets/dd092a10-2f8c-4a3c-b48f-d540c483bb5a\" /\u003e\n3. Exploit:\n  - User bob requests GET /api/resources//private/secret.txt.\n  - Server responds: 200 OK (Bypass successful).\n\u003cimg width=\"1193\" height=\"721\" alt=\"Screenshot_20260123_154544\" src=\"https://github.com/user-attachments/assets/27ebb82c-f7c2-467d-ae82-f495ae3aa2d4\" /\u003e\n\u003cimg width=\"1196\" height=\"818\" alt=\"Screenshot_20260123_154618\" src=\"https://github.com/user-attachments/assets/82035884-9a24-490d-b928-7bdd2dbe3193\" /\u003e\n\n\n### Impact\nThis vulnerability impacts the confidentiality and integrity of data stored in filebrowser.\n- Confidentiality: Users can read files they are explicitly forbidden from accessing.\n- Integrity: If the user has general write permissions but is restricted from specific directories via rules, they can bypass these restrictions to rename, delete, or modify files.",
  "id": "GHSA-4mh3-h929-w968",
  "modified": "2026-02-10T02:56:37Z",
  "published": "2026-02-10T00:25:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-4mh3-h929-w968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/489af403a19057f6b6b4b1dc0e48cbb26a202ef9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.57.1"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL"
}

GHSA-5278-2H8H-4P7C

Vulnerability from github – Published: 2025-04-01 06:30 – Updated: 2026-04-01 18:34
VLAI
Details

Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in g5theme Essential Real Estate allows PHP Local File Inclusion. This issue affects Essential Real Estate: from n/a through 5.2.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706",
      "CWE-98"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T06:15:53Z",
    "severity": "HIGH"
  },
  "details": "Improper Control of Filename for Include/Require Statement in PHP Program (\u0027PHP Remote File Inclusion\u0027) vulnerability in g5theme Essential Real Estate allows PHP Local File Inclusion. This issue affects Essential Real Estate: from n/a through 5.2.0.",
  "id": "GHSA-5278-2h8h-4p7c",
  "modified": "2026-04-01T18:34:18Z",
  "published": "2025-04-01T06:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30849"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/essential-real-estate/vulnerability/wordpress-essential-real-estate-plugin-5-2-0-local-file-inclusion-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-527R-MRH4-WX97

Vulnerability from github – Published: 2024-12-17 21:30 – Updated: 2024-12-18 18:30
VLAI
Details

An insecure direct object reference (IDOR) vulnerability was discovered in PHPGurukul Online Birth Certificate System v1.0. This vulnerability resides in the viewid parameter of /user/view-application-detail.php. Authenticated users can exploit this flaw by manipulating the viewid parameter in the URL to access sensitive birth certificate details of other users without proper authorization checks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-55058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-17T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An insecure direct object reference (IDOR) vulnerability was discovered in PHPGurukul Online Birth Certificate System v1.0. This vulnerability resides in the viewid parameter of /user/view-application-detail.php. Authenticated users can exploit this flaw by manipulating the viewid parameter in the URL to access sensitive birth certificate details of other users without proper authorization checks.",
  "id": "GHSA-527r-mrh4-wx97",
  "modified": "2024-12-18T18:30:51Z",
  "published": "2024-12-17T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SCR-athif/CVE/tree/main/CVE-2024-55058"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-52C3-83C9-5H54

Vulnerability from github – Published: 2026-09-15 18:32 – Updated: 2026-09-22 18:33
VLAI
Details

OneNav v1.2.4 contains an authenticated arbitrary file deletion vulnerability in the Api::upload() method in class/Api.php. An authenticated administrator can submit a non-HTML upload filename matching an existing file in the application's working directory. The application passes the user-controlled filename to unlink() when rejecting the upload, potentially causing file deletion and denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-88621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T16:17:39Z",
    "severity": "LOW"
  },
  "details": "OneNav v1.2.4 contains an authenticated arbitrary file deletion vulnerability in the Api::upload() method in class/Api.php. An authenticated administrator can submit a non-HTML upload filename matching an existing file in the application\u0027s working directory. The application passes the user-controlled filename to unlink() when rejecting the upload, potentially causing file deletion and denial of service.",
  "id": "GHSA-52c3-83c9-5h54",
  "modified": "2026-09-22T18:33:15Z",
  "published": "2026-09-15T18:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helloxz/onenav"
    },
    {
      "type": "WEB",
      "url": "https://github.com/returnwrong/returnwrong-security-advisories/blob/main/CVE-2026-88621.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-55XG-H548-PGFP

Vulnerability from github – Published: 2022-11-22 00:30 – Updated: 2022-11-28 18:30
VLAI
Details

An issue was discovered in Technitium DNS Server through 8.0.2 that allows variant V2 of unintended domain name resolution. A revoked domain name can still be resolvable for a long time, including expired domains and taken-down malicious domains. The effects of an exploit would be widespread and highly impactful, because the exploitation conforms to de facto DNS specifications and operational practices, and overcomes current mitigation patches for "Ghost" domain names.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-30258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-21T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Technitium DNS Server through 8.0.2 that allows variant V2 of unintended domain name resolution. A revoked domain name can still be resolvable for a long time, including expired domains and taken-down malicious domains. The effects of an exploit would be widespread and highly impactful, because the exploitation conforms to de facto DNS specifications and operational practices, and overcomes current mitigation patches for \"Ghost\" domain names.",
  "id": "GHSA-55xg-h548-pgfp",
  "modified": "2022-11-28T18:30:16Z",
  "published": "2022-11-22T00:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30258"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md#version-81"
    }
  ],
  "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"
    }
  ]
}

GHSA-568F-PV23-39P4

Vulnerability from github – Published: 2026-09-08 16:37 – Updated: 2026-09-08 16:37
VLAI
Summary
NLTK: Stable FrameNet and NKJP readers parse outside-root XML
Details

Summary

Published nltk==3.9.4 still contains several XML-reader entrypoints that build parser paths from caller-controlled selectors or trusted-looking index state without preserving the corpus-root boundary.

Details

  • Vulnerability type: Path traversal and trusted-root bypass
  • Affected component: FramenetCorpusReader.frame_by_name, FramenetCorpusReader.doc, FramenetCorpusReader.lu, NKJPCorpusReader.header
  • Affected versions: Published 3.9.4 reproduced. Current source v3.10.0-rc2 acted as a negative control and blocked the same payloads.
  • Patched versions: Patched in version 3.10.0, which includes the path-safety rejections seen in the release candidate.
  • Root cause: Stable reader paths still construct raw XML filenames from unsafe selectors, poisoned index state, or unsafe file identifiers.

I confirmed four public stable entrypoints return parsed outside-root content: a parent-segment traversal frame name, a poisoned fulltext index filename, a poisoned LU id, and an unsafe NKJP header file identifier. Current source rejects the same payloads with explicit path-safety errors, which shows the bug is real but version-scoped to the published stable package.

PoC

Preconditions - The application exposes FrameNet or NKJP reader APIs while trusting NLTK to keep XML parsing inside a corpus root.

Steps 1. Create a minimal FrameNet or NKJP corpus root and place attacker-chosen XML files outside that root. 2. Feed unsafe selectors or poisoned index state into the relevant public stable 3.9.4 APIs. 3. Observe frame_by_name, doc, lu(...).exemplars, or header return parsed outside-root values. 4. Run the same payloads against current source and observe explicit path-safety rejections.

Minimal reproducible excerpt

framenet_frame_definition FRAME_LEAK
framenet_doc_text DOC_LEAK
framenet_lu_text LU_LEAK
nkjp_header_title HEADER_LEAK

Impact

Applications that process attacker-influenced FrameNet or NKJP corpus selectors or state can be made to parse XML outside the trusted corpus root through normal public reader responses.

Remediation

Keep these reader paths on the same root-confinement model as CorpusReader.open() and nltk.pathsec. Reject unsafe path components before constructing filenames from frame names, document filenames, LU ids, or NKJP file identifiers.

Resources

  • https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1366-L1369
  • https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1456-L1460
  • https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1803-L1810
  • https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/nkjp.py#L96-L103
  • https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/nkjp.py#L251-L256
  • https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/corpus/reader/framenet.py#L1388-L1399
  • https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/corpus/reader/nkjp.py#L96-L128
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.9.4"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-706",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T16:37:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPublished `nltk==3.9.4` still contains several XML-reader entrypoints that build parser paths from caller-controlled selectors or trusted-looking index state without preserving the corpus-root boundary.\n\n### Details\n\n- **Vulnerability type:** Path traversal and trusted-root bypass\n- **Affected component:** `FramenetCorpusReader.frame_by_name`, `FramenetCorpusReader.doc`, `FramenetCorpusReader.lu`, `NKJPCorpusReader.header`\n- **Affected versions:** Published `3.9.4` reproduced. Current source `v3.10.0-rc2` acted as a negative control and blocked the same payloads.\n- **Patched versions:** Patched in version 3.10.0, which includes the path-safety rejections seen in the release candidate.\n- **Root cause:** Stable reader paths still construct raw XML filenames from unsafe selectors, poisoned index state, or unsafe file identifiers.\n\nI confirmed four public stable entrypoints return parsed outside-root content: a parent-segment traversal frame name, a poisoned fulltext index filename, a poisoned LU id, and an unsafe NKJP header file identifier. Current source rejects the same payloads with explicit path-safety errors, which shows the bug is real but version-scoped to the published stable package.\n\n### PoC\n\n**Preconditions**\n- The application exposes FrameNet or NKJP reader APIs while trusting NLTK to keep XML parsing inside a corpus root.\n\n**Steps**\n1. Create a minimal FrameNet or NKJP corpus root and place attacker-chosen XML files outside that root.\n2. Feed unsafe selectors or poisoned index state into the relevant public stable `3.9.4` APIs.\n3. Observe `frame_by_name`, `doc`, `lu(...).exemplars`, or `header` return parsed outside-root values.\n4. Run the same payloads against current source and observe explicit path-safety rejections.\n\n**Minimal reproducible excerpt**\n\n```text\nframenet_frame_definition FRAME_LEAK\nframenet_doc_text DOC_LEAK\nframenet_lu_text LU_LEAK\nnkjp_header_title HEADER_LEAK\n```\n\n### Impact\n\nApplications that process attacker-influenced FrameNet or NKJP corpus selectors or state can be made to parse XML outside the trusted corpus root through normal public reader responses.\n\n### Remediation\n\nKeep these reader paths on the same root-confinement model as `CorpusReader.open()` and `nltk.pathsec`. Reject unsafe path components before constructing filenames from frame names, document filenames, LU ids, or NKJP file identifiers.\n\n### Resources\n\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1366-L1369\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1456-L1460\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/framenet.py#L1803-L1810\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/nkjp.py#L96-L103\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/corpus/reader/nkjp.py#L251-L256\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/corpus/reader/framenet.py#L1388-L1399\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/corpus/reader/nkjp.py#L96-L128",
  "id": "GHSA-568f-pv23-39p4",
  "modified": "2026-09-08T16:37:18Z",
  "published": "2026-09-08T16:37:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-568f-pv23-39p4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62385"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/pull/3579"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/pull/3581"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/7d1389d0789c1eca56bd0ed444089e0a3972e3ed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/bf3bf32786791394a1008258b4917a7f2d4dbcda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/releases/tag/v3.10.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3728.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-path-traversal-via-framenet-and-nkjp-readers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NLTK: Stable FrameNet and NKJP readers parse outside-root XML"
}

GHSA-57J5-QWP2-VQP6

Vulnerability from github – Published: 2026-04-22 19:43 – Updated: 2026-04-22 19:43
VLAI
Summary
OpenFGA has Improper Policy Enforcement
Details

Description

In OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.

Am I Affected?

Users are affected if their applications meet the following preconditions:

  • The model has relations which rely on condition evaluation.
  • Caching is enabled.

Fix

Upgrade to OpenFGA v1.14.1.

Acknowledgement

OpenFGA would like to thank @bugbunny-research for the detailed report.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T19:43:36Z",
    "nvd_published_at": "2026-04-22T00:16:29Z",
    "severity": "MODERATE"
  },
  "details": "### Description\nIn OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.\n\n### Am I Affected?\nUsers are affected if their applications meet the following preconditions:\n\n* The model has relations which rely on condition evaluation.\n* Caching is enabled.\n\n### Fix\nUpgrade to OpenFGA v1.14.1.\n\n### Acknowledgement\nOpenFGA would like to thank @bugbunny-research for the detailed report.",
  "id": "GHSA-57j5-qwp2-vqp6",
  "modified": "2026-04-22T19:43:36Z",
  "published": "2026-04-22T19:43:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-57j5-qwp2-vqp6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41131"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/releases/tag/v1.14.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenFGA has Improper Policy Enforcement"
}

GHSA-5P55-QCQV-882W

Vulnerability from github – Published: 2026-05-27 21:31 – Updated: 2026-05-27 21:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.7 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that under certain conditions could have allowed an authenticated user to access CI data from a different ref type than intended.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-8716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T19:16:25Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.7 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that under certain conditions could have allowed an authenticated user to access CI data from a different ref type than intended.",
  "id": "GHSA-5p55-qcqv-882w",
  "modified": "2026-05-27T21:31:25Z",
  "published": "2026-05-27T21:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8716"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/05/27/patch-release-gitlab-19-0-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/570059"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5QHG-XGVP-WQ2G

Vulnerability from github – Published: 2026-09-25 00:33 – Updated: 2026-09-25 18:31
VLAI
Details

Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone.

Catalyst::Seal replaces the dispatcher's prepare_action with a version that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from.

A path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running.

The memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-85491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T22:17:02Z",
    "severity": "HIGH"
  },
  "details": "Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone.\n\nCatalyst::Seal replaces the dispatcher\u0027s prepare_action with a version that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from.\n\nA path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running.\n\nThe memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain.",
  "id": "GHSA-5qhg-xgvp-wq2g",
  "modified": "2026-09-25T18:31:21Z",
  "published": "2026-09-25T00:33:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85491"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/LNATION/Catalyst-Seal-0.02/source/lib/Catalyst/Seal/Dispatch.pm#L237-280"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/LNATION/Catalyst-Seal-0.03/changes"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/24/8"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/24/9"
    }
  ],
  "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"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-159: Redirect Access to Libraries

An adversary exploits a weakness in the way an application searches for external libraries to manipulate the execution flow to point to an adversary supplied library or code base. This pattern of attack allows the adversary to compromise the application or server via the execution of unauthorized code. An application typically makes calls to functions that are a part of libraries external to the application. These libraries may be part of the operating system or they may be third party libraries. If an adversary can redirect an application's attempts to access these libraries to other libraries that the adversary supplies, the adversary will be able to force the targeted application to execute arbitrary code. This is especially dangerous if the targeted application has enhanced privileges. Access can be redirected through a number of techniques, including the use of symbolic links, search path modification, and relative path manipulation.

CAPEC-177: Create files with the same name as files protected with a higher classification

An attacker exploits file location algorithms in an operating system or application by creating a file with the same name as a protected or privileged file. The attacker could manipulate the system if the attacker-created file is trusted by the operating system or an application component that attempts to load the original file. Applications often load or include external files, such as libraries or configuration files. These files should be protected against malicious manipulation. However, if the application only uses the name of the file when locating it, an attacker may be able to create a file with the same name and place it in a directory that the application will search before the directory with the legitimate file is searched. Because the attackers' file is discovered first, it would be used by the target application. This attack can be extremely destructive if the referenced file is executable and/or is granted special privileges based solely on having a particular name.

CAPEC-48: Passing Local Filenames to Functions That Expect a URL

This attack relies on client side code to access local files and resources instead of URLs. When the client browser is expecting a URL string, but instead receives a request for a local file, that execution is likely to occur in the browser process space with the browser's authority to local files. The attacker can send the results of this request to the local files out to a site that they control. This attack may be used to steal sensitive authentication data (either local or remote), or to gain system profile information to launch further attacks.

CAPEC-641: DLL Side-Loading

An adversary places a malicious version of a Dynamic-Link Library (DLL) in the Windows Side-by-Side (WinSxS) directory to trick the operating system into loading this malicious DLL instead of a legitimate DLL. Programs specify the location of the DLLs to load via the use of WinSxS manifests or DLL redirection and if they aren't used then Windows searches in a predefined set of directories to locate the file. If the applications improperly specify a required DLL or WinSxS manifests aren't explicit about the characteristics of the DLL to be loaded, they can be vulnerable to side-loading.