Skip to content

fix(deps): update dependency astro to v5 [security] #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(deps): update dependency astro to v5 [security] #146

wants to merge 1 commit into from

Conversation

@svc-secops
Copy link
Contributor

@svc-secops svc-secops commented Oct 15, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
astro (source) 4.15.9 -> 5.14.3 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2024-47885

Summary

A DOM Clobbering gadget has been discoverd in Astro's client-side router. It can lead to cross-site scripting (XSS) in websites enables Astro's client-side routing and has stored attacker-controlled scriptless HTML elements (i.e., iframe tags with unsanitized name attributes) on the destination pages.

Details

Backgrounds

DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:

[1] https://scnps.co/papers/sp23_domclob.pdf
[2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/

Gadgets found in Astro

We identified a DOM Clobbering gadget in Astro's client-side routing module, specifically in the <ViewTransitions /> component. When integrated, this component introduces the following vulnerable code, which is executed during page transitions (e.g., clicking an <a> link):

https://github.com/withastro/astro/blob/7814a6cad15f06931f963580176d9b38aa7819f2/packages/astro/src/transitions/router.ts#L135-L156

However, this implementation is vulnerable to a DOM Clobbering attack. The document.scripts lookup can be shadowed by an attacker injected non-script HTML elements (e.g., <img name="scripts"><img name="scripts">) via the browser's named DOM access mechanism. This manipulation allows an attacker to replace the intended script elements with an array of attacker-controlled scriptless HTML elements.

The condition script.dataset.astroExec === '' on line 138 can be bypassed because the attacker-controlled element does not have a data-astroExec attribute. Similarly, the check on line 134 can be bypassed as the element does not require a type attribute.

Finally, the innerHTML of an attacker-injected non-script HTML elements, which is plain text content before, will be set to the .innerHTML of an script element that leads to XSS.

PoC

Consider a web application using Astro as the framework with client-side routing enabled and allowing users to embed certain scriptless HTML elements (e.g., form or iframe). This can be done through a bunch of website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.

For PoC website, please refer to: https://stackblitz.com/edit/github-4xgj2d. Clicking the "about" button in the menu will trigger an alert(1) from an attacker-injected form element.

---
import Header from "../components/Header.astro";
import Footer from "../components/Footer.astro";
import { ViewTransitions } from "astro:transitions";
import "../styles/global.css";
const { pageTitle } = Astro.props;
---
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>{pageTitle}</title>
    <ViewTransitions />
  </head>
  <body>
    <!--USER INPUT-->
    <iframe name="scripts">alert(1)</iframe>
    <iframe name="scripts">alert(1)</iframe>
    <!--USER INPUT-->
    
    <Header />
    <h1>{pageTitle}</h1>
    <slot />
    <Footer />
    <script>
      import "../scripts/menu.js";
    </script>
  </body>
</html>

Impact

This vulnerability can result in cross-site scripting (XSS) attacks on websites that built with Astro that enable the client-side routing with ViewTransitions and store the user-inserted scriptless HTML tags without properly sanitizing the name attributes on the page.

Patch

We recommend replacing document.scripts with document.getElementsByTagName('script') for referring to script elements. This will mitigate the possibility of DOM Clobbering attacks leveraging the name attribute.

Reference

Similar issues for reference:

CVE-2024-56140

Summary

A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks.

Details

When the security.checkOrigin configuration option is set to true, Astro middleware will perform a CSRF check. (Source code: https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts)

For example, with the following Astro configuration:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

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

A request like the following would be blocked if made from a different origin:

// fetch API or <form action="https://test.example.com/" method="POST">
fetch('https://test.example.com/', {
	method: 'POST',
	credentials: 'include',
	body: 'a=b',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
});
// => Cross-site POST form submissions are forbidden

However, a vulnerability exists that can bypass this security.

Pattern 1: Requests with a semicolon after the Content-Type

A semicolon-delimited parameter is allowed after the type in Content-Type.

Web browsers will treat a Content-Type such as application/x-www-form-urlencoded; abc as a simple request and will not perform preflight validation. In this case, CSRF is not blocked as expected.

fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: 'test',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded; abc' },
});
// => Server-side functions are executed (Response Code 200).

Pattern 2: Request without Content-Type header

The Content-Type header is not required for a request. The following examples are sent without a Content-Type header, resulting in CSRF.

// Pattern 2.1 Request without body
fetch('http://test.example.com', { method: 'POST', credentials: 'include' });

// Pattern 2.2 Blob object without type
fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: new Blob(['a=b'], {}),
});

Impact

Bypass CSRF protection implemented with CSRF middleware.

Note

Even with credentials: 'include', browsers may not send cookies due to third-party cookie blocking. This feature depends on the browser version and settings, and is for privacy protection, not as a CSRF measure.

CVE-2024-56159

Summary

A bug in the build process allows any unauthenticated user to read parts of the server source code.

Details

During build, along with client assets such as css and font files, the sourcemap files for the server code are moved to a publicly-accessible folder.
https://github.com/withastro/astro/blob/176fe9f113fd912f9b61e848b00bbcfecd6d5c2c/packages/astro/src/core/build/static-build.ts#L139

Any outside party can read them with an unauthorized HTTP GET request to the same server hosting the rest of the website.

While some server files are hashed, making their access obscure, the files corresponding to the file system router (those in src/pages) are predictably named. For example. the sourcemap file for src/pages/index.astro gets named dist/client/pages/index.astro.mjs.map.

PoC

Here is one example of an affected open-source website:
https://creatorsgarten.org/pages/index.astro.mjs.map

The file can be saved and opened using https://evanw.github.io/source-map-visualization/ to reconstruct the source code.

The above accurately mirrors the source code as seen in the repository: https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/index.astro

The above was found as the 4th result (and the first one on Astro 5.0+) when making the following search query on GitHub.com (search results link):

path:astro.config.mjs @&#8203;sentry/astro

This vulnerability is the root cause of https://github.com/withastro/astro/issues/12703, which links to a simple stackblitz project demonstrating the vulnerability. Upon build, notice the contents of the dist/client (referred to as config.build.client in astro code) folder. All astro servers make the folder in question accessible to the public internet without any authentication. It contains .map files corresponding to the code that runs on the server.

Impact

All server-output (SSR) projects on Astro 5 versions v5.0.3 through v5.0.6 (inclusive), that have sourcemaps enabled, either directly or through an add-on such as sentry, are affected. The fix for server-output projects was released in [email protected].

Additionally, all static-output (SSG) projects built using Astro 4 versions 4.16.17 or older, or Astro 5 versions 5.0.7 or older, that have sourcemaps enabled are also affected. The fix for static-output projects was released in [email protected], and backported to Astro v4 in [email protected].

The immediate impact is limited to source code. Any secrets or environment variables are not exposed unless they are present verbatim in the source code.

There is no immediate loss of integrity within the the vulnerable server. However, it is possible to subsequently discover another vulnerability via the revealed source code .

There is no immediate impact to availability of the vulnerable server. However, the presence of an unsafe regular expression, for example, can quickly be exploited to subsequently compromise the availability.

  • Network attack vector.
  • Low attack complexity.
  • No privileges required.
  • No interaction required from an authorized user.
  • Scope is limited to first party. Although the source code of closed-source third-party software may also be exposed.

Remediation

The fix for server-output projects was released in [email protected], and the fix for static-output projects was released in [email protected] and backported to Astro v4 in [email protected]. Users are advised to update immediately if they are using sourcemaps or an integration that enables sourcemaps.

CVE-2025-55303

Summary

In affected versions of astro, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served.

Details

On-demand rendered sites built with Astro include an /_image endpoint which returns optimized versions of images.

The /_image endpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using the image.domains or image.remotePatterns options).

However, a bug in impacted versions of astro allows an attacker to bypass the third-party domain restrictions by using a protocol-relative URL as the image source, e.g. /_image?href=//example.com/image.png.

Proof of Concept

  1. Create a new minimal Astro project ([email protected]).

  2. Configure it to use the Node adapter (@astrojs/[email protected] — newer versions are not impacted):

    // astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

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

  3. Build the site by running astro build.

  4. Run the server, e.g. with astro preview.

  5. Append /_image?href=//placehold.co/600x400 to the preview URL, e.g. http://localhost:4321/_image?href=//placehold.co/600x400

  6. The site will serve the image from the unauthorized placehold.co origin.

Impact

Allows a non-authorized third-party to create URLs on an impacted site’s origin that serve unauthorized image content.
In the case of SVG images, this could include the risk of cross-site scripting (XSS) if a user followed a link to a maliciously crafted SVG.

CVE-2025-61925

Summary

When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe.

Details

Astro reflects the value in X-Forwarded-Host in output when using Astro.url without any validation.

It is common for web servers such as nginx to route requests via the Host header, and forward on other request headers. As such as malicious request can be sent with both a Host header and an X-Forwarded-Host header where the values do not match and the X-Forwarded-Host header is malicious. Astro will then return the malicious value.

This could result in any usages of the Astro.url value in code being manipulated by a request. For example if a user follows guidance and uses Astro.url for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.

As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.

Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.

PoC

  • Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server
  • nvm use
  • yarn run build
  • node ./dist/server/entry.mjs
  • curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'
  • Observe that the response reflects the malicious X-Forwarded-Host header

For the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above curl request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.

Impact

This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.

DOM Clobbering Gadget found in astro's client-side router that leads to XSS

CVE-2024-47885 / GHSA-m85w-3h95-hcf9

More information

Details

Summary

A DOM Clobbering gadget has been discoverd in Astro's client-side router. It can lead to cross-site scripting (XSS) in websites enables Astro's client-side routing and has stored attacker-controlled scriptless HTML elements (i.e., iframe tags with unsanitized name attributes) on the destination pages.

Details
Backgrounds

DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:

[1] https://scnps.co/papers/sp23_domclob.pdf
[2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/

Gadgets found in Astro

We identified a DOM Clobbering gadget in Astro's client-side routing module, specifically in the <ViewTransitions /> component. When integrated, this component introduces the following vulnerable code, which is executed during page transitions (e.g., clicking an <a> link):

https://github.com/withastro/astro/blob/7814a6cad15f06931f963580176d9b38aa7819f2/packages/astro/src/transitions/router.ts#L135-L156

However, this implementation is vulnerable to a DOM Clobbering attack. The document.scripts lookup can be shadowed by an attacker injected non-script HTML elements (e.g., <img name="scripts"><img name="scripts">) via the browser's named DOM access mechanism. This manipulation allows an attacker to replace the intended script elements with an array of attacker-controlled scriptless HTML elements.

The condition script.dataset.astroExec === '' on line 138 can be bypassed because the attacker-controlled element does not have a data-astroExec attribute. Similarly, the check on line 134 can be bypassed as the element does not require a type attribute.

Finally, the innerHTML of an attacker-injected non-script HTML elements, which is plain text content before, will be set to the .innerHTML of an script element that leads to XSS.

PoC

Consider a web application using Astro as the framework with client-side routing enabled and allowing users to embed certain scriptless HTML elements (e.g., form or iframe). This can be done through a bunch of website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.

For PoC website, please refer to: https://stackblitz.com/edit/github-4xgj2d. Clicking the "about" button in the menu will trigger an alert(1) from an attacker-injected form element.

---
import Header from "../components/Header.astro";
import Footer from "../components/Footer.astro";
import { ViewTransitions } from "astro:transitions";
import "../styles/global.css";
const { pageTitle } = Astro.props;
---
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>{pageTitle}</title>
    <ViewTransitions />
  </head>
  <body>
    <!--USER INPUT-->
    <iframe name="scripts">alert(1)</iframe>
    <iframe name="scripts">alert(1)</iframe>
    <!--USER INPUT-->
    
    <Header />
    <h1>{pageTitle}</h1>
    <slot />
    <Footer />
    <script>
      import "../scripts/menu.js";
    </script>
  </body>
</html>
Impact

This vulnerability can result in cross-site scripting (XSS) attacks on websites that built with Astro that enable the client-side routing with ViewTransitions and store the user-inserted scriptless HTML tags without properly sanitizing the name attributes on the page.

Patch

We recommend replacing document.scripts with document.getElementsByTagName('script') for referring to script elements. This will mitigate the possibility of DOM Clobbering attacks leveraging the name attribute.

Reference

Similar issues for reference:

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Atro CSRF Middleware Bypass (security.checkOrigin)

CVE-2024-56140 / GHSA-c4pw-33h3-35xw

More information

Details

Summary

A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks.

Details

When the security.checkOrigin configuration option is set to true, Astro middleware will perform a CSRF check. (Source code: https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts)

For example, with the following Astro configuration:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

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

A request like the following would be blocked if made from a different origin:

// fetch API or <form action="https://test.example.com/" method="POST">
fetch('https://test.example.com/', {
	method: 'POST',
	credentials: 'include',
	body: 'a=b',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
});
// => Cross-site POST form submissions are forbidden

However, a vulnerability exists that can bypass this security.

Pattern 1: Requests with a semicolon after the Content-Type

A semicolon-delimited parameter is allowed after the type in Content-Type.

Web browsers will treat a Content-Type such as application/x-www-form-urlencoded; abc as a simple request and will not perform preflight validation. In this case, CSRF is not blocked as expected.

fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: 'test',
	headers: { 'Content-Type': 'application/x-www-form-urlencoded; abc' },
});
// => Server-side functions are executed (Response Code 200).
Pattern 2: Request without Content-Type header

The Content-Type header is not required for a request. The following examples are sent without a Content-Type header, resulting in CSRF.

// Pattern 2.1 Request without body
fetch('http://test.example.com', { method: 'POST', credentials: 'include' });

// Pattern 2.2 Blob object without type
fetch('https://test.example.com', {
	method: 'POST',
	credentials: 'include',
	body: new Blob(['a=b'], {}),
});
Impact

Bypass CSRF protection implemented with CSRF middleware.

[!Note]
Even with credentials: 'include', browsers may not send cookies due to third-party cookie blocking. This feature depends on the browser version and settings, and is for privacy protection, not as a CSRF measure.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Astro's server source code is exposed to the public if sourcemaps are enabled

CVE-2024-56159 / GHSA-49w6-73cw-chjr

More information

Details

Summary

A bug in the build process allows any unauthenticated user to read parts of the server source code.

Details

During build, along with client assets such as css and font files, the sourcemap files for the server code are moved to a publicly-accessible folder.
https://github.com/withastro/astro/blob/176fe9f113fd912f9b61e848b00bbcfecd6d5c2c/packages/astro/src/core/build/static-build.ts#L139

Any outside party can read them with an unauthorized HTTP GET request to the same server hosting the rest of the website.

While some server files are hashed, making their access obscure, the files corresponding to the file system router (those in src/pages) are predictably named. For example. the sourcemap file for src/pages/index.astro gets named dist/client/pages/index.astro.mjs.map.

PoC

Here is one example of an affected open-source website:
https://creatorsgarten.org/pages/index.astro.mjs.map

The file can be saved and opened using https://evanw.github.io/source-map-visualization/ to reconstruct the source code.

The above accurately mirrors the source code as seen in the repository: https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/index.astro

The above was found as the 4th result (and the first one on Astro 5.0+) when making the following search query on GitHub.com (search results link):

path:astro.config.mjs @&#8203;sentry/astro

This vulnerability is the root cause of https://github.com/withastro/astro/issues/12703, which links to a simple stackblitz project demonstrating the vulnerability. Upon build, notice the contents of the dist/client (referred to as config.build.client in astro code) folder. All astro servers make the folder in question accessible to the public internet without any authentication. It contains .map files corresponding to the code that runs on the server.

Impact

All server-output (SSR) projects on Astro 5 versions v5.0.3 through v5.0.6 (inclusive), that have sourcemaps enabled, either directly or through an add-on such as sentry, are affected. The fix for server-output projects was released in [email protected].

Additionally, all static-output (SSG) projects built using Astro 4 versions 4.16.17 or older, or Astro 5 versions 5.0.7 or older, that have sourcemaps enabled are also affected. The fix for static-output projects was released in [email protected], and backported to Astro v4 in [email protected].

The immediate impact is limited to source code. Any secrets or environment variables are not exposed unless they are present verbatim in the source code.

There is no immediate loss of integrity within the the vulnerable server. However, it is possible to subsequently discover another vulnerability via the revealed source code .

There is no immediate impact to availability of the vulnerable server. However, the presence of an unsafe regular expression, for example, can quickly be exploited to subsequently compromise the availability.

  • Network attack vector.
  • Low attack complexity.
  • No privileges required.
  • No interaction required from an authorized user.
  • Scope is limited to first party. Although the source code of closed-source third-party software may also be exposed.
Remediation

The fix for server-output projects was released in [email protected], and the fix for static-output projects was released in [email protected] and backported to Astro v4 in [email protected]. Users are advised to update immediately if they are using sourcemaps or an integration that enables sourcemaps.

Severity

  • CVSS Score: Unknown
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:L/SA:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Astro allows unauthorized third-party images in _image endpoint

CVE-2025-55303 / GHSA-xf8x-j4p2-f749

More information

Details

Summary

In affected versions of astro, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served.

Details

On-demand rendered sites built with Astro include an /_image endpoint which returns optimized versions of images.

The /_image endpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using the image.domains or image.remotePatterns options).

However, a bug in impacted versions of astro allows an attacker to bypass the third-party domain restrictions by using a protocol-relative URL as the image source, e.g. /_image?href=//example.com/image.png.

Proof of Concept

  1. Create a new minimal Astro project ([email protected]).

  2. Configure it to use the Node adapter (@astrojs/[email protected] — newer versions are not impacted):

    // astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

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

  3. Build the site by running astro build.

  4. Run the server, e.g. with astro preview.

  5. Append /_image?href=//placehold.co/600x400 to the preview URL, e.g. http://localhost:4321/_image?href=//placehold.co/600x400

  6. The site will serve the image from the unauthorized placehold.co origin.

Impact

Allows a non-authorized third-party to create URLs on an impacted site’s origin that serve unauthorized image content.
In the case of SVG images, this could include the risk of cross-site scripting (XSS) if a user followed a link to a maliciously crafted SVG.

Severity

  • CVSS Score: Unknown
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Astro's X-Forwarded-Host is reflected without validation

CVE-2025-61925 / GHSA-5ff5-9fcw-vg88

More information

Details

Summary

When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe.

Details

Astro reflects the value in X-Forwarded-Host in output when using Astro.url without any validation.

It is common for web servers such as nginx to route requests via the Host header, and forward on other request headers. As such as malicious request can be sent with both a Host header and an X-Forwarded-Host header where the values do not match and the X-Forwarded-Host header is malicious. Astro will then return the malicious value.

This could result in any usages of the Astro.url value in code being manipulated by a request. For example if a user follows guidance and uses Astro.url for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.

As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.

Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.

PoC
  • Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server
  • nvm use
  • yarn run build
  • node ./dist/server/entry.mjs
  • curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'
  • Observe that the response reflects the malicious X-Forwarded-Host header

For the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above curl request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.

Impact

This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

withastro/astro (astro)

v5.14.3

Compare Source

Patch Changes

  • #​14505 28b2a1d Thanks @​matthewp! - Fixes Cannot set property manifest error in test utilities by adding a protected setter for the manifest property

  • #​14235 c4d84bb Thanks @​toxeeec! - Fixes a bug where the "tap" prefetch strategy worked only on the first clicked link with view transitions enabled

v5.14.1

Compare Source

Patch Changes

v5.14.0

Compare Source

Minor Changes

  • #​13520 a31edb8 Thanks @​openscript! - Adds a new property routePattern available to GetStaticPathsOptions

    This provides the original, dynamic segment definition in a routing file path (e.g. /[...locale]/[files]/[slug]) from the Astro render context that would not otherwise be available within the scope of getStaticPaths(). This can be useful to calculate the params and props for each page route.

    For example, you can now localize your route segments and return an array of static paths by passing routePattern to a custom getLocalizedData() helper function. The params object will be set with explicit values for each route segment (e.g. locale, files, and slug). Then, these values will be used to generate the routes and can be used in your page template via Astro.params.

v5.13.11

Compare Source

Patch Changes

  • #​14409 250a595 Thanks @​louisescher! - Fixes an issue where astro info would log errors to console in certain cases.

  • #​14398 a7df80d Thanks @​idawnlight! - Fixes an unsatisfiable type definition when calling addServerRenderer on an experimental container instance

  • #​13747 120866f Thanks @​jp-knj! - Adds automatic request signal abortion when the underlying socket closes in the Node.js adapter

    The Node.js adapter now automatically aborts the request.signal when the client connection is terminated. This enables better resource management and allows applications to properly handle client disconnections through the standard AbortSignal API.

  • #​14428 32a8acb Thanks @​drfuzzyness! - Force sharpService to return a Uint8Array if Sharp returns a SharedArrayBuffer

  • #​14411 a601186 Thanks @​GameRoMan! - Fixes relative links to docs that could not be opened in the editor.

v5.13.10

Compare Source

Patch Changes

v5.13.9

Compare Source

Patch Changes

v5.13.8

Compare Source

Patch Changes

  • #​14300 bd4a70b Thanks @​louisescher! - Adds Vite version & integration versions to output of astro info

  • #​14341 f75fd99 Thanks @​delucis! - Fixes support for declarative Shadow DOM when using the <ClientRouter> component

  • #​14350 f59581f Thanks @​ascorbic! - Improves error reporting for content collections by adding logging for configuration errors that had previously been silently ignored. Also adds a new error that is thrown if a live collection is used in content.config.ts rather than live.config.ts.

  • #​14343 13f7d36 Thanks @​florian-lefebvre! - Fixes a regression in non node runtimes

v5.13.7

Compare Source

Patch Changes

v5.13.6

Compare Source

Patch Changes

v5.13.5

Compare Source

Patch Changes

  • #​14286 09c5db3 Thanks @​ematipico! - BREAKING CHANGES only to the experimental CSP feature

    The following runtime APIs of the Astro global have been renamed:

    • Astro.insertDirective to Astro.csp.insertDirective
    • Astro.insertStyleResource to Astro.csp.insertStyleResource
    • Astro.insertStyleHash to Astro.csp.insertStyleHash
    • Astro.insertScriptResource to Astro.csp.insertScriptResource
    • Astro.insertScriptHash to Astro.csp.insertScriptHash

    The following runtime APIs of the APIContext have been renamed:

    • ctx.insertDirective to ctx.csp.insertDirective
    • ctx.insertStyleResource to ctx.csp.insertStyleResource
    • ctx.insertStyleHash to ctx.csp.insertStyleHash
    • ctx.insertScriptResource to ctx.csp.insertScriptResource
    • ctx.insertScriptHash to ctx.csp.insertScriptHash

  • #​14283 3224637 Thanks @​ematipico! - Fixes an issue where CSP headers were incorrectly injected in the development server.

  • #​14275 3e2f20d Thanks @​florian-lefebvre! - Adds support for experimental CSP when using experimental fonts

    Experimental fonts now integrate well with experimental CSP by injecting hashes for the styles it generates, as well as font-src directives.

    No action is required to benefit from it.

  • #​14280 4b9fb73 Thanks @​ascorbic! - Fixes a bug that caused cookies to not be correctly set when using middleware sequences

  • #​14276 77281c4 Thanks @​ArmandPhilippot! - Adds a missing export for resolveSrc, a documented image services utility.

v5.13.4

Compare Source

Patch Changes

  • #​14260 86a1e40 Thanks @​jp-knj! - Fixes Astro.url.pathname to respect trailingSlash: 'never' configuration when using a base path. Previously, the root path with a base would incorrectly return /base/ instead of /base when trailingSlash was set to 'never'.

  • #​14248 e81c4bd Thanks @​julesyoungberg! - Fixes a bug where actions named 'apply' do not work due to being a function prototype method.

v5.13.3

Compare Source

Patch Changes

  • #​14239 d7d93e1 Thanks @​wtchnm! - Fixes a bug where the types for the live content collections were not being generated correctly in dev mode

  • #​14221 eadc9dd Thanks @​delucis! - Fixes JSON schema support for content collections using the file() loader

  • #​14229 1a9107a Thanks @​jonmichaeldarby! - Ensures Astro.currentLocale returns the correct locale during SSG for pages that use a locale param (such as [locale].astro or [locale]/index.astro, which produce [locale].html)

v5.13.2

Compare Source

Patch Changes

v5.13.1

Compare Source

Patch Changes

  • #​14409 250a595 Thanks @​louisescher! - Fixes an issue where astro info would log errors to console in certain cases.

  • #​14398 a7df80d Thanks @​idawnlight! - Fixes an unsatisfiable type definition when calling addServerRenderer on an experimental container instance

  • #​13747 120866f Thanks @​jp-knj! - Adds automatic request signal abortion when the underlying socket closes in the Node.js adapter

    The Node.js adapter now automatically aborts the request.signal when the client connection is terminated. This enables better resource management and allows applications to properly handle client disconnections through the standard AbortSignal API.

  • #​14428 32a8acb Thanks @​drfuzzyness! - Force sharpService to return a Uint8Array if Sharp returns a SharedArrayBuffer

  • #​14411 a601186 Thanks @​GameRoMan! - Fixes relative links to docs that could not be opened in the editor.

v5.13.0

Compare Source

Minor Changes

Configuration

📅 Schedule: Branch creation - "" in timezone America/Los_Angeles, Automerge - "after 8am and before 4pm on tuesday" in timezone America/Los_Angeles.

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

This PR has been generated by Renovate Bot.

@svc-secops svc-secops enabled auto-merge (squash) October 15, 2024 12:11
@changeset-bot
Copy link

changeset-bot bot commented Oct 15, 2024 •
edited
Loading

⚠️ No Changeset found

Latest commit: c57a02a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@netlify
Copy link

netlify bot commented Oct 15, 2024 •
edited
Loading

❌ Deploy Preview for graphql-testing-library failed.

Name Link
🔨 Latest commit c57a02a
🔍 Latest deploy log https://app.netlify.com/projects/graphql-testing-library/deploys/68ea680b773b810008bc46c3

@svc-secops svc-secops force-pushed the renovate/npm-astro-vulnerability branch from 73f1742 to 62f7b79 Compare December 19, 2024 13:54
@svc-secops svc-secops changed the title fix(deps): update dependency astro to v4.16.1 [security] fix(deps): update dependency astro to v4.16.17 [security] Dec 19, 2024
@svc-secops svc-secops force-pushed the renovate/npm-astro-vulnerability branch from 62f7b79 to 3d7d4f4 Compare December 20, 2024 12:03
@svc-secops svc-secops changed the title fix(deps): update dependency astro to v4.16.17 [security] fix(deps): update dependency astro to v4.16.18 [security] Dec 20, 2024
@svc-secops svc-secops force-pushed the renovate/npm-astro-vulnerability branch from 3d7d4f4 to cb2f556 Compare August 21, 2025 13:47
@svc-secops svc-secops changed the title fix(deps): update dependency astro to v4.16.18 [security] fix(deps): update dependency astro to v4.16.19 [security] Aug 21, 2025
@svc-secops svc-secops force-pushed the renovate/npm-astro-vulnerability branch from cb2f556 to c57a02a Compare October 11, 2025 14:22
@svc-secops svc-secops changed the title fix(deps): update dependency astro to v4.16.19 [security] fix(deps): update dependency astro to v5 [security] Oct 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

🎄 dependencies vulnerability

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@svc-secops