chore(deps): update dependency @astrojs/node to v10 [security]#10333
chore(deps): update dependency @astrojs/node to v10 [security]#10333renovate[bot] wants to merge 1 commit intomainfrom
Conversation
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx affected --targets=test:sherif,test:knip,tes... |
❌ Failed | 4m 36s | View ↗ |
nx run-many --target=build --exclude=examples/*... |
✅ Succeeded | 1s | View ↗ |
☁️ Nx Cloud last updated this comment at 2026-04-23 15:07:51 UTC
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughUpdated the Solid + Astro example's package.json to change the Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🚀 Changeset Version PreviewNo changeset entries found. Merging this PR will not cause a version bump for any packages. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@examples/solid/astro/package.json`:
- Line 14: The dependency update is invalid because "@astrojs/node" v10 requires
Astro v6+, while this project uses "astro" v5.5.6; fix by either (A) upgrading
"astro" to a compatible v6+ release alongside "@astrojs/node" v10 and then run
the project build/tests and update any config changes (search for "astro" in
package.json and check "astro.config" for any required migrations), or (B)
revert "@astrojs/node" to a v9.x patch that addresses CVE-2026-29772 if
available (check npm/changelog for a patched v9), update package.json
accordingly, run npm install and verify the example builds; note that
astro.config does not use the removed experimentalErrorPageHost option so no
extra migration steps are required for that flag.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b4388bf3-cb8c-4129-b917-3c837bd9735d
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
examples/solid/astro/package.json
| "dependencies": { | ||
| "@astrojs/check": "^0.9.4", | ||
| "@astrojs/node": "^9.1.3", | ||
| "@astrojs/node": "^10.0.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check Astro config for removed experimentalErrorPageHost option
# Search for experimentalErrorPageHost in Astro config files
fd -e mjs -e js -e ts --full-path 'astro\.config' --exec rg -n 'experimentalErrorPageHost'
# Also check if there's an adapter configuration that might need bodySizeLimit
fd -e mjs -e js -e ts --full-path 'astro\.config' --exec cat {}Repository: TanStack/query
Length of output: 387
🌐 Web query:
Is @astrojs/node version 10 compatible with Astro version 5.5.6?
💡 Result:
No, @astrojs/node version 10 is not compatible with Astro version 5.5.6.
Citations:
- 1: https://newreleases.io/project/github/withastro/astro/release/@astrojs%2Fnode@10.0.0
- 2: https://docs.astro.build/en/guides/upgrade-to/v6/
- 3: https://www.npmjs.com/package/@astrojs/node/v/5.3.2?activeTab=dependencies
- 4: https://github.com/withastro/astro/blob/main/packages/integrations/node/CHANGELOG.md
- 5: https://www.npmjs.com/package/%40astrojs/node
@astrojs/node v10 is incompatible with Astro v5.5.6 — cannot upgrade without updating Astro.
The security update for CVE-2026-29772 is critical and must be applied. However, @astrojs/node v10 requires Astro v6 or higher, not v5.5.6. Upgrading only the adapter will break the example project.
The astro.config doesn't use the removed experimentalErrorPageHost option, so there are no deprecated features to migrate.
To proceed with the security fix, either:
- Upgrade
astroto a compatible v6+ version alongside@astrojs/nodev10 - Check if a v9.x patch is available for the CVE
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/solid/astro/package.json` at line 14, The dependency update is
invalid because "@astrojs/node" v10 requires Astro v6+, while this project uses
"astro" v5.5.6; fix by either (A) upgrading "astro" to a compatible v6+ release
alongside "@astrojs/node" v10 and then run the project build/tests and update
any config changes (search for "astro" in package.json and check "astro.config"
for any required migrations), or (B) revert "@astrojs/node" to a v9.x patch that
addresses CVE-2026-29772 if available (check npm/changelog for a patched v9),
update package.json accordingly, run npm install and verify the example builds;
note that astro.config does not use the removed experimentalErrorPageHost option
so no extra migration steps are required for that flag.
size-limit report 📦
|
053b023 to
0396410
Compare
0396410 to
e6bb3ee
Compare
e6bb3ee to
2613d34
Compare

This PR contains the following updates:
^9.1.3→^10.0.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands
CVE-2026-29772 / GHSA-3rmj-9m5h-8fpv
More information
Details
Summary
Astro's Server Islands POST handler buffers and parses the full request body as JSON without enforcing a size limit. Because
JSON.parse()allocates a V8 heap object for every element in the input, a crafted payload of many small JSON objects achieves ~15x memory amplification (wire bytes to heap bytes), allowing a single unauthenticated request to exhaust the process heap and crash the server. The/_server-islands/[name]route is registered on all Astro SSR apps regardless of whether any component usesserver:defer, and the body is parsed before the island name is validated, so any Astro SSR app with the Node standalone adapter is affected.Details
Astro automatically registers a Server Islands route at
/_server-islands/[name]on all SSR apps, regardless of whether any component usesserver:defer. The POST handler inpackages/astro/src/core/server-islands/endpoint.tsbuffers the entire request body into memory and parses it as JSON with no size or depth limit:The request body is parsed before the island name is validated, so the attacker does not need to know any valid island name —
/_server-islands/anythingtriggers the vulnerable code path. No authentication is required.Additionally,
JSON.parse()allocates a heap object for every array/object in the input, so a payload consisting of many empty JSON objects (e.g.,[{},{},{},...]) achieves ~15x memory amplification (wire bytes to heap bytes). The entire object graph is held as a single live reference until parsing completes, preventing garbage collection. An 8.6 MB request is sufficient to crash a server with a 128 MB heap limit.PoC
Environment: Astro 5.18.0,
@astrojs/node9.5.4, Node.js 22 with--max-old-space-size=128.The app does not use
server:defer— this is a minimal SSR setup with no server island components. The route is still registered and exploitable.Setup files:
package.json:{ "name": "poc-server-islands-dos", "scripts": { "build": "astro build", "start": "node --max-old-space-size=128 dist/server/entry.mjs" }, "dependencies": { "astro": "5.18.0", "@​astrojs/node": "9.5.4" } }astro.config.mjs:src/pages/index.astro:Dockerfile:docker-compose.yml:Reproduction:
crash.py:The server process is killed and does not recover. Repeated requests in a containerized environment with restart policies cause a persistent crash-restart loop.
Impact
Any Astro SSR app with the Node standalone adapter is affected — the
/_server-islands/[name]route is registered by default regardless of whether any component usesserver:defer. Unauthenticated attackers can crash the server process with a single crafted HTTP request under 9 MB. In containerized environments with memory limits, repeated requests cause a persistent crash-restart loop, denying service to all users. The attack requires no authentication and no knowledge of valid island names — any value in the[name]parameter works because the body is parsed before the name is validated.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed
CVE-2026-41322 / GHSA-c57f-mm3j-27q9
More information
Details
Summary
Requesting a static JS/CSS resource from the
_astropath with an incorrect or malformedif-matchheader returns a500error with a one-year cache lifetime instead of412in some cases. As a result, all subsequent requests to that file — regardless of theif-matchheader — will be served a 5xx error instead of the file until the cache expires.Sending an incorrect or malformed
if-matchheader should always return a412error without any cache headers, which is not the current behavior.Affected Versions
astro@5.14.1@astrojs/node@9.4.4Proof of Concept
Run the following command:
If a 5xx error is not returned, inspect the resources via the browser's web inspector and select another CSS/JS file to request until a 5xx error is returned. The behavior generally defaults to a 5xx response. Note that all static files are immutable, so the cache must be purged or disabled to reproduce reliably.
A response similar to the following is expected from CloudFront:
The above is not the real server output but the AWS error response triggered when the pods return a 5xx. Below is the output of the same
curlcommand issued directly against a pod in Kubernetes:This demonstrates that the pod itself returns a
5xxerror instead of412. In addition, the response includes aCache-Control: public, max-age=31536000, immutableheader.Because the testing setup configures
if-matchas part of the cache key, the exploit no longer affects the production application. Prior to that change, the CDN Point of Presence would become cache-poisoned, and any client visiting the affected pages without cached files through the same PoP would receive broken pages. This was reproduced by creating test URLs and visiting them in a browser only after triggering the exploit. The exploited resources returned5xxerrors instead of the original CSS/JS content, breaking the application.Details
The findings were analyzed with an LLM, which identified the following file as the likely source: serve-static.ts
LLM analysis:
Impact
Cache Poisoning — An attacker can force edge servers to cache an error page instead of the actual content, rendering one or more assets unavailable to legitimate users until the cache expires.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
withastro/astro (@astrojs/node)
v10.0.5Compare Source
Patch Changes
940afd5Thanks @matthewp! - Fixes static asset error responses incorrectly including immutable cache headers. Conditional request failures (e.g.If-Matchmismatch) now return the correct status code without far-future cache directives.v10.0.4Compare Source
Patch Changes
#16002
846f27fThanks @buley! - Fixes file descriptor leaks from read streams that were not destroyed on client disconnect or read errors#15941
f41584aThanks @ematipico! - Fixes an infinite loop inresolveClientDir()when the server entry point is bundled with esbuild or similar tools. The function now throws a descriptive error instead of hanging indefinitely when the expected server directory segment is not found in the file path.v10.0.3Compare Source
Patch Changes
#15735
9685e2dThanks @fa-sharp! - Fixes an EventEmitter memory leak when serving static pages from Node.js middleware.When using the middleware handler, requests that were being passed on to Express / Fastify (e.g. static files / pre-rendered pages / etc.) weren't cleaning up socket listeners before calling
next(), causing a memory leak warning. This fix makes sure to run the cleanup before callingnext().v10.0.2Compare Source
Patch Changes
6f8f0bcThanks @ematipico! - Updates the AstropeerDependencies#astroto be6.0.0.v10.0.1Compare Source
Patch Changes
bb2b8f5Thanks @ematipico! - Fixes an issue where the adapter would cause a series of warnings during the build.v10.0.0Compare Source
Major Changes
#15654
a32aee6Thanks @florian-lefebvre! - Removes theexperimentalErrorPageHostoptionThis option allowed fetching a prerendered error page from a different host than the server is currently running on.
However, there can be security implications with prefetching from other hosts, and often more customization was required to do this safely. This has now been removed as a built-in option so that you can implement your own secure solution as needed and appropriate for your project via middleware.
What should I do?
If you were previously using this feature, you must remove the option from your adapter configuration as it no longer exists:
// astro.config.mjs import { defineConfig } from 'astro/config' import node from '@​astrojs/node' export default defineConfig({ adapter: node({ mode: 'standalone', - experimentalErrorPageHost: 'http://localhost:4321' }) })You can replicate the previous behavior by checking the response status in a middleware and fetching the prerendered page yourself:
Minor Changes
#15258
d339a18Thanks @ematipico! - Stabilizes the adapter featureexperimentalStatiHeaders. If you were using this feature in any of the supported adapters, you'll need to change the name of the flag:export default defineConfig({ adapter: netlify({ - experimentalStaticHeaders: true + staticHeaders: true }) })#15759
39ff2a5Thanks @matthewp! - Adds a newbodySizeLimitoption to the@astrojs/nodeadapterYou can now configure a maximum allowed request body size for your Node.js standalone server. The default limit is 1 GB. Set the value in bytes, or pass
0to disable the limit entirely:#15006
f361730Thanks @florian-lefebvre! - Adds new session driver object shapeFor greater flexibility and improved consistency with other Astro code, session drivers are now specified as an object:
Specifying the session driver as a string has been deprecated, but will continue to work until this feature is removed completely in a future major version. The object shape is the current recommended and documented way to configure a session driver.
#14946
95c40f7Thanks @ematipico! - Removes theexperimental.cspflag and replaces it with a new configuration optionsecurity.csp- (v6 upgrade guidance)Patch Changes
#15473
d653b86Thanks @matthewp! - Improves error page loading to read from disk first before falling back to configured host#15562
e14a51dThanks @florian-lefebvre! - Updates to new Adapter API introduced in v6#15585
98ea30cThanks @matthewp! - Add a default body size limit for server actions to prevent oversized requests from exhausting memory.#15777
02e24d9Thanks @matthewp! - Fixes CSRF origin check mismatch by passing the actual server listening port tocreateRequest, ensuring the constructed URL origin includes the correct port (e.g.,http://localhost:4321instead ofhttp://localhost). Also restrictsX-Forwarded-Prototo only be trusted whenallowedDomainsis configured.#15714
9a2c949Thanks @ematipico! - Fixes an issue where static headers weren't correctly applied when the website usesbase.#15763
1567e8cThanks @matthewp! - Normalizes static file paths before evaluating dotfile access rules for improved consistency#15164
54dc11dThanks @HiDeoo! - Fixes an issue where the Node.js adapter could fail to serve a 404 page matching a pre-rendered dynamic route pattern.#15745
20b05c0Thanks @matthewp! - Hardens static file handler path resolution to ensure resolved paths stay within the client directory#15495
5b99e90Thanks @leekeh! - Refactors to usemiddlewareModeadapter feature (set toclassic)#15657
cb625b6Thanks @qzio! - Adds a newsecurity.actionBodySizeLimitoption to configure the maximum size of Astro Actions request bodies.This lets you increase the default 1 MB limit when your actions need to accept larger payloads. For example, actions that handle file uploads or large JSON payloads can now opt in to a higher limit.
If you do not set this option, Astro continues to enforce the 1 MB default to help prevent abuse.
Updated dependencies [
4ebc1e3,4e7f3e8,a164c77,cf6ea6b,a18d727,240c317,745e632]:Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.