CWE-706
Allowed-with-ReviewUse 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.
148 vulnerabilities reference this CWE, most recent first.
GHSA-J3RW-FX6G-Q46J
Vulnerability from github – Published: 2025-12-02 21:10 – Updated: 2025-12-02 21:10Impact
In Apptainer versions less than 1.4.5, a container can disable two of the forms of the little used --security option, in particular the forms --security=apparmor:<profile> and --security=selinux:<label> which otherwise put restrictions on operations that containers can do. The --security option has always been mentioned in Apptainer documentation as being a feature for the root user, although these forms do also work for unprivileged users on systems where the corresponding feature is enabled. Apparmor is enabled by default on Debian-based distributions and SElinux is enabled by default on RHEL-based distributions, but on SUSE it depends on the distribution version.
In addition, a bug in the detection of selinux support in Apptainer's suid mode means that --security selinux:<label> flags may not be applied, even in the absence of an attack. In that case a warning message is emitted indicating that selinux is unavailable, but the warning may be may be overlooked, mis-interpreted, or not seen when apptainer is run from a script or other tool. Failure to apply requested restrictions should result in a fatal error rather than just a warning message.
Patches
Ineffective write of selinux process labels is addressed via an update to the containers/selinux dependency in https://github.com/apptainer/apptainer/pull/3226. That update brings in the upstream fix for https://github.com/advisories/GHSA-cgrx-mc8f-2prm which was for a different but related vulnerability.
Ineffective write of apparmor process profiles is addressed in commit 4313b42.
Failure to detect apparmor / selinux support, when --security flags are provided, is made an error rather than a warning in commit 82f1790.
Workarounds
There are no known workarounds, other than to define system-wide apparmor / selinux policy for Apptainer itself. This would apply to all containers, not just those run with the --security flags, and could impact the operation of Apptainer itself.
References
Thanks to Sylabs for finding this issue, fixing it in https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87 which was easy to import into Apptainer, and disclosing it early to the Apptainer project for a coordinated release.
The related upstream runc disclosure which inspired the investigation is https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/apptainer/apptainer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65105"
],
"database_specific": {
"cwe_ids": [
"CWE-61",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-02T21:10:04Z",
"nvd_published_at": "2025-12-02T18:15:48Z",
"severity": "MODERATE"
},
"details": "### Impact\nIn Apptainer versions less than 1.4.5, a container can disable two of the forms of the little used `--security` option, in particular the forms `--security=apparmor:\u003cprofile\u003e` and `--security=selinux:\u003clabel\u003e` which otherwise put restrictions on operations that containers can do. The `--security` option has always been mentioned in Apptainer documentation as being a feature for the root user, although these forms do also work for unprivileged users on systems where the corresponding feature is enabled. Apparmor is enabled by default on Debian-based distributions and SElinux is enabled by default on RHEL-based distributions, but on SUSE it depends on the distribution version.\n\nIn addition, a bug in the detection of selinux support in Apptainer\u0027s suid mode means that `--security selinux:\u003clabel\u003e` flags may not be applied, even in the absence of an attack. In that case a warning message is emitted indicating that selinux is unavailable, but the warning may be may be overlooked, mis-interpreted, or not seen when apptainer is run from a script or other tool. Failure to apply requested restrictions should result in a fatal error rather than just a warning message.\n\n### Patches\nIneffective write of selinux process labels is addressed via an update to the containers/selinux dependency in https://github.com/apptainer/apptainer/pull/3226. That update brings in the upstream fix for https://github.com/advisories/GHSA-cgrx-mc8f-2prm which was for a different but related vulnerability.\n\nIneffective write of apparmor process profiles is addressed in commit 4313b42.\n\nFailure to detect apparmor / selinux support, when --security flags are provided, is made an error rather than a warning in commit 82f1790.\n\n### Workarounds\nThere are no known workarounds, other than to define system-wide apparmor / selinux policy for Apptainer itself. This would apply to all containers, not just those run with the `--security` flags, and could impact the operation of Apptainer itself.\n\n### References\nThanks to Sylabs for finding this issue, fixing it in https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87 which was easy to import into Apptainer, and disclosing it early to the Apptainer project for a coordinated release.\n\nThe related upstream runc disclosure which inspired the investigation is https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm.",
"id": "GHSA-j3rw-fx6g-q46j",
"modified": "2025-12-02T21:10:04Z",
"published": "2025-12-02T21:10:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apptainer/apptainer/security/advisories/GHSA-j3rw-fx6g-q46j"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm"
},
{
"type": "WEB",
"url": "https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65105"
},
{
"type": "WEB",
"url": "https://github.com/apptainer/apptainer/pull/3226"
},
{
"type": "WEB",
"url": "https://github.com/apptainer/apptainer/commit/4313b42717e18a4add7dd7503528bc15af905981"
},
{
"type": "WEB",
"url": "https://github.com/apptainer/apptainer/commit/82f17900a0c31bc769bf9b4612d271c7068d8bf2"
},
{
"type": "PACKAGE",
"url": "https://github.com/apptainer/apptainer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Apptainer ineffectively applies selinux and apparmor --security options"
}
GHSA-J623-H46R-V5WR
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02Firely/Incendi Spark before 1.5.5-r4 lacks Content-Disposition headers in certain situations, which may cause crafted files to be delivered to clients such that they are rendered directly in a victim's web browser.
{
"affected": [],
"aliases": [
"CVE-2021-32054"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-14T21:15:00Z",
"severity": "MODERATE"
},
"details": "Firely/Incendi Spark before 1.5.5-r4 lacks Content-Disposition headers in certain situations, which may cause crafted files to be delivered to clients such that they are rendered directly in a victim\u0027s web browser.",
"id": "GHSA-j623-h46r-v5wr",
"modified": "2022-05-24T19:02:25Z",
"published": "2022-05-24T19:02:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32054"
},
{
"type": "WEB",
"url": "https://github.com/FirelyTeam/spark/commit/9c79320059f92d8aa4fbd6cc4fa8f9d5d6ba9941"
},
{
"type": "WEB",
"url": "https://github.com/FirelyTeam/spark/compare/v1.5.4-r4...v1.5.5-r4"
},
{
"type": "WEB",
"url": "https://github.com/FirelyTeam/spark/releases/tag/v1.5.5-r4"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JP82-JPQV-5VV3
Vulnerability from github – Published: 2026-06-15 20:38 – Updated: 2026-06-15 20:38Summary
In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host.
Details
When a client requests a path that does not start with /:
GET @google.com HTTP/1.1
Host: localhost
affected versions reconstruct the URL as http://localhost@google.com. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path:
request.url == "http://localhost@google.com"
request.url.hostname == "google.com"
request.url.path == ""
The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host header was validated when constructing request.url; the path was not.
This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"].
Impact
Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first.
Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers.
Mitigation
Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@google.com with request.url.hostname == "localhost".
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Starlette"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54282"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:38:08Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nIn affected versions, the HTTP request path is not validated before being used to reconstruct `request.url`. Because `request.url` is rebuilt by concatenating `{scheme}://{host}{path}` and re-parsing the result, a path that does not begin with `/` (for example `@google.com`) moves the authority boundary during re-parsing, so `request.url.hostname` and `request.url.netloc` become attacker-controlled. Code that reads `request.url.hostname` (rather than the `Host` header or `scope`) can therefore be misled into trusting an attacker-supplied host.\n\n### Details\n\nWhen a client requests a path that does not start with `/`:\n\n```http\nGET @google.com HTTP/1.1\nHost: localhost\n```\n\naffected versions reconstruct the URL as `http://localhost@google.com`. Per [RFC 3986 \u00a73.2.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.1), the substring before `@` in the authority is `userinfo`, so re-parsing yields `username = \"localhost\"` and `hostname = \"google.com\"`, with an empty path:\n\n```text\nrequest.url == \"http://localhost@google.com\"\nrequest.url.hostname == \"google.com\"\nrequest.url.path == \"\"\n```\n\nThe root cause is that the path is concatenated directly after the host without a separating `/`, and without validating that it begins with one. Only the `Host` header was validated when constructing `request.url`; the path was not.\n\nThis requires an ASGI server that forwards a request-target lacking a leading `/` into `scope[\"path\"]`.\n\n### Impact\n\nAny application running an affected version that uses `request.url`, `request.url.netloc`, or `request.url.hostname` for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first.\n\nNote that this is less exploitable than [GHSA-86qp-5c8j-p5mr](https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr): there, the poison is carried in the `Host` header, so the real path still routes to a valid endpoint while `request.url.path` lies. Here, the poison must be carried in the path itself, and that path (`@google.com`) does not match any registered route, so routing returns `404` and no endpoint handler runs. The exposure is limited to code that reads `request.url` before routing - notably middleware - or in 404/exception handlers.\n\n### Mitigation\n\nUpgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields `http://localhost/@google.com` with `request.url.hostname == \"localhost\"`.",
"id": "GHSA-jp82-jpqv-5vv3",
"modified": "2026-06-15T20:38:09Z",
"published": "2026-06-15T20:38:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Kludex/starlette/security/advisories/GHSA-jp82-jpqv-5vv3"
},
{
"type": "PACKAGE",
"url": "https://github.com/Kludex/starlette"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname"
}
GHSA-JQ57-3W7P-VWVV
Vulnerability from github – Published: 2024-02-29 22:14 – Updated: 2024-03-21 18:25Impact
The vulnerability allows attackers to gain unauthorized access to information on the system through URL manipulation. It affects versions 1.4.53 to 1.4.96.
Patches
The vulnerability has been patched in version 1.4.97 of the master branch. The Docker image on docker.io has been patched.
Workarounds
If upgrading is not possible, manually apply the changes of 97f77dc and restart the server.
Credit
The vulnerability was discovered by Riyush Ghimire (@richighimi).
For more information
If you have any questions or comments about this advisory:
- Open an issue in docassemble
- Join the Slack channel
- Email us at jhpyle@gmail.com
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "docassemble.webapp"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.53"
},
{
"fixed": "1.4.97"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "docassemble.base"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.53"
},
{
"fixed": "1.4.97"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-27292"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-29T22:14:46Z",
"nvd_published_at": "2024-03-21T02:52:19Z",
"severity": "HIGH"
},
"details": "### Impact\nThe vulnerability allows attackers to gain unauthorized access to information on the system through URL manipulation. It affects versions 1.4.53 to 1.4.96.\n\n### Patches\nThe vulnerability has been patched in version 1.4.97 of the master branch. The Docker image on docker.io has been patched.\n\n### Workarounds\nIf upgrading is not possible, manually apply the changes of [97f77dc](https://github.com/jhpyle/docassemble/commit/97f77dc486a26a22ba804765bfd7058aabd600c9) and restart the server.\n\n### Credit\n\nThe vulnerability was discovered by Riyush Ghimire (@richighimi).\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [docassemble](https://github.com/jhpyle/docassemble/issues)\n* Join the [Slack channel](https://join.slack.com/t/docassemble/shared_invite/zt-2cspzjo9j-YyE7SrLmi5muAvnPv~Bz~A)\n* Email us at jhpyle@gmail.com",
"id": "GHSA-jq57-3w7p-vwvv",
"modified": "2024-03-21T18:25:22Z",
"published": "2024-02-29T22:14:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhpyle/docassemble/security/advisories/GHSA-jq57-3w7p-vwvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27292"
},
{
"type": "WEB",
"url": "https://github.com/jhpyle/docassemble/commit/97f77dc486a26a22ba804765bfd7058aabd600c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/jhpyle/docassemble"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Docassemble unauthorized access through URL manipulation"
}
GHSA-JQ74-8PV3-P93C
Vulnerability from github – Published: 2022-05-24 17:16 – Updated: 2022-05-24 17:16An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. checkout.c mishandles equivalent filenames that exist because of NTFS short names. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1353.
{
"affected": [],
"aliases": [
"CVE-2020-12279"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-27T17:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. checkout.c mishandles equivalent filenames that exist because of NTFS short names. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1353.",
"id": "GHSA-jq74-8pv3-p93c",
"modified": "2022-05-24T17:16:36Z",
"published": "2022-05-24T17:16:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/git/git/security/advisories/GHSA-589j-mmg9-733v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12279"
},
{
"type": "WEB",
"url": "https://github.com/libgit2/libgit2/commit/64c612cc3e25eff5fb02c59ef5a66ba7a14751e4"
},
{
"type": "WEB",
"url": "https://github.com/libgit2/libgit2/releases/tag/v0.28.4"
},
{
"type": "WEB",
"url": "https://github.com/libgit2/libgit2/releases/tag/v0.99.0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/03/msg00031.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00034.html"
}
],
"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-M48X-5WVQ-WMQG
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-04-04 02:25A file-rename filter bypass exists in admin/media/rename.php in WBCE CMS 1.4.0 and earlier. This can be exploited by an authenticated user with admin privileges to rename a media filename and extension. (For example: place PHP code in a .jpg file, and then change the file's base name to filename.ph and change the file's extension to p. Because of concatenation, the name is then treated as filename.php.) At the result, remote attackers can execute arbitrary PHP code.
{
"affected": [],
"aliases": [
"CVE-2019-17575"
],
"database_specific": {
"cwe_ids": [
"CWE-706",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-14T15:15:00Z",
"severity": "HIGH"
},
"details": "A file-rename filter bypass exists in admin/media/rename.php in WBCE CMS 1.4.0 and earlier. This can be exploited by an authenticated user with admin privileges to rename a media filename and extension. (For example: place PHP code in a .jpg file, and then change the file\u0027s base name to filename.ph and change the file\u0027s extension to p. Because of concatenation, the name is then treated as filename.php.) At the result, remote attackers can execute arbitrary PHP code.",
"id": "GHSA-m48x-5wvq-wmqg",
"modified": "2024-04-04T02:25:56Z",
"published": "2022-05-24T16:58:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17575"
},
{
"type": "WEB",
"url": "https://github.com/kbgsft/vuln-wbce/wiki/Arbitrary-file-upload-vulnerbility-in-WBCE-CMS-1.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M8CJ-QF2V-5G2Q
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-06-26 21:32Incorrect link resolution by display name in the custom PowerShell VPN editor in Devolutions Remote Desktop Manager 2026.2.5 through 2026.2.11 allows an authenticated attacker with write access to a shared workspace to execute a PowerShell script in another user's context via a display name collision with an existing VPN script link.
{
"affected": [],
"aliases": [
"CVE-2026-13372"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T19:16:39Z",
"severity": "HIGH"
},
"details": "Incorrect link resolution by display name in the custom PowerShell VPN editor in Devolutions Remote Desktop Manager 2026.2.5 through 2026.2.11 allows an authenticated attacker with write access to a shared workspace to execute a PowerShell script in another user\u0027s context via a display name collision with an existing VPN script link.",
"id": "GHSA-m8cj-qf2v-5g2q",
"modified": "2026-06-26T21:32:15Z",
"published": "2026-06-26T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13372"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2026-0021"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MFX7-67R8-JCFR
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2022-07-26 00:01A vulnerability was found in Apache HTTP Server 2.4.0 to 2.4.38. When the path component of a request URL contains multiple consecutive slashes ('/'), directives such as LocationMatch and RewriteRule must account for duplicates in regular expressions while other aspects of the servers processing will implicitly collapse them.
{
"affected": [],
"aliases": [
"CVE-2019-0220"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-11T21:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Apache HTTP Server 2.4.0 to 2.4.38. When the path component of a request URL contains multiple consecutive slashes (\u0027/\u0027), directives such as LocationMatch and RewriteRule must account for duplicates in regular expressions while other aspects of the servers processing will implicitly collapse them.",
"id": "GHSA-mfx7-67r8-jcfr",
"modified": "2022-07-26T00:01:02Z",
"published": "2022-05-24T16:47:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0220"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re473305a65b4db888e3556e4dae10c2a04ee89dcff2e26ecdbd860a9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/04/msg00008.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ALIR5S3O7NRHEGFMIDMUSYQIZOE4TJJN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EZRMTEIGZKYFNGIDOTXN3GNEJTLVCYU7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WETXNQWNQLWHV6XNW6YTO5UGDTIWAQGT"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Apr/5"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190625-0007"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K44591505"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03950en_us"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3937-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4422"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2343"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3436"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4126"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0250"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0251"
},
{
"type": "WEB",
"url": "https://httpd.apache.org/security/vulnerabilities_24.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r03ee478b3dda3e381fd6189366fa7af97c980d2f602846eef935277d@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r06f0d87ebb6d59ed8379633f36f72f5b1f79cadfda72ede0830b42cf@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r31f46d1f16ffcafa68058596b21f6eaf6d352290e522690a1cdccdd7@%3Cbugs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r76142b8c5119df2178be7c2dba88fde552eedeec37ea993dfce68d1d@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd2fb621142e7fa187cfe12d7137bf66e7234abcbbcd800074c84a538@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd336919f655b7ff309385e34a143e41c503e133da80414485b3abcc9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00051.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00061.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00084.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/02/6"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107670"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P36Q-Q72M-GCHR
Vulnerability from github – Published: 2026-03-26 16:52 – Updated: 2026-03-27 21:11Summary
A pathname parsing discrepancy in srvx's FastURL allows middleware bypass on the Node.js adapter when a raw HTTP request uses an absolute URI with a non-standard scheme (e.g. file://).
Details
When Node.js receives an absolute URI in the request line (e.g. GET file://hehe?/internal/run HTTP/1.1), req.url is set verbatim to file://hehe?/internal/run. Since this doesn't start with /, NodeRequestURL passes it directly to FastURL as a string, which stores it in #href for lazy manual parsing.
FastURL#getPos() locates the pathname by finding :// then scanning for the next / — but this fails for URLs like file://hehe?/internal/run where a ? appears before the first / after the authority. The manual parser extracts pathname as /internal/run, while native URL correctly parses it as pathname / with search ?/internal/run.
This discrepancy means the router (using the fast-path) matches /internal/run, but if any middleware triggers a deopt to native URL (e.g. by accessing hostname), subsequent middleware sees a different pathname — bypassing route-based middleware guards.
This is a bypass of CVE-2026-33131.
Impact
Route-based middleware (auth guards, rate limiters, etc.) can be bypassed on the Node.js adapter when a prior middleware triggers FastURL deopt. Requires sending a raw HTTP request (not possible from browsers).
Fix
srvx FastURL constructor now deopts to native URL for any string not starting with /, ensuring consistent pathname resolution.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "srvx"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33732"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T16:52:08Z",
"nvd_published_at": "2026-03-26T18:16:31Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA pathname parsing discrepancy in srvx\u0027s `FastURL` allows middleware bypass on the Node.js adapter when a raw HTTP request uses an absolute URI with a non-standard scheme (e.g. `file://`).\n\n## Details\n\nWhen Node.js receives an absolute URI in the request line (e.g. `GET file://hehe?/internal/run HTTP/1.1`), `req.url` is set verbatim to `file://hehe?/internal/run`. Since this doesn\u0027t start with `/`, `NodeRequestURL` passes it directly to `FastURL` as a string, which stores it in `#href` for lazy manual parsing.\n\n`FastURL#getPos()` locates the pathname by finding `://` then scanning for the next `/` \u2014 but this fails for URLs like `file://hehe?/internal/run` where a `?` appears before the first `/` after the authority. The manual parser extracts pathname as `/internal/run`, while native `URL` correctly parses it as pathname `/` with search `?/internal/run`.\n\nThis discrepancy means the router (using the fast-path) matches `/internal/run`, but if any middleware triggers a deopt to native `URL` (e.g. by accessing `hostname`), subsequent middleware sees a different pathname \u2014 bypassing route-based middleware guards.\n\nThis is a bypass of [CVE-2026-33131](https://github.com/h3js/h3/security/advisories/GHSA-3vj8-jmxq-cgj5).\n\n## Impact\n\nRoute-based middleware (auth guards, rate limiters, etc.) can be bypassed on the Node.js adapter when a prior middleware triggers `FastURL` deopt. Requires sending a raw HTTP request (not possible from browsers).\n\n## Fix\n\nsrvx `FastURL` constructor now deopts to native `URL` for any string not starting with `/`, ensuring consistent pathname resolution.",
"id": "GHSA-p36q-q72m-gchr",
"modified": "2026-03-27T21:11:10Z",
"published": "2026-03-26T16:52:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/h3js/h3/security/advisories/GHSA-p36q-q72m-gchr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33732"
},
{
"type": "WEB",
"url": "https://github.com/h3js/srvx/commit/de0d69901c357f36a39b7e13eebef6c930652baa"
},
{
"type": "PACKAGE",
"url": "https://github.com/h3js/srvx"
},
{
"type": "WEB",
"url": "https://github.com/h3js/srvx/releases/tag/v0.11.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "srvx is vulnerable to middleware bypass via absolute URI in request line "
}
GHSA-P7RF-4RP4-Q9Q8
Vulnerability from github – Published: 2025-04-01 06:30 – Updated: 2026-04-01 18:34Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in WP Travel Engine WP Travel Engine allows PHP Local File Inclusion. This issue affects WP Travel Engine: from n/a through 6.3.5.
{
"affected": [],
"aliases": [
"CVE-2025-30870"
],
"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 WP Travel Engine WP Travel Engine allows PHP Local File Inclusion. This issue affects WP Travel Engine: from n/a through 6.3.5.",
"id": "GHSA-p7rf-4rp4-q9q8",
"modified": "2026-04-01T18:34:18Z",
"published": "2025-04-01T06:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30870"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-travel-engine/vulnerability/wordpress-wp-travel-engine-plugin-6-3-5-local-file-inclusion-vulnerability-2?_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"
}
]
}
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.