A dependency security release for the 1.9 line. Nothing in Terrapod's own
behaviour changes — the whole release is two frontend dependency bumps and the
reasoning for a third advisory that has no upstream fix.
All three advisories arrived on an unchanged lockfile: v1.9.0's tag pipeline
was green on exactly the lockfile this release bumps. What moved was npm's
advisory data, not anything in the tree, which is what the scheduled re-scan of
supported releases exists to catch.
Security
Two advisories are fixed, both high severity, both reachable in the published
terrapod-web image:
-
GHSA-wq5f-xc86-pv6w— a vulnerability insharp's bundled librsvg
(CVE-2026-96889), affectingsharp < 0.35.5.v1.9.0shipped 0.35.4. Fixed
by taking 0.35.5, which also moves the bundled
@img/sharp-libvips-*packages to 1.3.4, where the librsvg fix lives.sharp
is an optional production dependency pulled in by Next.js for image
optimization. -
GHSA-68fv-2mgg-jv7q— an event-loop denial of service insource-map-js
through indexed source-map section offsets, affecting>= 1.0.0, < 1.2.2.
v1.9.0shipped 1.2.1. Fixed by taking 1.2.2. It reaches the image
transitively throughpostcss.
Both were taken as upstream fixes rather than accepted, because the advisories
name a patched version and npm reports one available.
GHSA-vfj7-8cjw-p6xm (braces) is an accepted risk, not a fix
The third advisory blocking this release has no upstream fix to take. The
advisory's own affected range is <= 3.0.3 with no first-patched version, and
3.0.3 is the latest braces published — so every version in existence is
affected. npm's suggested remediation is a two-major downgrade of
eslint-config-next, which clears nothing, because the older chain depends on
braces too.
It is therefore recorded in pentest/npm-audit-allow.txt with its reasoning and
an exit condition, rather than papered over. It is not reachable from anything
Terrapod ships: the whole dependency chain is development-only in the lockfile,
and the terrapod-web image's production stage copies Next.js's standalone
output rather than the full node_modules. That standalone output does carry a
traced node_modules of runtime dependencies — checked, and braces is not
among them. braces runs under npm run lint and nowhere else, over globs we
wrote ourselves.
If your own scanner reports GHSA-vfj7-8cjw-p6xm against a v1.9.1 image,
that is this entry and it is expected. The register is re-examined every
release; it will be removed as soon as braces publishes a version the advisory
lists as patched, or the lint toolchain stops depending on micromatch.
Also in this release
A documentation correction that landed after v1.9.0 was cut, and ships here
for the first time (#1959). All three OIDC examples in
docs/authentication.md
named the POST-only SAML ACS endpoint as the redirect URI. An operator following
the Auth0 or Okta example verbatim would have registered
/api/terrapod/v1/auth/saml/acs as their OIDC callback, and OIDC login would
fail. The examples now name /api/terrapod/v1/auth/callback. If you configured
an OIDC provider against the v1.9.0 docs, check the redirect URI registered
with your IdP.
Two comment-level scanner suppressions the development line already carried, so
the files no longer differ between the lines. Neither changes behaviour: the Go
binary is unchanged, and the pull-request command help text is byte-identical.
One of them resolves a CodeQL py/implicit-string-concatenation-in-list finding
reported against the v1.9.0 tag.
Three further findings reported against the v1.9.0 tag are not addressed
here. All three are CodeQL note-severity findings in test files, none is a
security finding, and two of them describe a deliberate choice that "fixing"
would undo.
Upgrading
Drop-in. No schema migration, no configuration change, no API, wire-protocol or
Helm values change — the diff is two npm manifests, one accepted-risk register
and two source comments. A runner or listener at v1.9.0 keeps working against
a v1.9.1 API.
Status
Supported lines are 1.9 and 1.8. 1.9 is the current line.
Full Changelog: v1.9.0...v1.9.1