ensureSessionID() doesn't validate session cookie value before using it as storage key

[wildfiremedia]

Astro Info

Astro                    v7.2.2
Node                     v26.7.0
System                   macOS (arm64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations

If this issue only occurs in one browser, which browser is a problem?

NA

Describe the Bug

While going through the sessions module (runtime.ts), full disclosure, I was using Claude to help dig through the code, so flagging that upfront rather than presenting it as pure manual review — I found that #ensureSessionID() takes the session cookie value directly from the client and uses it as the storage key, with no format validation. This is inconsistent with the cookie name, which is checked against VALID_COOKIE_REGEX.

If the client-supplied session ID happens to collide with an existing key in the storage backend whose value isn't a valid session Map, it triggers destroy(). The request pipeline's finally block still flushes this as a real storage.removeItem() call, even though the request itself throws/500s.

Severity note: I checked the Node, Cloudflare, and Netlify adapter defaults — all give sessions their own isolated store out of the box, so this isn't exploitable under default config. It only matters if someone points the session driver at a storage backend shared with other data, without a key prefix.

Confirmed by a maintainer as low severity, filing per their request.

Suggested fix: Add a validation check on the session ID (mirroring VALID_COOKIE_REGEX used for the cookie name) as a safety net, so malformed/colliding values are rejected before being used as a storage key.

What's the expected result?

Session IDs supplied by the client should be validated against an expected format before being used as a storage key, so they can't collide with unrelated keys in a shared storage backend.

Link to Minimal Reproducible Example

NA

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

• Reproduced: Yes
• Exploration: Yes — View branch
• Unit Test: Yes — packages/astro/test/sessions.test.ts (new test: "rejects a non-UUID session cookie value and generates a new ID")
• Priority: P2: has workaround. As noted in the issue, all default adapter configurations use isolated storage, so this only affects users who manually point the session driver at a shared storage backend without a key prefix. The workaround is to use a dedicated/prefixed storage namespace for sessions.

The #ensureSessionID() method in packages/astro/src/core/session/runtime.ts reads the session cookie value from the client and uses it directly as a storage key with no format validation. Since Astro generates UUIDs via crypto.randomUUID() for new sessions, a simple UUID format check would reject any crafted or malformed values. Without this check, a client-supplied value that collides with an existing non-session key in shared storage triggers destroy(), which then flushes a storage.removeItem() call for that key.

I found a potential fix for this issue. The fix adds a UUID_REGEX constant and validates the cookie value against it in #ensureSessionID(). If the value doesn't match the expected UUID v4 format, a new UUID is generated instead of accepting the client-supplied value. All 9 session tests pass (8 existing + 1 new).

Try this fix

You can test this fix right now without waiting for a release:

npm i https://pkg.pr.new/astro@0862c69

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Reproduction

Confirmed that #ensureSessionID() accepts any client-supplied cookie value without format validation. A test sending astro-session=not-a-uuid-at-all as a cookie demonstrated the value was accepted and used directly as a storage key. When data exists at a crafted key, it is loaded and used as session data.

Diagnosis

Root cause: #ensureSessionID() (line ~433 of packages/astro/src/core/session/runtime.ts) checks only whether a cookie value exists (if (cookieValue)), not whether it matches the expected UUID format. This is inconsistent with the cookie name validation, which uses VALID_COOKIE_REGEX.

Impact chain when a crafted session ID collides with non-session data:

1. #ensureSessionID() accepts the arbitrary value as the session ID
2. #ensureData() calls storage.get() with that value as the key
3. If data exists but isn't a valid Map, the !(storedMap instanceof Map) check triggers destroy()
4. destroy() adds the crafted ID to #toDestroy and sets #dirty = true
5. The [PERSIST_SYMBOL]() method in the request pipeline's finally block calls storage.removeItem() on the crafted key

Existing partial mitigation: #ensureData() regenerates IDs when #sessionIDFromCookie is true and no storage data is found (lines 370-377). However, this only covers the "no data found" case — not the "data found but wrong format" case.

Verification

This is a legitimate bug, not intended behavior:

• Cookie names are validated but cookie values are not (inconsistency)
• Server-generated IDs are always UUIDs, establishing an expected format
• The #sessionIDFromCookie mitigation logic shows developers were aware of untrusted cookie values but missed this case

Fix

File: packages/astro/src/core/session/runtime.ts

Added UUID_REGEX constant and changed the condition in #ensureSessionID() from if (cookieValue) to if (cookieValue && UUID_REGEX.test(cookieValue)). Non-UUID values are silently rejected and a fresh UUID is generated instead.

Test: Added "rejects a non-UUID session cookie value and generates a new ID" to packages/astro/test/sessions.test.ts. All 9 tests pass.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[wildfiremedia]

Confirmed, this fixes it. (Disclosure: had Claude clone the repo, check out the fix commit, and run the updated #ensureSessionID() logic against a set of crafted non-UUID cookie values, including collision-style keys like config, proto, path-traversal strings, plus a valid UUID for regression. All crafted values were rejected with a new session ID generated; the valid UUID was preserved.)

Thanks for the quick fix!

[astrobot-houston]

The fix has been verified! A pull request has been created: #17719

[matthewp]

@wildfiremedia please provide a reproduction. Just looking at code and spotting things that don't seem right to you doesn't mean there is a bug. If you can provide a reproduction of a bug-causing issue around this, we can retriage it.