EUVD-2026-64065
GHSA-8882-frvv-92w4
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/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
AC:H because the exploit requires a URL that fails the URL constructor yet succeeds in fetch(); C:L for potential HTTP traffic exposure via SSRF redirect.
Primary rating from Vendor (https://github.com/asymmetric-effort/specifyjs).
CVSS VectorVendor: https://github.com/asymmetric-effort/specifyjs
Lifecycle Timeline
5DescriptionCVE.org
Finding
Location: core/src/shared/secure-fetch.ts:42-45
When new URL() throws a parse error, the assertSecureUrl function returned without throwing, silently allowing the request to proceed without HTTPS validation.
Status
Fixed in v0.2.136 - The catch block now throws an error instead of silently returning.
AnalysisAI
URL validation bypass in @asymmetric-effort/specifyjs before v0.2.136 enables Server-Side Request Forgery by silently allowing outbound requests when URL parsing fails. The assertSecureUrl function in secure-fetch.ts:42-45 contains a catch block that returns without throwing when new URL() raises a parse error, so any URL that defeats the WHATWG URL constructor but remains acceptable to fetch() bypasses the library's HTTPS-only enforcement entirely. No public exploit code has been identified, and a vendor-confirmed patch is available in v0.2.136.
Technical ContextAI
The affected package is a TypeScript npm library (@asymmetric-effort/specifyjs, pkg:npm/@asymmetric-effort_specifyjs) that wraps the fetch() API with an HTTPS-only policy via a function called assertSecureUrl. The policy is implemented using the WHATWG URL constructor to parse and inspect each request URL before dispatch. CWE-918 (Server-Side Request Forgery) applies because the error-handling path in the catch block silently returns on a parse failure rather than throwing, making the validation function a no-op for any URL that triggers a constructor exception. In Node.js or Deno SSR environments where window is undefined, new URL(url) called without a base throws for relative-format or non-standard URLs, creating a reproducible bypass path in server-side rendering pipelines. The vulnerability was surfaced by a white-box pentest of v0.2.135 (PT-001 in the accompanying report) and is the sole High-severity finding in an otherwise well-reviewed codebase with zero runtime dependencies.
RemediationAI
Upgrade @asymmetric-effort/specifyjs to version 0.2.136 or later, confirmed patched per vendor release tag v0.2.136 and commit 25d1fb491d99479efdf501f5f75e0bb80c908f0a (https://github.com/asymmetric-effort/specifyjs/commit/25d1fb491d99479efdf501f5f75e0bb80c908f0a). The fix replaces the silent return in the assertSecureUrl catch block with an explicit throw new Error(...), ensuring unparseable URLs are rejected. If an immediate upgrade is not feasible, restrict the sources from which URL strings are accepted by the application so that only hard-coded or internally validated URLs reach secureFetch - untrusted user input must never flow to secureFetch without independent pre-validation. As a targeted workaround, disabling SSR features that invoke secureFetch with externally derived URL parameters eliminates the vulnerable path at the cost of SSR functionality. Full advisory details are at https://github.com/asymmetric-effort/specifyjs/security/advisories/GHSA-8882-frvv-92w4.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today