Skip to content

build(deps): update dependency astro to v7 [security] - #26

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-astro-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-astro-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jul 21, 2026 •

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
astro (source) ^6.1.5 → ^7.0.0 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


Astro: Reflected XSS via unescaped View Transition animation properties

CVE-2026-73422 / GHSA-4g3v-8h47-v7g6

More information

Details

Summary

Astro's server-side View Transition CSS generator interpolates animation properties into an inline <style> element without escaping them for the CSS and HTML contexts.

An attacker-controlled value passed to an animation property such as duration can contain a </style> sequence, terminate the generated style element, and inject arbitrary HTML or JavaScript.

This is similar to GHSA-8hv8-536x-4wqp, but exploits a different injection point: unescaped View Transition animation values in a server-generated <style> element rather than an unescaped slot name in a hydration template.

Like GHSA-8hv8-536x-4wqp, exploitation requires an application to pass attacker-controlled data to an Astro API. However, the value is subsequently inserted into the HTML response without context-appropriate escaping by Astro.

Details

packages/astro/src/runtime/server/transition.ts

The generated stylesheet is wrapped in a <style> element and marked as HTML-safe:

const css = sheet.toString();
result._metadata.extraHead.push(markHTMLString(`<style>${css}</style>`));

Animation properties are added to the stylesheet without escaping:

if (anim.duration) {
  addAnimationProperty(builder, 'animation-duration', toTimeValue(anim.duration));
}

For string values, toTimeValue() returns the input unchanged:

export function toTimeValue(num: number | string) {
  return typeof num === 'number' ? num + 'ms' : num;
}

As a result, a duration value containing </style> can escape from the generated style element.

Other TransitionAnimation properties, including easing, direction, delay, fillMode, and name, are serialized by the same animation builder. The following PoC only relies on the official fade() helper and its duration option.

PoC

Using:

  • astro@7.0.9
  • @astrojs/node@11.0.2
astro.config.mjs
import node from '@astrojs/node';
import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});
src/pages/index.astro
---
import { fade } from 'astro:transitions';

const duration = Astro.url.searchParams.get('duration') ?? '300ms';
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>PoC</title>
  </head>
  <body>
    <div transition:animate={fade({ duration })}>
      Animated content
    </div>
  </body>
</html>
Payload:

open:

http://localhost:4321/?duration=%3C%2Fstyle%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C!--

The browser interprets </style> as the end of the generated style element and executes the injected script. An alert dialog is displayed when the page is opened.

image
Impact

An attacker who can control a View Transition animation value can execute arbitrary JavaScript in the origin of the affected Astro application.

The query-based reflected XSS scenario affects on-demand/server-rendered routes, such as:

  • projects configured with output: "server";
  • pages using export const prerender = false;
  • other server-side data flows that pass attacker-controlled values into a View Transition animation definition.

Successful exploitation may allow access to sensitive page data and authenticated actions available to the victim.

Suggested Fix

Animation values should be serialized using context-appropriate CSS escaping or validation before being added to the generated stylesheet.

Additionally, content inserted into a raw <style> element must not be able to contain an HTML end-tag sequence such as </style>. The final generated CSS should be made safe for the HTML raw-text context before it is passed to markHTMLString().

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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


Astro: Cross-site scripting via unescaped transition:* directive values on hydrated islands

CVE-2026-59727 / GHSA-7pw4-f3q4-r2p2

More information

Details

Summary

When a transition:persist, transition:scope, or transition:persist-props directive is applied to a client-hydrated (client:*) component, Astro copied the directive value onto the rendered <astro-island> element without HTML-escaping it. If a developer reflects attacker-controlled input into one of these directives, an attacker can break out of the attribute and inject arbitrary HTML/JavaScript into the server-rendered output, resulting in reflected cross-site scripting (XSS).

Severity

Although a generic reflected XSS scores in the Medium range, exploitation here requires the application developer to have written a non-idiomatic pattern — passing untrusted, request-derived input directly into a transition directive. Astro applications that do not route untrusted input into these directives are unaffected. This mitigating precondition places the real-world severity at Low.

Details

In generateHydrateScript() (packages/astro/src/runtime/server/hydration.ts), every island property is HTML-escaped before serialization — the attrs, props, and opts assignments all pass through escapeHTML(). The transition directives, however, were copied verbatim:

transitionDirectivesToCopyOnIsland.forEach((name) => {
  if (typeof props[name] !== 'undefined') {
    island.props[name] = props[name]; // not escaped
  }
});

The <astro-island> element is serialized via renderElement('astro-island', island, false) with shouldEscape=false, and toAttributeString() returns the value unchanged in that mode. As a result there is no downstream re-escaping, and the raw directive value reaches the HTML response. This is the same output sink previously addressed for slot names in GHSA-8hv8-536x-4wqp.

The affected directives are:

  • data-astro-transition-scope (transition:scope)
  • data-astro-transition-persist (transition:persist)
  • data-astro-transition-persist-props (transition:persist-props)

Note that transition:persist is typed boolean | string, so passing a string value is a supported use of the API.

Proof of Concept

A component that reflects a query parameter into a transition directive:

---
const persist = Astro.url.searchParams.get('persist') ?? 'default';
---
<Island client:load transition:persist={persist} />

Request:

https://example.com/?persist="><img src=x onerror=alert(document.domain)>

Rendered output (before the fix):

<astro-island … data-astro-transition-persist=""><img src=x onerror=alert(document.domain)>></astro-island>

The " closes the attribute and the injected <img onerror=…> executes in the victim's browser.

Impact

Reflected XSS. An attacker who can induce a victim to visit a crafted URL can execute arbitrary script in the victim's session on the origin, subject to the requirement that the target application reflects untrusted input into one of the affected transition directives.

Affected Versions

astro >= 3.10.0, < 7.0.4 (introduced in 3.10.0, PR #​7861).

Patched Versions

astro >= 7.0.4. Fixed in PR #​17212 by HTML-escaping transition directive values before they are rendered onto the island element.

Workarounds

Do not pass untrusted or request-derived input into transition:persist, transition:scope, or transition:persist-props. If such input is required, HTML-escape or strictly validate it before passing it to the directive. Upgrading to astro@7.0.4 or later removes the need for manual mitigation.

Credits

Reported by @​jlgore.

Severity

  • CVSS Score: 2.1 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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


Astro: XSS via unescaped spread attribute names in renderHTMLElement (incomplete fix for CVE-2026-54298)

CVE-2026-59729 / GHSA-f48w-9m4c-m7f5

More information

Details

Summary

The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an INVALID_ATTR_NAME_CHAR guard to addAttribute() so that spread-prop attribute names containing "' >/= or whitespace are dropped. A second attribute-rendering path, renderHTMLElement() in packages/astro/src/runtime/server/render/dom.ts, has its own inline attribute loop that does not go through addAttribute() and was not updated. It interpolates the attribute name unescaped and only escapes the value, so untrusted prop keys spread onto a native-HTMLElement-subclass component can still break out of the attribute context, resulting in XSS.

Details

renderHTMLElement builds attributes directly:

for (const attr in props) {
  attrHTML += ` ${attr}="${toAttributeString(await props[attr])}"`;
}

The attribute name (attr) is interpolated raw; only the value is escaped via toAttributeString. By contrast, the hardened addAttribute in util.ts rejects invalid names:

if (INVALID_ATTR_NAME_CHAR.test(key)) { return ''; } // /[\s"'>/=]/

renderHTMLElement is reached from component.ts when the component is a native HTMLElement subclass:

if (!renderer && typeof HTMLElement === 'function' && componentIsHTMLElement(Component)) {
  const output = await renderHTMLElement(result, Component, _props, slots);
}

where _props carries spread props verbatim.

Reachability

The branch only runs when typeof HTMLElement === 'function' at SSR time. In default Node SSR HTMLElement is undefined, so the branch is dead. It becomes reachable when the SSR runtime exposes a global HTMLElement (Deno, Bun with a DOM shim, or jsdom/happy-dom in Node) and a class extending HTMLElement is used directly as an Astro component that receives untrusted-keyed spread props.

Proof of Concept

Given malicious spread props:

const maliciousProps = {
  'onmouseover=alert(document.domain) x': 'y',
  'x><script>alert(1)</script>': 'z',
};
  • addAttribute (post-fix) → <my-el></my-el> (key stripped — safe)
  • renderHTMLElement → <my-el onmouseover=alert(document.domain) x="y" x><script>alert(1)</script>="z"></my-el> (handler + <script> injected — XSS)

Equivalent Astro template, served by an SSR runtime that defines a global HTMLElement:

---
import MyElement from '../MyElement.js'; // class MyElement extends HTMLElement {}
const userInput = Astro.url.searchParams;  // untrusted keys
---
<MyElement {...Object.fromEntries(userInput)} />
Impact

Cross-site scripting (CWE-79) via attribute-name breakout — the same vulnerability class as CVE-2026-54298, in a code path its fix did not cover. An attacker who controls the keys of an object spread onto a native-HTMLElement-subclass component can inject arbitrary event-handler attributes or sibling elements (including <script>) into the SSR output. Reachability is constrained by the runtime and component preconditions described above.

Severity

  • CVSS Score: 5.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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


Astro: Remote code execution through AVIF image optimization

GHSA-26w7-cxv4-gfx2

More information

Details

A vulnerability in libheif, used by the default Sharp image service in Astro, can lead to remote code execution when a malicious AVIF image is optimized.

Projects are affected when an attacker can cause Astro to process an untrusted AVIF image.

The fix was released in Astro 7.2.8, which requires Sharp 0.35.4.

Severity

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

References

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


Astro: Authorization bypass from missing path-segment boundary check when stripping the configured base

CVE-2026-84376 / GHSA-376h-93r7-7g6f

More information

Details

Summary

Astro stripped a configured base path from request pathnames using a string-prefix check that did not verify a path-segment boundary. With base: "/app", a request to /appX/admin was treated as being under the base and resolved internally to the /admin route, while middleware still observed the public pathname /appX/admin. Middleware that authorizes routes by inspecting context.url.pathname could therefore be bypassed.

Impact

An unauthenticated remote attacker can bypass pathname-based middleware authorization in applications that:

  • Configure a non-root base.
  • Protect base-prefixed routes in middleware using context.url.pathname.

Because routing and middleware resolved different effective pathnames, a request such as /appX/admin (or other single-character extensions like /app2/admin or /app-/admin) reached the protected /admin route without passing the middleware check that guards /app/admin. Astro's authentication guide demonstrates protecting routes in middleware via context.url.pathname, so this is a reasonable and expected pattern.

Affected versions

astro <= 7.2.3.

Patches

Fixed in astro 7.2.4. Base stripping now requires the pathname to equal the base without its trailing slash, or to be followed by a /, so a prefix that does not end on a path-segment boundary is no longer treated as being under the base. Routing and context.url.pathname now resolve the same pathname.

Workarounds

Upgrade to astro 7.2.4 or later. As a mitigation before upgrading, avoid relying solely on prefix checks of context.url.pathname for authorization, or reject requests whose pathname does not begin with the configured base followed by a path-segment boundary.

Credits

Reported by @​Ryoga-exe.

Severity

  • CVSS Score: 6.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

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


Astro: Reflected/Stored XSS via unescaped <script>/<style> tag content in JSX/MDX rendering

CVE-2026-114128 / GHSA-98hj-9722-w3j8

More information

Details

Summary

Astro's JSX and MDX rendering pipeline treated string children of <script> and <style> elements as trusted HTML. When a dynamic value was passed through a JSX expression, such as <script>{value}</script>, an attacker-controlled value containing </script> or </style> could terminate the element and inject arbitrary HTML and JavaScript.

Other JSX expression contexts escaped dynamic strings automatically. This behavior was limited to <script> and <style> children rendered through Astro's astro:jsx renderer, including MDX components.

Details

The affected rendering paths marked all string children of <script> and <style> elements as safe HTML, without distinguishing literal content generated by the compiler from dynamic expression values. An application was vulnerable when attacker-controlled data, such as a query parameter or CMS field, was interpolated directly into one of these elements.

For example, a value containing </script><script>alert(1)</script> passed to <script>{value}</script> was emitted without escaping. The browser interpreted the first closing tag as markup and executed the injected script.

The fix preserves raw rendering for literal script and style content while escaping dynamic string children like other JSX expression values.

Impact

Affected applications could be vulnerable to reflected or stored cross-site scripting. Exploitation required an application to pass attacker-controlled data directly as a dynamic child of a <script> or <style> element in MDX or through the astro:jsx runtime. Successful exploitation allowed arbitrary JavaScript execution in the victim's browser under the application's origin.

Patches

This issue is patched in astro@7.3.2.

Workarounds

Do not interpolate untrusted dynamic values directly into <script> or <style> element children. Applications that cannot upgrade should validate and contextually encode these values before rendering them.

Credit

Reported by @​RKasai127.

Severity

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

References

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


Astro: Image endpoint in @​astrojs/node can read files from a case-variant sibling of the output directory on case-sensitive filesystems

CVE-2026-126364 / GHSA-r3h5-4585-7x3w

More information

Details

Summary

The /_image endpoint used by the @astrojs/node adapter checks that a requested local image is inside the build output directory before reading it from disk. That check compared paths case-insensitively. On case-sensitive filesystems (such as Linux), a directory whose path differs from the output directory only by letter case is a different directory, but it passed the check.

For example, with the client output directory at /srv/app/dist/client/, a request such as:

/_image?href=/../../DIST/client/secret.png&w=32&f=png

resolved to /srv/app/DIST/client/secret.png and was served, even though that file is outside the output directory.

Impact

An unauthenticated attacker can read image files from outside the output directory, but only when all of the following are true:

  • The site uses on-demand rendering with the @astrojs/node adapter.
  • The server runs on a case-sensitive filesystem.
  • A directory exists whose path matches the output directory except for letter case (for example DIST/client next to dist/client). Such a layout is unusual, and the attacker cannot create it.

Only files the image service accepts can be read. Raster images are returned after resizing; SVG files are returned unchanged. Other file types fail during processing. Plain path traversal outside the output directory (for example /../../secret.png) was already rejected and is not affected.

Affected versions

astro >= 5.14.3, <= 7.4.6, when used with @astrojs/node (all versions up to 11.1.11). The vulnerable image endpoint is provided by astro and used by the @astrojs/node adapter.

Patches

Fixed in astro 7.4.7. The path check now compares paths exactly, and only ignores letter case for Windows drive-letter paths. The fix ships in astro, so upgrading @astrojs/node alone is not enough.

Workarounds

Upgrade to astro 7.4.7 or later. Before upgrading, make sure no directory next to the build output directory has a path that differs from it only by letter case.

Credits

Reported by @​zachariah-mithani.

Severity

  • CVSS Score: 6.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

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


Astro: XSS via attribute injection in dynamic tag names

CVE-2026-126361 / GHSA-mh32-jxcr-mh9f

More information

Details

Summary

When a dynamic tag (const Tag = ...; <Tag />) resolves to a string, Astro renders it as a raw HTML element name. The name was filtered to remove characters that could inject attributes, but the filter did not handle /. Because HTML parsers treat / inside a tag as an attribute separator, a tag name such as img/src/onerror=alert(1) was rendered as an <img> element with an onerror attribute. The JSX renderer used for MDX did not filter string tag names at all.

For example:

---
const Tag = Astro.url.searchParams.get('as') ?? 'div';
---
<Tag>hello</Tag>

rendered ?as=img/src/onerror=alert(1) as live HTML.

Impact

Reflected or stored cross-site scripting, but only in applications that use untrusted input (such as a request parameter or an uncontrolled CMS field) as all or part of an element name. Astro itself never derives element names from request data.

Applications that let content choose an element should map that input to a fixed set of known tags. Letting untrusted input choose an element name is unsafe even with a correct filter, because it can still select elements such as script or iframe.

Affected versions

astro <= 7.4.4.

Patches

Fixed in astro 7.4.5. String tag names in .astro dynamic tags, JSX, and MDX now render only the leading valid element name, so characters such as / or = can no longer change the generated markup. Strings that do not start with a valid element name now throw an error.

Workarounds

Upgrade to astro 7.4.5 or later. Before upgrading, do not use untrusted input as an element name, or map it to a fixed set of known tags.

Credits

Reported by @​uttej-badwane.

Severity

  • CVSS Score: 2.3 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

References

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


Release Notes

withastro/astro (astro)

v7.4.12

Compare Source

Patch Changes

v7.4.11

Compare Source

Patch Changes
  • #​18641 08e2cee Thanks @​astro-factory! - Validates the protocol, host and port from X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-Port together against each security.allowedDomains entry, instead of one at a time:

    • A forwarded protocol is only applied when an entry allows it for the host in use.
    • A forwarded port is only applied when the entry for that host lists it.
    • A forwarded host without a forwarded protocol is validated with the protocol of the server.
    • An entry with port: '443' (or '80' for http) now matches a host that doesn't include a port.
  • #​18651 93a9057 Thanks @​umeraamir69! - Returns 400 Bad Request for malformed percent-encoded paths in the dev server and static preview instead of bubbling into a 500

  • #​18672 e901468 Thanks @​astro-factory! - Fixes astro check reporting @astrojs/check as missing when the package is installed but throws while loading. The original error is now shown instead of an install prompt.

  • #​18641 08e2cee Thanks @​astro-factory! - Fixes security.allowedDomains accepting non-HTTP(S) X-Forwarded-Proto values (such as ftp or ws) when the list mixes patterns with and without a protocol

  • #​18686 62bb716 Thanks @​astro-factory! - Fixes astro build deleting the license file generated by Vite's build.license option. Astro now removes only its own Vite manifest from the .vite/ output folder.

  • #​18629 e9916e1 Thanks @​decrek! - Fixes spreading an object onto an element with scoped styles changing that object. When the same object was spread on every render, for example a constant imported from another module, its class grew with every request.

  • #​18641 08e2cee Thanks @​astro-factory! - Tightens how security.allowedDomains validates the Host and X-Forwarded-Host headers. Only a plain hostname with an optional port is accepted, and the validated host is applied to Astro.url exactly as it was matched.

  • Updated dependencies [d13beeb, e9916e1]:

v7.4.10

Compare Source

Patch Changes

v7.4.9

Compare Source

Patch Changes
  • #​18681 bf1828b Thanks @​astro-factory! - Fixes static builds skipping or failing on pages whose getStaticPaths() params contain characters like % or \, and warns when a prerendered page is skipped because it returned an empty error response

  • #​18630 c904827 Thanks @​astro-factory! - Fixes bundled scripts and hydrated islands being blocked when security.csp.scriptDirective.strictDynamic is enabled. Astro now adds the hash of every bundled script to script-src and renders an import map with their integrity in the <head>.

  • #​18611 f98e8a8 Thanks @​matthewp! - Fixes bundling of a <script src> that uses a root-relative path to a project file outside src/, such as /lib/analytics.ts. The error asking for is:inline is now shown only when the path points to a file in public/.

  • #​18688 1999c84 Thanks @​astro-factory! - Fixes errors thrown after a page has started streaming bypassing the configured logger. They are now reported once through it, as one error record, in both production and astro dev

  • Updated dependencies [c904827, 5083c65, 1999c84, 5083c65, f98e8a8, f98e8a8]:

v7.4.8

Compare Source

Patch Changes

v7.4.7

Compare Source

Patch Changes

v7.4.6

Compare Source

Patch Changes
  • #​18565 cd09986 Thanks @​praveen-kumary! - Avoids attributing client-only components or scripts to unrelated pages importing astro:i18n by bounding top-level page graph traversal at virtual page entries

  • #​18608 babd96d Thanks @​umeraamir69! - Fixes an extra page reload on the first page load after starting astro dev without an existing .astro directory

  • #​18589 402c0fa Thanks @​astro-factory! - Fixes astro check exiting with code 0 when @astrojs/check or typescript is not installed. The command now exits with code 1 so CI fails instead of silently skipping type checking.

  • #​18503 54fcdd5 Thanks @​SwastikTripathi! - Preserves the last-modified date of cached font files and unchanged public files when copying them into the build output. Public-file timestamp preservation respects the resolved public-directory configuration, follows source symlinks, and avoids backdating files overwritten by build plugins.

  • #​18605 76cd239 Thanks @​astro-factory! - Fixes the glob() loader adding files from a folder excluded with a negation pattern such as !_docs when they change during astro dev

  • #​18432 ed60d82 Thanks @​alexmv! - Improves the MissingSharp error to include the reason Sharp failed to load, such as its prebuilt binaries not supporting the current CPU

  • #​18474 59543c3 Thanks @​miottid! - Fixes i18n fallback for on-demand rendered pages. A locale-prefixed request for a page that only exists in the fallback locale (for example /de/about with fallback: { de: 'en' }) was answered with status 302 and no Location header. Such requests are now rewritten or redirected to the fallback locale according to i18n.routing.fallbackType, including encoded paths and sites with a configured base. Query strings are preserved, and explicit page statuses and redirects are left unchanged.

  • #​18541 cfa2d2b Thanks @​ump45nose! - Fixes matchAllRoutes to consider fallbackRoutes, matching matchRoute and the production router. Dev-server i18n fallback requests now resolve to the source route's metadata instead of the 404 route, and SSR-only fallback candidates can fall through the prerender handler.

  • #​18602 d856064 Thanks @​astro-factory! - Fixes astro check losing the end of its output, including the Result summary, when stdout is piped to a slow reader. When the reader closes the pipe early, for example astro check | head, astro check now exits with code 1 instead of crashing with an EPIPE stack trace.

  • #​18574 da0f149 Thanks @​astro-factory! - Fixes an unnecessary full page reload in astro dev when a content loader calls store.clear() or store.delete() and the content store has no asset imports

  • #​18570 e71c038 Thanks @​astro-factory! - Fixes pages using <ClientRouter /> briefly showing the top of the page on reload before jumping back to the previous scroll position. Full reloads now use the browser's native scroll restoration.

  • #​18531 f75553b Thanks @​praveen-kumary! - Fixes an unhandled TypeError: Cannot convert undefined or null to object when calling route.generate() without arguments on static routes

v7.4.5

Compare Source

Patch Changes

[!IMPORTANT]
✂ PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 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.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@vercel

vercel Bot commented Jul 21, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
rfdf Error Error Nov 13, 2026 8:03pm UTC

@greptile-apps

greptile-apps Bot commented Jul 21, 2026

Copy link
Copy Markdown

PR author is in the excluded authors list.

@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from f270fa6 to d750dbd Compare July 24, 2026 16:38
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from d750dbd to 91f2a3c Compare July 24, 2026 23:13
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 91f2a3c to 93a4862 Compare July 27, 2026 06:39
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 93a4862 to d5b19e3 Compare July 27, 2026 09:13
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from d5b19e3 to f1789b4 Compare July 30, 2026 17:41
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from f1789b4 to ef539d7 Compare July 30, 2026 23:04
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from ef539d7 to 1b71998 Compare August 3, 2026 10:01
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 1b71998 to d3fadb1 Compare August 3, 2026 16:48
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from d3fadb1 to 8e995ed Compare August 10, 2026 04:44
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 8e995ed to dcd140a Compare August 10, 2026 08:30
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from dcd140a to cfc605b Compare August 11, 2026 23:56
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from cfc605b to 7b11e40 Compare August 12, 2026 06:16
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 7b11e40 to ab5e053 Compare August 14, 2026 20:46
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from ab5e053 to 88995b3 Compare August 15, 2026 02:31
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 10844b8 to 800f561 Compare August 27, 2026 02:50
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 800f561 to 524a55e Compare August 31, 2026 05:08
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 524a55e to 4485755 Compare August 31, 2026 13:09
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 4485755 to 169d20e Compare September 2, 2026 23:33
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 169d20e to 2a78ef6 Compare September 3, 2026 02:42
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 2a78ef6 to 6c85145 Compare September 3, 2026 19:57
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 6c85145 to 29d688a Compare September 4, 2026 01:58
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch 2 times, most recently from fa3a969 to aee5566 Compare September 7, 2026 04:33
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from aee5566 to c0a586a Compare September 7, 2026 21:58
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from c0a586a to 99f8738 Compare September 8, 2026 04:15
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 99f8738 to 9eeab67 Compare September 9, 2026 16:45
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 9eeab67 to 7eb3794 Compare September 10, 2026 01:44
@renovate
renovate Bot force-pushed the renovate/npm-astro-vulnerability branch from 7eb3794 to c95bb77 Compare September 10, 2026 17:50

This branch had an error being deployed

1 failed deployment
Preview — 9cb23daf Deployed Nov 13, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants