3.7 CVE-2026-33490
H3 is a minimal H(TTP) framework. In versions 2.0.0-0 through 2.0.1-rc.16, the `mount()` method in h3 uses a simple `startsWith()` check to determine whether incoming requests fall under a mounted sub-application's path prefix. Because this check does not verify a path segment boundary (i.e., that the next character after the base is `/` or end-of-string), middleware registered on a mount like `/admin` will also execute for unrelated routes such as `/admin-public`, `/administrator`, or `/adminstuff`. This allows an attacker to trigger context-setting middleware on paths it was never intended to cover, potentially polluting request context with unintended privilege flags. Version 2.0.2-rc.17 contains a patch.
https://nvd.nist.gov/vuln/detail/CVE-2026-33490
Categories
CWE-706 : Use of Incorrectly-Resolved Name or Reference
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. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
References
134c704f-9b21-4f2e-91b3-4a467353bcc0
security-advisories@github.com
AFFECTED (from MITRE)
| Vendor |
Product |
Versions |
| h3js |
h3 |
- >= 2.0.1-alpha.0, < 2.0.1-rc.17 [affected]
|
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
CPE
REMEDIATION
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| No known exploits |
POC Github
Other Nist (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
severity |
| 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. [Identify Target] The adversary identifies the target application and determines what libraries are being used. [Deploy Malicious Libraries] The adversary crafts malicious libraries and deploys them on the system where the application is running, or in a remote location that can be loaded by the application. [Redirect Library Calls to Malicious Library] Once the malicious library crafted by the adversary is deployed, the adversary will manipulate the flow of the application such that it calls the malicious library. This can be done in a variety of ways based on how the application is loading and calling libraries. |
Very High |
| 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. |
Very High |
| 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. [Identify web application URL inputs] Review application inputs to find those that are designed to be URLs. [Identify URL inputs allowing local access.] Execute test local commands via each URL input to determine which are successful. [Execute malicious commands] Using the identified URL inputs that allow local command execution, execute malicious commands. |
High |
| 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. |
High |
MITRE
Techniques
| id |
description |
| T1036 |
Masquerading |
| T1574.002 |
Hijack Execution Flow:DLL Side-Loading |
| T1574.008 |
Hijack Execution Flow:Path Interception by Search Order Hijacking |
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
Mitigations
| id |
description |
| M1017 |
Train users not to open email attachments or click unknown links (URLs). Such training fosters more secure habits within your organization and will limit many of the risks. |
| M1051 |
Update software regularly to include patches that fix DLL side-loading vulnerabilities. |
| M1022 |
Ensure that proper permissions and directory access control are set to deny users the ability to write files to the top-level directory <code>C:</code> and system directories, such as <code>C:Windows</code>, to reduce places where malicious files could be placed for execution. Require that all executables be placed in write-protected directories. |
| © 2022 The MITRE Corporation. Esta obra se reproduce y distribuye con el permiso de The MITRE Corporation. |
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
Discover this offer
