Skip to main content

uri-js CVE-2026-93751

| EUVDEUVD-2026-83256 MEDIUM
Improper Handling of Unicode Encoding (CWE-176)
2026-09-18 VulnCheck GHSA-7g43-p94j-qr58
6.9
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Craft overlong percent-encoded URI payload
  2. Delivery
    Submit to app using uri-js parse/normalize
  3. Exploit
    pctDecChars decodes into ASCII metacharacters
  4. Execution
    Bypass platform decoder validation
  5. Persist
    Downstream consumer processes traversal/CRLF unfiltered
  6. Impact
    File access or header/response injection

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Unicode normalization
Exploitation Conditions

Exploitation requires (1) a target application that uses uri-js (≤4.4.1) to parse, normalize, or percent-decode attacker-controlled URI input via the vulnerable pctDecChars() path, and (2) a downstream consumer that trusts uri-js's decoded output as already-validated and uses it to build a filesystem path or HTTP header/log line WITHOUT its own filtering. The flaw is remotely and unauthenticatedly triggerable (PR:N, UI:N) with a crafted percent-encoded payload, but the actual security impact is LIMITED by the consuming application's handling - if the downstream code re-validates the decoded string, or does not use it for path/header construction, no traversal or CRLF injection results. There is no availability impact and no direct code execution; harm is confined to path-traversal file access or CRLF/response-splitting in the specific downstream context.

Impact

This is a moderate-severity input-neutralization weakness (CWE-176, improper Unicode/UTF-8 handling) in the uri-js library, not a directly exploitable RCE or auth bypass. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N, score 6.9) correctly reflects remote, unauthenticated, low-complexity triggering with only LOW integrity/confidentiality impact and NO availability impact - the flaw itself does not compromise a system, it undermines a downstream validator's assumptions. Real-world risk is entirely contingent on how consumers use uri-js output: pctDecChars() decodes invalid/overlong percent-encoded sequences into ASCII metacharacters, so the danger materializes only when a downstream consumer treats the decoded string as a trusted, already-validated path or header value and performs path traversal or CRLF injection with it. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided in the input, so there is no signal of active or automated exploitation; this is a supply-chain/library hygiene issue disclosed by VulnCheck rather than a confirmed in-the-wild threat. The main aggravating factor is breadth of deployment (uri-js is an extremely common transitive npm dependency), which raises aggregate exposure even though per-instance exploitability depends on the consuming application. Treat this as a patch-in-normal-cycle dependency update, elevated only where uri-js output feeds filesystem paths or HTTP headers without secondary validation.

Exploit ScenarioDerived

An attacker submits a URI or URI component containing overlong/invalid percent-encoded bytes (e.g. an overlong encoding of '/' or CR/LF) to an application that normalizes or parses it with uri-js. Because pctDecChars() decodes these into raw ASCII metacharacters, the payload slips past platform decoder validation and reaches a downstream consumer, which then interprets the decoded '../' as path traversal or the injected CRLF as an HTTP header/log split. No public exploit code was identified at time of analysis; exploitation is remote and unauthenticated but depends on the downstream consumer processing the decoded output unsafely.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 18, 2026

Improper UTF-8 percent-decoding in uri-js through 4.4.1 lets remote, unauthenticated attackers feed crafted percent-encoded URIs that the library converts into ASCII metacharacters such as '/', '\', '.' and CRLF, enabling downstream path traversal or CRLF injection wherever the decoded output is consumed without re-validation. The flaw is remotely triggerable with no authentication or user interaction (CVSS:4.0 base 6.9; independent assessment CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), but real-world harm is constrained by the consuming application: no code execution, no availability impact, and no effect at all if the downstream code re-validates the decoded string. There is no CISA KEV listing and no public exploit identified at time of analysis, so this is currently a latent input-neutralization weakness for applications that treat uri-js output as already-sanitized rather than a live exploitation campaign.

RemediationAI

No vendor-released patch or fixed version is identified in the available data, so assume uri-js 4.4.1 and earlier remain vulnerable; track upstream issue https://github.com/garycourt/uri-js/issues/106 for a patched release and, until one ships, treat every decoded URI string as untrusted. The most reliable compensating control is to stop treating uri-js output as validated: after any parse/normalize/decode step, decode exactly once with a strict, spec-conformant decoder (decodeURIComponent() or the WHATWG URL parser), reject or re-encode any result containing overlong or invalid UTF-8, and then apply context-specific validation before use. For filesystem sinks, resolve the final path with path.resolve()/realpath and verify the result still sits inside an allow-listed base directory, rejecting any decoded segment equal to '..' or containing path separators - the trade-off is that legitimate URIs with percent-encoded slashes will be rejected unless explicitly allow-listed. For HTTP/log sinks, strip or reject CR (0x0D) and LF (0x0A) from any decoded value before it reaches a header or log line, accepting that this breaks the rare legitimate multi-line value. Applications that do not build paths, headers, or shell/query strings from uri-js output are not exploitable and can defer upgrading; those that do should consider replacing the dependency or overriding it with a maintained alternative (for example the built-in WHATWG URL API) and re-testing parsing behaviour, since stricter decoding may change normalization results across the codebase. Additional hardening: block malformed percent-encoding at the HTTP ingress (WAF/reverse-proxy rules that reject overlong UTF-8 and encoded path separators) as a defence-in-depth layer, while noting this does not help for non-HTTP input channels. Reference advisories: https://www.vulncheck.com/advisories/uri-js-through-4.4.1-improper-utf-8-decoding-via-pctdecchars and https://github.com/garycourt/uri-js/issues/106.

Affected VersionsENISA

uri-js 0 ≤4.4.1

Affected Packages

euvd uri_js no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The issue is CWE-176 (Improper Handling of Unicode Encoding), rooted in the pctDecChars() routine of the uri-js URI parser (source lines 103-141 of src/uri.ts, linked from the CVE references). Percent-decoding is supposed to reverse %XX escapes into bytes and then interpret those bytes as UTF-8; a conformant decoder rejects overlong encodings and invalid continuation sequences. pctDecChars() instead accepts malformed and overlong sequences and reduces them to their ASCII equivalents, so payloads such as overlong forms of '/', '\', '.' or CR/LF survive the decode step as ordinary metacharacters that the library's own validation logic never flagged. The security relevance is entirely contextual: uri-js is a widely embedded URI parsing/normalization component, and any consumer that performs a single decode-then-trust pass inherits the ambiguity. This is a decoder-validation bypass class of bug rather than a memory-safety or injection flaw inside uri-js itself - uri-js does not construct filesystem paths or emit HTTP headers, so it provides the malformed primitive while the downstream application supplies the sink.

Know when Uri Js gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 6.9 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
vuln.today AI 6.5 MEDIUM

Remote, unauthenticated, low-complexity to send a crafted encoded payload (AV:N/AC:L/PR:N/UI:N); only low C/I impact that is realized in a downstream consumer, no availability effect (A:N).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
SUSE 5.3 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Red Hat 6.5 MEDIUM

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
Low
Vulnerable system: Integrity
Low
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

uri-js through 4.4.1 contains an improper UTF-8 decoding vulnerability in pctDecChars() that decodes invalid and overlong percent-encoded sequences into ASCII metacharacters. Attackers can craft percent-encoded payloads to bypass platform decoder validation and inject path traversal or CRLF sequences that downstream consumers process without filtering.

Threat Intelligence Overview

EPSS Score
0.2%
Top 86% exploitable
Prevalence
High
uri-js is a very widely-used npm URI library and common transitive dependency (e.g. via ajv)
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment Vendor GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.

More in Uri Js

View all

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 12 Not-Affected
SUSE Linux Enterprise Micro 5.3 Affected
SUSE Linux Enterprise Micro 5.3 Affected
SUSE Linux Enterprise Micro 5.3 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy