chore(deps): bump esbuild from 0.27.7 to 0.28.1 in /examples/astro in the npm_and_yarn group across 1 directory

[dependabot]

Bumps the npm_and_yarn group with 1 update in the /examples/astro directory: esbuild.

Updates esbuild from 0.27.7 to 0.28.1

Release notes

Sourced from esbuild's releases.

v0.28.1

• Disallow \ in local development server HTTP requests (GHSA-g7r4-m6w7-qqqr)

  This release fixes a security issue where HTTP requests to esbuild's local development server could traverse outside of the serve directory on Windows using a \ backslash character. It happened due to the use of Go's path.Clean() function, which only handles Unix-style / characters. HTTP requests with paths containing \ are no longer allowed.

  Thanks to @​dellalibera for reporting this issue.

• Add integrity checks to the Deno API (GHSA-gv7w-rqvm-qjhr)

  The previous release of esbuild added integrity checks to esbuild's npm install script. This release also adds integrity checks to esbuild's Deno install script. Now esbuild's Deno API will also fail with an error if the downloaded esbuild binary contains something other than the expected content.

  Note that esbuild's Deno API installs from registry.npmjs.org by default, but allows the NPM_CONFIG_REGISTRY environment variable to override this with a custom package registry. This change means that the esbuild executable served by NPM_CONFIG_REGISTRY must now match the expected content.

  Thanks to @​sondt99 for reporting this issue.

• Avoid inlining using and await using declarations (#4482)

  Previously esbuild's minifier sometimes incorrectly inlined using and await using declarations into subsequent uses of that declaration, which then fails to dispose of the resource correctly. This bug happened because inlining was done for let and const declarations by avoiding doing it for var declarations, which no longer worked when more declaration types were added. Here's an example:

  // Original code
  {
    using x = new Resource()
    x.activate()
  }
  // Old output (with --minify)
  new Resource().activate();
  // New output (with --minify)
  {using e=new Resource;e.activate()}

• Fix module evaluation when an error is thrown (#4461, #4467)

  If an error is thrown during module evaluation, esbuild previously didn't preserve the state of the module for subsequent module references. This was observable if import() or require() is used to import a module multiple times. The thrown error is supposed to be thrown by every call to import() or require(), not just the first. With this release, esbuild will now throw the same error every time you call import() or require() on a module that throws during its evaluation.

• Fix some edge cases around the new operator (#4477)

  Previously esbuild incorrectly printed certain edge cases involving complex expressions inside the target of a new expression (specifically an optional chain and/or a tagged template literal). The generated code for the new target was not correctly wrapped with parentheses, and either contained a syntax error or had different semantics. These edge cases have been fixed so that they now correctly wrap the new target in parentheses. Here is an example of some affected code:

  // Original code
  new (foo()`bar`)()
  new (foo()?.bar)()
  // Old output
  new foo()bar();
  new (foo())?.bar();

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.28.1

• Disallow \ in local development server HTTP requests (GHSA-g7r4-m6w7-qqqr)

  This release fixes a security issue where HTTP requests to esbuild's local development server could traverse outside of the serve directory on Windows using a \ backslash character. It happened due to the use of Go's path.Clean() function, which only handles Unix-style / characters. HTTP requests with paths containing \ are no longer allowed.

  Thanks to @​dellalibera for reporting this issue.

• Add integrity checks to the Deno API (GHSA-gv7w-rqvm-qjhr)

  The previous release of esbuild added integrity checks to esbuild's npm install script. This release also adds integrity checks to esbuild's Deno install script. Now esbuild's Deno API will also fail with an error if the downloaded esbuild binary contains something other than the expected content.

  Note that esbuild's Deno API installs from registry.npmjs.org by default, but allows the NPM_CONFIG_REGISTRY environment variable to override this with a custom package registry. This change means that the esbuild executable served by NPM_CONFIG_REGISTRY must now match the expected content.

  Thanks to @​sondt99 for reporting this issue.

• Avoid inlining using and await using declarations (#4482)

  Previously esbuild's minifier sometimes incorrectly inlined using and await using declarations into subsequent uses of that declaration, which then fails to dispose of the resource correctly. This bug happened because inlining was done for let and const declarations by avoiding doing it for var declarations, which no longer worked when more declaration types were added. Here's an example:

  // Original code
  {
    using x = new Resource()
    x.activate()
  }
  // Old output (with --minify)
  new Resource().activate();
  // New output (with --minify)
  {using e=new Resource;e.activate()}

• Fix module evaluation when an error is thrown (#4461, #4467)

  If an error is thrown during module evaluation, esbuild previously didn't preserve the state of the module for subsequent module references. This was observable if import() or require() is used to import a module multiple times. The thrown error is supposed to be thrown by every call to import() or require(), not just the first. With this release, esbuild will now throw the same error every time you call import() or require() on a module that throws during its evaluation.

• Fix some edge cases around the new operator (#4477)

  Previously esbuild incorrectly printed certain edge cases involving complex expressions inside the target of a new expression (specifically an optional chain and/or a tagged template literal). The generated code for the new target was not correctly wrapped with parentheses, and either contained a syntax error or had different semantics. These edge cases have been fixed so that they now correctly wrap the new target in parentheses. Here is an example of some affected code:

  // Original code
  new (foo()`bar`)()
  new (foo()?.bar)()
  // Old output
  new foo()bar();
  new (foo())?.bar();

... (truncated)

Commits

• bb9db84 publish 0.28.1 to npm
• 9ff053e security: add integrity checks to the Deno API
• 0a9bf21 enforce non-negative size in gzip parser
• e2a1a71 security: forbid \\ in local dev server requests
• 83a2cbf fix #4482: don't inline using declarations
• 308ad74 fix #4471: renaming of nested var declarations
• f013f5f fix some typos
• aafd6e4 chore: fix some minor issues in comments (#4462)
• 15300c3 follow up: cjs evaluation fixes
• 1bda0c3 fix #4461, fix #4467: esm evaluation fixes
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​astrojs/​node@​10.1.2 ⏵ 11.0.0	+1		+1	+1
	npm/​astro@​6.4.8 ⏵ 7.0.4

View full report

[socket-security]

Caution

Review the following alerts detected in dependencies.

According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. It is recommended to resolve "Warn" alerts too. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Block		Obfuscated code: npm astro is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/astro@7.0.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential security risk (AI signal): npm @emnapi/core Notes: undefined Confidence: undefined Severity: undefined From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@emnapi/core@1.11.1 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/core@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential security risk (AI signal): npm @emnapi/core Notes: undefined Confidence: undefined Severity: undefined From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@emnapi/core@1.11.1 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/core@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential security risk (AI signal): npm @emnapi/core Notes: undefined Confidence: undefined Severity: undefined From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@emnapi/core@1.11.1 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/core@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @astrojs/compiler-binding-wasm32-wasi is 90.0% likely to have a medium risk anomaly Notes: This loader establishes a Node.js WASI/worker environment that: 1) passes the entire host process.env into the WASI instance (exposing all environment variables, including secrets, to loaded modules); 2) preopens the filesystem root (granting broad file read/write access under the host’s root directory); and 3) implements importScripts via synchronous fs.readFileSync + eval (allowing any local JS file to be executed in the loader context). If an untrusted or compromised WASM module or script is provided, it can read sensitive environment variables, access or modify arbitrary files, and execute arbitrary JavaScript—posing a moderate security risk. Recommended mitigations: restrict WASI preopens to a minimal directory, limit or sanitize environment variables passed into WASI, and replace or sandbox the eval-based importScripts mechanism. Confidence: 0.90 Severity: 0.60 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @astrojs/compiler-binding is 66.0% likely to have a medium risk anomaly Notes: This file is primarily a platform-aware native/WASI binding loader for the Astro compiler. No explicit malicious payload (exfiltration/backdoor/credential theft) is visible in the JavaScript loader logic. However, it contains a high-impact sink: it can load an arbitrary native module via require(process.env.NAPI_RS_NATIVE_LIBRARY_PATH) without validation or integrity checks. Additionally, it executes ldd --version during initialization for libc detection. Overall risk is driven by native code execution impact and potential environment manipulation; otherwise the behavior is consistent with legitimate native-binding loading. Confidence: 0.66 Severity: 0.60 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@astrojs/compiler-binding@0.3.0 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@astrojs/compiler-binding@0.3.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @bruits/satteri-wasm32-wasi is 63.0% likely to have a medium risk anomaly Notes: This file is a WASM loader/wrapper. The wrapper itself does not show classic malicious JS behaviors (no eval/Function, no direct network exfiltration, no hardcoded credentials). However, it executes a wasm binary whose content is not verified, prefers a potentially different 'debug' wasm if present, grants WASI access to a broadly preopened filesystem root, and passes full process.env to both the WASI instance and a worker. Additionally, worker message data is forwarded into a FS proxy that can perform filesystem operations. Since the core behavior is inside the instantiated WASM, this wrapper carries a moderate supply-chain/security risk primarily due to unverified wasm execution and broad capability exposure. Confidence: 0.63 Severity: 0.58 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@bruits/satteri-wasm32-wasi@0.9.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@bruits/satteri-wasm32-wasi@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @bruits/satteri-wasm32-wasi is 90.0% likely to have a medium risk anomaly Notes: This loader establishes a Node.js WASI/worker environment that: 1) passes the entire host process.env into the WASI instance (exposing all environment variables, including secrets, to loaded modules); 2) preopens the filesystem root (granting broad file read/write access under the host’s root directory); and 3) implements importScripts via synchronous fs.readFileSync + eval (allowing any local JS file to be executed in the loader context). If an untrusted or compromised WASM module or script is provided, it can read sensitive environment variables, access or modify arbitrary files, and execute arbitrary JavaScript—posing a moderate security risk. Recommended mitigations: restrict WASI preopens to a minimal directory, limit or sanitize environment variables passed into WASI, and replace or sandbox the eval-based importScripts mechanism. Confidence: 0.90 Severity: 0.60 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@bruits/satteri-wasm32-wasi@0.9.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@bruits/satteri-wasm32-wasi@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @emnapi/core is 66.0% likely to have a medium risk anomaly Notes: This code is a WASM/worker interop runtime shim with significant execution capability. The primary security concern is that it can execute arbitrary JavaScript via g.eval (napi_run_script) and can dynamically generate wrapper functions via new Function (emnapiCreateFunction). Additionally, worker message payloads can drive indirect calls into wasm function tables. The fragment shows no direct exfiltration or persistence mechanisms, so malicious intent is not established, but the attack surface is elevated due to powerful dynamic-execution sinks and trust in WASM/message-controlled inputs. Confidence: 0.66 Severity: 0.67 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@emnapi/core@1.11.1 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/core@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @emnapi/core is 63.0% likely to have a medium risk anomaly Notes: The file package/dist/emnapi-core.min.js implements a wasm/N-API interop runtime that includes dynamic code execution surfaces via eval and new Function. If attacker-controlled input can reach these dynamic paths (through napi_run_script or dynamic wrapper code), it can enable arbitrary JavaScript execution (RCE) in the Node process and potentially in spawned workers. Confidence: 0.63 Severity: 0.74 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@emnapi/core@1.11.1 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/core@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @rolldown/binding-wasm32-wasi is 60.0% likely to have a medium risk anomaly Notes: A WASI-enabled loader executes the packaged WASM binary for packages/rolldown/src/rolldown-binding.wasi.cjs with broad capabilities, exposing process.env and preopening a host directory, creating a risk of environment secrets exposure and filesystem access if the artifact or related logic is tampered with. Mitigation should enforce integrity verification of the WASM binaries and worker scripts, limit preopens to specific directories, and avoid exposing full process.env. Confidence: 0.60 Severity: 0.52 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@rolldown/binding-wasm32-wasi@1.1.3 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@rolldown/binding-wasm32-wasi@1.1.3. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm @rolldown/binding-wasm32-wasi is 90.0% likely to have a medium risk anomaly Notes: This loader establishes a Node.js WASI/worker environment that: 1) passes the entire host process.env into the WASI instance (exposing all environment variables, including secrets, to loaded modules); 2) preopens the filesystem root (granting broad file read/write access under the host’s root directory); and 3) implements importScripts via synchronous fs.readFileSync + eval (allowing any local JS file to be executed in the loader context). If an untrusted or compromised WASM module or script is provided, it can read sensitive environment variables, access or modify arbitrary files, and execute arbitrary JavaScript—posing a moderate security risk. Recommended mitigations: restrict WASI preopens to a minimal directory, limit or sanitize environment variables passed into WASI, and replace or sandbox the eval-based importScripts mechanism. Confidence: 0.90 Severity: 0.60 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@rolldown/binding-wasm32-wasi@1.1.3 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@rolldown/binding-wasm32-wasi@1.1.3. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm astro is 60.0% likely to have a medium risk anomaly Notes: No direct evidence of malicious payloads (e.g., hardcoded credentials, explicit credential theft, eval/Function, direct network exfiltration, or overt persistence) is visible in this fragment alone. The primary security considerations are delegation and trust boundaries: it dynamically imports many internal modules and passes user-controlled CLI flags broadly into them, and the docs path wires an execution abstraction plus OS/cloud provider objects, which makes downstream subprocess/network behavior important to review. Telemetry is also invoked (update with full flags and an unconditional notify), increasing the need to verify that telemetry is privacy-preserving and does not transmit sensitive user/system data. Overall, this appears to be a typical CLI entrypoint with moderate supply-chain/behavioral review risk due to indirection and telemetry/executor wiring. Confidence: 0.60 Severity: 0.52 From: examples/astro/package-lock.json → npm/astro@7.0.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/astro@7.0.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm satteri is 60.0% likely to have a medium risk anomaly Notes: This module is a typical MD/MDX compilation/evaluation pipeline with a significant security property: it executes compiler-generated JavaScript via new Function(...). No explicit malware behavior (network/IO/stealth) is visible in the snippet, but it materially increases the impact of untrusted MDX input or compromised/unsafe plugins by turning parsed content into executable code. Security depends on strict trust boundaries, plugin governance, and whether evaluation is ever performed on attacker-controlled content. Confidence: 0.60 Severity: 0.62 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/satteri@0.9.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/satteri@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm satteri is 63.0% likely to have a medium risk anomaly Notes: This file is a WASM loader/wrapper. The wrapper itself does not show classic malicious JS behaviors (no eval/Function, no direct network exfiltration, no hardcoded credentials). However, it executes a wasm binary whose content is not verified, prefers a potentially different 'debug' wasm if present, grants WASI access to a broadly preopened filesystem root, and passes full process.env to both the WASI instance and a worker. Additionally, worker message data is forwarded into a FS proxy that can perform filesystem operations. Since the core behavior is inside the instantiated WASM, this wrapper carries a moderate supply-chain/security risk primarily due to unverified wasm execution and broad capability exposure. Confidence: 0.63 Severity: 0.58 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/satteri@0.9.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/satteri@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Block		Potential code anomaly (AI signal): npm satteri is 90.0% likely to have a medium risk anomaly Notes: This loader establishes a Node.js WASI/worker environment that: 1) passes the entire host process.env into the WASI instance (exposing all environment variables, including secrets, to loaded modules); 2) preopens the filesystem root (granting broad file read/write access under the host’s root directory); and 3) implements importScripts via synchronous fs.readFileSync + eval (allowing any local JS file to be executed in the loader context). If an untrusted or compromised WASM module or script is provided, it can read sensitive environment variables, access or modify arbitrary files, and execute arbitrary JavaScript—posing a moderate security risk. Recommended mitigations: restrict WASI preopens to a minimal directory, limit or sanitize environment variables passed into WASI, and replace or sandbox the eval-based importScripts mechanism. Confidence: 0.90 Severity: 0.60 From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/satteri@0.9.4 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/satteri@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		System shell access: npm @astrojs/compiler-binding in module child_process Module: child_process Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@astrojs/compiler-binding@0.3.0 ℹ Read more on: This package | This alert | What is shell access? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@astrojs/compiler-binding@0.3.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm am-i-vibing Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/am-i-vibing@0.4.0 ℹ Read more on: This package | This alert | What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/am-i-vibing@0.4.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		System shell access: npm process-ancestry in module child_process Module: child_process Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/process-ancestry@0.1.0 ℹ Read more on: This package | This alert | What is shell access? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/process-ancestry@0.1.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Dynamic code execution: npm satteri Eval Type: Function Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/satteri@0.9.4 ℹ Read more on: This package | This alert | What is dynamic code execution? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Avoid packages that use dynamic code execution like eval(), since this could potentially execute any code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/satteri@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		System shell access: npm satteri in module child_process Module: child_process Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/satteri@0.9.4 ℹ Read more on: This package | This alert | What is shell access? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/satteri@0.9.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Environment variable access: npm @astrojs/compiler-binding-wasm32-wasi Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0 ℹ Read more on: This package | This alert | What is environment variable access? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should be clear about which environment variables they access, and care should be taken to ensure they only access environment variables they claim to. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Environment variable access: npm @astrojs/compiler-binding-wasm32-wasi Env Vars: NAPI_RS_ASYNC_WORK_POOL_SIZE Location: Package overview From: examples/astro/package-lock.json → npm/astro@7.0.4 → npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0 ℹ Read more on: This package | This alert | What is environment variable access? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should be clear about which environment variables they access, and care should be taken to ensure they only access environment variables they claim to. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@astrojs/compiler-binding-wasm32-wasi@0.3.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
See 28 more rows in the dashboard

View full report