Security: bundled PostgreSQL 18.4 / TimescaleDB 2.28.1 and the self-contained .NET 10.0.11 runtime carry published CVEs #3906

A security review of 3.8.0 by a prospective user flagged two findings. Both are confirmed against the shipped artifacts.

Darling: the bundled PostgreSQL and TimescaleDB

Darling/tools/fetch-pg-runtime.ps1 pins EDB PostgreSQL 18.4 (2026-05-14) and TimescaleDB 2.28.1. The 3.8.0 pg-runtime.zip reports pg_ctl 18.4 and timescaledb-2.28.1.dll.

• PostgreSQL 18.6 (2026-08-13; 18.5 was never released because of a regression) fixes 23 CVEs that affect 18.4, most rated High (CVSS 8.x). See https://www.postgresql.org/support/security/ and https://www.postgresql.org/docs/release/18.6/
• TimescaleDB 2.29.1 fixed GHSA-hcfx-29v5-2rcw (High): missing permission checks in internal chunk management functions, affecting 2.7.0 through 2.29.0. The latest release is 2.30.1.

Existing installs do pick up a new runtime when they upgrade. DarlingStoreUpgrade.TryAdvanceRuntimeAsync swaps the extracted runtime whenever the shipped pg-runtime.zip hash differs from pg-runtime.stamp. A same-major swap runs no pg_upgrade; it runs ALTER EXTENSION timescaledb UPDATE.

There is one gap. A host that has no stamp is adopted as current when its PostgreSQL major and TimescaleDB version match the package. A minor-only bump such as 18.4 → 18.6 therefore never reaches that host.

Lite and Darling Viewer: Microsoft.DiaSymReader.Native from the self-contained .NET runtime

No project references Microsoft.DiaSymReader.Native; the file comes from the .NET runtime pack. Lite (zip, Setup and Portable) and the Viewer's Setup and Portable builds are self-contained. In 3.8.0 they carry runtime pack 10.0.11 and Microsoft.DiaSymReader.Native.amd64.dll 14.42.34436.0.

That DLL is affected by CVE-2026-69439, CVE-2026-71328 and CVE-2026-69522: out-of-bounds writes while parsing PDB files, CVSS 8.8, user interaction required. All three are fixed in .NET 10.0.12 (2026-09-08).

Root cause. global.json pins SDK 10.0.302 with rollForward: latestPatch, which never leaves the 3xx feature band. Microsoft stopped servicing that band at 10.0.303, which carries runtime 10.0.11. The 10.0.12 runtime shipped only in SDKs 10.0.401 and 10.0.112.

Dependabot manages the NuGet packages but not the SDK. So after 10.0.12, every self-contained build kept packing the 10.0.11 runtime, even though the Microsoft.Extensions.* packages moved to 10.0.12.

The Darling service and the Darling zip's viewer\ folder are framework-dependent. They run on the machine's installed .NET 10 runtime, which the operator patches (10.0.12 or later).

Plan

• Pin PostgreSQL 18.6 in fetch-pg-runtime.ps1. TimescaleDB stays at 2.28.1 for now: testing the bump on real data found that the store upgrade cannot move a field store's extension, and would leave every store's database failing after the upgrade. That fix, and the bump to 2.30.1, are tracked in TimescaleDB bump: the store upgrade cannot move a field store's extension (same-major probe loads the missing old library; pg_upgrade bridge cannot reach a newer version) #3908.
• Hosts with no stamp: compare the full PostgreSQL version, not only the major, before adopting the extracted runtime as current.
• Move to SDK 10.0.401 (runtime 10.0.12) in global.json and Darling/Dockerfile.
• Have Dependabot's dotnet-sdk ecosystem open a PR for each new SDK, so runtime security servicing no longer depends on someone noticing. Add a pin test, run on every global.json change, so the Dockerfile's SDK line has to move with it.
• Add a weekly check that fails when a newer PostgreSQL minor for the pinned major is out, or when a TimescaleDB advisory covers the pinned version. It will stay red on GHSA-hcfx-29v5-2rcw until TimescaleDB bump: the store upgrade cannot move a field store's extension (same-major probe loads the missing old library; pg_upgrade bridge cannot reach a newer version) #3908 lands, which is accurate.