11.40.0

An SSRF egress allowlist that was switched off wherever it was configured from the environment now works.

Update

pnpm update @lenne.tech/nest-server

Do I need to do anything?

Only if you set ai.allowedBaseUrlHosts through an environment variable. One check answers it:

grep -r "NSC__AI__ALLOWED_BASE_URL_HOSTS" . --include="*.env*" --include="*.yml" --include="*.yaml"

How you set it	Affected?
NSC__AI__ALLOWED_BASE_URL_HOSTS (or any env route)	Yes — the control was inert
A real array in config.env.ts	No — it worked as documented
Not set at all	No — no restriction was intended

If the grep finds something, the allowlist has not been restricting anything on that deployment, and it starts doing so with this release. Make sure every base URL your AI connections actually use is in the list before updating — otherwise those outbound calls begin to be refused.

This is not an edge case for a wrong notation: the NSC__* reader coerces only 'true', 'false' and numbers, so no environment value can produce an array. Anyone configuring the allowlist that way had it fully off.

Full details, including the matching rules and the two other outbound paths now covered: migration guide 11.39.0 → 11.40.0.

Why a MINOR

The MAJOR digit in this package tracks the NestJS major (11.x = NestJS 11), so it is not ours to spend — breaking changes of our own ship as MINOR releases. This one is breaking in behaviour: a security control that was silently inert starts being enforced, and a deployment that relied on the inert behaviour can stop working.

Under the hood

The allowlist now also guards probeContextWindow(), which was unguarded and is reachable from an ordinary user prompt, and it accepts a comma-separated string as well as an array, normalising case and trailing dots on both sides of the comparison.