Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Finding Location: core/src/server/render-to-string.ts:307-311 CSS value sanitization stripped expression( and url(javascript: using simple regex, but could be bypassed with CSS unicode escapes (\65xpression(), null bytes, or CSS comments (exp//ression(). Mitigating Factor: These CSS injection vectors only work in legacy browsers (IE6-IE10). SpecifyJS targets modern browsers. Status Fixed in v0.2.136 — CSS sanitization now normalizes unicode escapes and strips CSS comments before pattern matching. Also checks for behavior:, -moz-binding, and -o-link patterns.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Finding Location: core/src/shared/secure-fetch.ts:33-35 data: URIs were allowed without any restriction. While data: URIs don't make network requests, they can be used for memory exhaustion via very large data URIs. Status Fixed in v0.2.136 — data: URIs are now limited to 1MB. URIs exceeding this limit throw an error.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Finding Location: core/src/shared/secure-fetch.ts:52-54 The localhost exception allowed localhost and 127.0.0.1 but did not cover 0.0.0.0, [::1] (IPv6 localhost), or the full 127.0.0.0/8 loopback range. Status Fixed in v0.2.136 — Localhost detection now covers localhost, 127.0.0.1, [::1], 0.0.0.0, and the full 127.x.x.x range.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Finding Location: core/src/core/scheduler.ts:23, core/src/hooks/dispatcher.ts:100, core/src/client/graphql.ts:71 Several console.warn calls are not gated behind DEV and will fire in production builds, potentially exposing internal framework state such as queue sizes, component names, and query fragments to users viewing the browser console. Status Open — These warnings serve as development-time diagnostics. They do not expose credentials or PII, but may reveal internal architecture details. Recommendation Gate all development-time console.warn and console.error calls behind process.env.NODEENV !== 'production' or a DEV constant that build tools can tree-shake.
Recommended action: Upgrade to 0.2.140 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Finding Location: core/src/client/graphql.ts:66-80 The gql template tag function warned about interpolated values containing GraphQL metacharacters ({}():) but still concatenated them into the query string, enabling potential GraphQL injection. Status Fixed in v0.2.136 — The gql function now throws an error when metacharacters are detected in interpolated values, forcing developers to use the variables parameter.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.2.136 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.