CWE-180
AllowedIncorrect Behavior Order: Validate Before Canonicalize
Abstraction: Variant · Status: Draft
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
51 vulnerabilities reference this CWE, most recent first.
GHSA-6XGW-5Q2H-P29F
Vulnerability from github – Published: 2026-08-19 15:32 – Updated: 2026-08-19 15:32Incorrect Behavior Order: Validate Before Canonicalize in the report theme CSS sanitizer in maalfer Pentestify 1.2.0 through 2.3.2 allows an authenticated user to force outbound HTTP requests from other users' browsers, disclosing their IP address and User-Agent, via CSS hex escapes that reconstruct the url() function and evade the sanitizer blocklist
{
"affected": [],
"aliases": [
"CVE-2026-76203"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T15:18:10Z",
"severity": "MODERATE"
},
"details": "Incorrect Behavior Order: Validate Before Canonicalize in the report theme CSS sanitizer\nin maalfer Pentestify 1.2.0 through 2.3.2 allows an authenticated user to force outbound\nHTTP requests from other users\u0027 browsers, disclosing their IP address and User-Agent, via\nCSS hex escapes that reconstruct the url() function and evade the sanitizer blocklist",
"id": "GHSA-6xgw-5q2h-p29f",
"modified": "2026-08-19T15:32:39Z",
"published": "2026-08-19T15:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76203"
},
{
"type": "WEB",
"url": "https://github.com/ccyl13/Pentestify/commit/1ed1aadadb02e959af470aac9958462048f7f5f5"
},
{
"type": "WEB",
"url": "https://secur0.com/en/cna/cve-list/cve-2026-76203-css-sanitizer-bypass-pentestify-report-themes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7JMW-8259-Q9JX
Vulnerability from github – Published: 2024-06-11 19:29 – Updated: 2024-06-17 15:28Impact
There is a vulnerability in Go managing various Is methods (IsPrivate, IsLoopback, etc) for IPv4-mapped IPv6 addresses.
They didn't work as expected returning false for addresses which would return true in their traditional IPv4 forms.
References
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.4
- https://github.com/traefik/traefik/releases/tag/v3.0.2
Workarounds
No workaround.
For more information
If you have any questions or comments about this advisory, please open an issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta3"
},
{
"fixed": "3.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-11T19:29:43Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThere is a vulnerability in [Go managing various Is methods (IsPrivate, IsLoopback, etc) for IPv4-mapped IPv6 addresses](https://groups.google.com/g/golang-announce/c/XbxouI9gY7k/m/TuoGEhxIEwAJ).\n\nThey didn\u0027t work as expected returning false for addresses which would return true in their traditional IPv4 forms.\n\n### References\n\n- [CVE-2024-24790](https://www.cve.org/CVERecord?id=CVE-2024-24790)\n\n### Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.4\n- https://github.com/traefik/traefik/releases/tag/v3.0.2\n\n### Workarounds\n\nNo workaround.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).",
"id": "GHSA-7jmw-8259-q9jx",
"modified": "2024-06-17T15:28:38Z",
"published": "2024-06-11T19:29:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-7jmw-8259-q9jx"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.4"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.0.2"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2917"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24790"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Traefik has unexpected behavior with IPv4-mapped IPv6 addresses"
}
GHSA-7RQJ-J65F-68WH
Vulnerability from github – Published: 2026-07-23 14:40 – Updated: 2026-08-12 20:27Summary
The default email-address normalizer used by the email/magic-link sign-in flow validates the address before applying Unicode normalization. An address can contain a Unicode character that is not an ASCII @ (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-@ check, but a downstream mail library that normalizes the string then sees two @ separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.
Am I affected?
You may be affected if all of the following hold:
- You use
next-auth>= 4.0.0, < 4.24.14, or@auth/core>= 0.1.0, < 0.41.3. - You have the email / magic-link (passwordless) provider enabled.
- You rely on the built-in default identifier normalizer (you have not supplied your own
normalizeIdentifier). - Your
sendVerificationRequestimplementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).
You are not affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.
Impact
- Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.
- No victim interaction is required to misroute the link; the attacker initiates the flow.
Patched version
The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.
Workarounds
If you cannot upgrade immediately:
- Supply a custom
normalizeIdentifieron the email provider that callsidentifier.normalize("NFKC")(and lower-cases/trims) before any validation, and rejects addresses that do not contain exactly one@after normalization. - Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.
Credit
Reported by @kakashi-kx. Thank you for the responsible disclosure.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@auth/core"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "0.41.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "4.10.3"
},
{
"fixed": "4.24.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.0-beta.32"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73420"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T14:40:15Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer\u0027s single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003e= 4.0.0, \u003c 4.24.14`, or `@auth/core` `\u003e= 0.1.0, \u003c 0.41.3`.\n- You have the email / magic-link (passwordless) provider enabled.\n- You rely on the built-in default identifier normalizer (you have not supplied your own `normalizeIdentifier`).\n- Your `sendVerificationRequest` implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).\n\nYou are **not** affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.\n\n## Impact\n\n- Account takeover: an attacker who knows a victim\u0027s email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.\n- No victim interaction is required to misroute the link; the attacker initiates the flow.\n\n## Patched version\n\nThe fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- Supply a custom `normalizeIdentifier` on the email provider that calls `identifier.normalize(\"NFKC\")` (and lower-cases/trims) **before** any validation, and rejects addresses that do not contain exactly one `@` after normalization.\n- Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.\n\n## Credit\n\nReported by @kakashi-kx. Thank you for the responsible disclosure.",
"id": "GHSA-7rqj-j65f-68wh",
"modified": "2026-08-12T20:27:03Z",
"published": "2026-07-23T14:40:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0"
},
{
"type": "PACKAGE",
"url": "https://github.com/nextauthjs/next-auth"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass"
}
GHSA-86P5-CMGC-C94W
Vulnerability from github – Published: 2026-07-24 09:32 – Updated: 2026-07-24 09:32In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router.
The shared router configuration used Chi's middleware.StripSlashes, so a request such as GET /shells/ was dispatched to the registered GET /shells route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters.
An unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations.
The issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.
{
"affected": [],
"aliases": [
"CVE-2026-15704"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T09:16:24Z",
"severity": "CRITICAL"
},
"details": "In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router.\n\n\n\nThe shared router configuration used Chi\u0027s `middleware.StripSlashes`, so a request such as `GET /shells/` was dispatched to the registered `GET /shells` route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters.\n\n\n\nAn unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations.\n\n\n\nThe issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.",
"id": "GHSA-86p5-cmgc-c94w",
"modified": "2026-07-24T09:32:16Z",
"published": "2026-07-24T09:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15704"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-basyx/basyx-go-components/pull/442"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-basyx/basyx-go-components/releases/tag/v1.0.1"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/164"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/580"
}
],
"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-89VP-JRXV-24W8
Vulnerability from github – Published: 2026-07-22 23:14 – Updated: 2026-08-12 19:56JupyterLab's PyPI extension manager enforces blocked_extensions_uris by comparing the requested install name to blocklist entries with a custom string normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as JupyterLab.Git for a blocklisted package such as jupyterlab-git; JupyterLab accepts the install request even though pip resolves the variant to the same package.
This has security implications only for deployments that combine all of the following: - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI Extension Manager enabled; and - kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can install packages directly regardless of this check)
Impact
The vulnerability lets an authenticated user install a package the operator specifically intended to block, defeating the allowlist/blocklist control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server's data, so installing an extension grants no new read access.
In particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod's resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.
Patches
JupyterLab v4.6.2 and v4.5.10 contain the patch.
Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.
Workarounds
No action is required for deployments that do not have a custom allow/block list configured. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:
--LabApp.extension_manager=readonly
or the following traitlet:
c.LabApp.extension_manager = 'readonly'
You can confirm that the read-only manager is in use from GUI:
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.1"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "4.6.0"
},
{
"fixed": "4.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.9"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "4.5.0"
},
{
"fixed": "4.5.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73416"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T23:14:27Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "JupyterLab\u0027s PyPI extension manager enforces `blocked_extensions_uris` by comparing the requested install name to blocklist entries with a custom string normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as `JupyterLab.Git` for a blocklisted package such as `jupyterlab-git`; JupyterLab accepts the install request even though pip resolves the variant to the same package.\n\nThis has security implications only for deployments that combine all of the following:\n- an allowlist/blocklist configured with the intent of restricting which packages users can install;\n- the (default) PyPI Extension Manager enabled; and\n- kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can install packages directly regardless of this check) \n\n### Impact\n\nThe vulnerability lets an authenticated user install a package the operator specifically intended to block, defeating the allowlist/blocklist control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server\u0027s data, so installing an extension grants no new read access.\n\nIn particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod\u0027s resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.\n\n### Patches\n\nJupyterLab [`v4.6.2`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10) contain the patch.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nNo action is required for deployments that do not have a custom allow/block list configured. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:\n\n```bash\n--LabApp.extension_manager=readonly\n```\n\nor the following traitlet:\n\n```python\nc.LabApp.extension_manager = \u0027readonly\u0027\n```\n\nYou can confirm that the read-only manager is in use from GUI:\n\n\u003cimg width=\"293\" height=\"293\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f\" /\u003e",
"id": "GHSA-89vp-jrxv-24w8",
"modified": "2026-08-12T19:56:08Z",
"published": "2026-07-22T23:14:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-89vp-jrxv-24w8"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19184"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19185"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19186"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyterlab/jupyterlab"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "JupyterLab: PyPI extension blocklist package-name canonicalization bypass"
}
GHSA-8PVW-JCV7-9CMJ
Vulnerability from github – Published: 2026-07-24 16:43 – Updated: 2026-07-24 16:43Impact
@fastify/static evaluates the allowedPath callback before normalizing dot segments and duplicate slashes in the pathname used for file resolution. Non-canonical pathnames such as //file, /./file, or /public/../private/file bypass allowedPath filtering while resolving to the intended file on disk.
Applications that use allowedPath as a security boundary to restrict access to specific static files or path subtrees may unintentionally expose files that were intended to be denied.
Patches
Upgrade to @fastify/static >= 10.1.2.
Workarounds
None. Upgrade to the patched version.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.1.1"
},
"package": {
"ecosystem": "npm",
"name": "@fastify/static"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-7120"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:43:44Z",
"nvd_published_at": "2026-07-23T04:16:33Z",
"severity": "MODERATE"
},
"details": "### Impact\n\n`@fastify/static` evaluates the `allowedPath` callback before normalizing dot segments and duplicate slashes in the pathname used for file resolution. Non-canonical pathnames such as `//file`, `/./file`, or `/public/../private/file` bypass `allowedPath` filtering while resolving to the intended file on disk.\n\nApplications that use `allowedPath` as a security boundary to restrict access to specific static files or path subtrees may unintentionally expose files that were intended to be denied.\n\n### Patches\n\nUpgrade to `@fastify/static` \u003e= 10.1.2.\n\n### Workarounds\n\nNone. Upgrade to the patched version.",
"id": "GHSA-8pvw-jcv7-9cmj",
"modified": "2026-07-24T16:43:44Z",
"published": "2026-07-24T16:43:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-static/security/advisories/GHSA-8pvw-jcv7-9cmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7120"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-static/commit/878c72e920fabacf7e37739bf78057044717bf63"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/fastify/fastify-static"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-static/releases/tag/v10.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@fastify/static vulnerable to Authorization Bypass via Non-Canonical URL Paths"
}
GHSA-8R66-VG6C-X88H
Vulnerability from github – Published: 2025-11-25 18:32 – Updated: 2025-11-25 18:32NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper processing of input data. A successful exploit of this vulnerability might lead to information disclosure or denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-33194"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-25T18:15:51Z",
"severity": "MODERATE"
},
"details": "NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper processing of input data. A successful exploit of this vulnerability might lead to information disclosure or denial of service.",
"id": "GHSA-8r66-vg6c-x88h",
"modified": "2025-11-25T18:32:22Z",
"published": "2025-11-25T18:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33194"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5720"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33194"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-92H7-Q9M9-98H8
Vulnerability from github – Published: 2025-04-23 15:30 – Updated: 2025-04-23 15:30A directory traversal vulnerability exists in Ivanti LANDesk Management Gateway through 4.2-1.9. By appending %3F.php to the URI of the /client/index.php endpoint, an attacker can bypass access controls and gain unauthorized access to various endpoints such as /client/index.php%3F.php/gsb/firewall.php within the management web panel, potentially exposing sensitive device information. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [],
"aliases": [
"CVE-2025-43716"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-23T14:15:29Z",
"severity": "MODERATE"
},
"details": "A directory traversal vulnerability exists in Ivanti LANDesk Management Gateway through 4.2-1.9. By appending %3F.php to the URI of the /client/index.php endpoint, an attacker can bypass access controls and gain unauthorized access to various endpoints such as /client/index.php%3F.php/gsb/firewall.php within the management web panel, potentially exposing sensitive device information. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
"id": "GHSA-92h7-q9m9-98h8",
"modified": "2025-04-23T15:30:57Z",
"published": "2025-04-23T15:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43716"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/Graphical-overview-of-the-LANDesk-Management-Gateway-Functionality"
},
{
"type": "WEB",
"url": "https://medium.com/@0xbytehunter/discovery-of-path-traversal-vulnerability-in-landesk-management-gateway-devices-6dba386dd290"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-94VH-GPHV-8PM8
Vulnerability from github – Published: 2025-03-17 21:26 – Updated: 2025-03-19 15:51Summary
In the archive extraction routine of affected versions of the zip crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.
Details
This is a variant of the zip-slip vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.
The documentation of the [::zip::read::ZipArchive::extract] method is in my opinion implying this should not happen:
"Paths are sanitized with ZipFile::enclosed_name." ... [
::zip::read::FileOptions::enclosed_name] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.
Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.
PoC
https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85
Impact
Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.
- zip::unstable::stream::ZipStreamReader::extract
- zip::read::ZipArchive::extract
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "zip"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29787"
],
"database_specific": {
"cwe_ids": [
"CWE-180",
"CWE-22",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-17T21:26:32Z",
"nvd_published_at": "2025-03-17T14:15:22Z",
"severity": "HIGH"
},
"details": "### Summary\n\n\nIn the archive extraction routine of affected versions of the `zip` crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.\n\n### Details\n\nThis is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.\n\nThe documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:\n\n\u003e \"Paths are sanitized with ZipFile::enclosed_name.\" ...\n\u003e [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can\u2019t resolve to a path outside the current directory.\n\n\nMost archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.\n\n### PoC\n\nhttps://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85\n\n### Impact\n\nUsers who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.\n\n- zip::unstable::stream::ZipStreamReader::extract\n- zip::read::ZipArchive::extract",
"id": "GHSA-94vh-gphv-8pm8",
"modified": "2025-03-19T15:51:04Z",
"published": "2025-03-17T21:26:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/security/advisories/GHSA-94vh-gphv-8pm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29787"
},
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/commit/a2e062f37066c3b12860a32eb1cb44856cfb7afe"
},
{
"type": "WEB",
"url": "https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85"
},
{
"type": "PACKAGE",
"url": "https://github.com/zip-rs/zip2"
},
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/releases/tag/v2.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write"
}
GHSA-9RFG-V8G9-9367
Vulnerability from github – Published: 2026-05-26 23:38 – Updated: 2026-06-11 13:30As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.
Summary
An attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.
Details
The vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.
One of the issues is that by taking a signed Activity with an embedded object, an attacker can move the top-level Activity to a @graph property and move the activity's object to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of { "type": "Undo", "object": { "type": "Announce" } }, but other implementations may sign other activities that can be exploited in the same way.
The @reverse keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an Activity and its object.
Another problematic feature is @included, which can be used to “move” properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed Create or Update activity is received.
Given that we have seen no use of @graph, @included or @reverse in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that “normalize” @included and @reverse are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.
Detection of @graph, @included and @reverse should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.
Additionally, after a quick scan of Fedify's source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.
Impact
The impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.
The @included keyword allows “removing” arbitrary attributes, thus allowing replaying Create and Update activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.
The @graph and @reverse keywords allow changing the root activity, which in the case of Mastodon allows sending an Announce from a Undo { Announce }, but might have wider consequences depending on what various servers sign.
The lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor's inbox).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42462"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-180",
"CWE-347",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-26T23:38:37Z",
"nvd_published_at": "2026-06-10T22:16:57Z",
"severity": "HIGH"
},
"details": "As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.\n\n### Summary\n\nAn attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.\n\n### Details\n\nThe vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.\n\nOne of the issues is that by taking a signed `Activity` with an embedded `object`, an attacker can move the top-level `Activity` to a `@graph` property and move the activity\u0027s `object` to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of `{ \"type\": \"Undo\", \"object\": { \"type\": \"Announce\" } }`, but other implementations may sign other activities that can be exploited in the same way.\n\nThe `@reverse` keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an `Activity` and its `object`.\n\nAnother problematic feature is `@included`, which can be used to \u201cmove\u201d properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed `Create` or `Update` activity is received.\n\nGiven that we have seen no use of `@graph`, `@included` or `@reverse` in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that \u201cnormalize\u201d `@included` and `@reverse` are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.\n\nDetection of `@graph`, `@included` and `@reverse` should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.\n\nAdditionally, after a quick scan of Fedify\u0027s source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.\n\n### Impact\n\nThe impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.\n\nThe `@included` keyword allows \u201cremoving\u201d arbitrary attributes, thus allowing replaying `Create` and `Update` activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.\n\nThe `@graph` and `@reverse` keywords allow changing the root activity, which in the case of Mastodon allows sending an `Announce` from a `Undo { Announce }`, but might have wider consequences depending on what various servers sign.\n\nThe lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor\u0027s `inbox`).",
"id": "GHSA-9rfg-v8g9-9367",
"modified": "2026-06-11T13:30:30Z",
"published": "2026-05-26T23:38:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42462"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedify-dev/fedify"
},
{
"type": "WEB",
"url": "https://github.com/fedify-dev/fedify/releases/tag/2.2.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring"
}
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CAPEC-267: Leverage Alternate Encoding
An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.
CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic
This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.