@asymmetric-effort/specifyjs: No redirect target validation in secureFetch

published 2026-07-02 4mo ago modified 2026-09-10 2mo ago

cvss: —; not scored
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

## Finding

**Location**: `core/src/shared/secure-fetch.ts`

`assertSecureUrl` validated only the initial request URL. The `fetch()` API follows redirects by default (up to 20 hops). A request to a valid `https://` URL could redirect to `http://internal-service/` or other unvalidated destinations.

## Status

**Fixed in v0.2.136** — `secureFetch` now defaults to `redirect: 'error'` which rejects any redirect. Callers can override with `{ redirect: 'follow' }` if they trust the target.

Patch / fix

fixed in 1 links 1

npm @asymmetric-effort/specifyjs 0.2.136

github.com/asymmetric-effort/specifyjs@25d1fb4 commit

Is GHSA-j5qp-p44g-2m49 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem	package	affected	fixed in
npm	@asymmetric-effort/specifyjs	<0.2.136	0.2.136

Classification

Weakness

CWE-918 Server-Side Request Forgery

References

Sources

GitHub Advisory GHSA-j5qp-p44g-2m49

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.