next npm package: is it safe?

The requireFromString function compiles and executes arbitrary JavaScript code provided as a string using module._compile. This is a dynamic code execution capability that could be abused if the input is attacker-controlled.

The code compiles TypeScript config using SWC and then dynamically loads the resulting CommonJS code via requireFromString, which executes the transpiled module in the current process. While this is intentional behavior for loading Next.js config, it represents dynamic code execution where arbitrary code from next.config.ts is run at build time.

The readEntryJSFiles function constructs a file path from pagePath and requires it at runtime. While this is intended to load Next.js RSC manifests, the pattern of requiring a file whose path is derived from route/manifest data could be exploited if an attacker can influence pagePath to load arbitrary JavaScript files, leading to code execution. The save/restore of global.__RSC_MANIFEST is also a fragile global mutation pattern.

The code reads process.env.NEXT_PRIVATE_PAGE_PATHS and process.env.NEXT_PRIVATE_APP_PATHS and parses them with JSON.parse. These environment variables can override route path discovery. While this appears to be a legitimate testing hook in Next.js, it represents an environment-controlled code path that can influence build output. If an attacker can set these environment variables, they can inject arbitrary paths into the build configuration.

The code resolves and requires modules based on environment variables such as __INTERNAL_CUSTOM_TURBOPACK_BINDINGS, NEXT_TEST_NATIVE_DIR, NEXT_TEST_WASM_DIR, and NEXT_TEST_NATIVE_IGNORE_LOCAL_INSTALL. If an attacker can control these env vars, they could load arbitrary native binaries or JS modules into the process.

loadBindings/tryLoadNativeWithFallback download native SWC binaries at runtime via download-swc when local bindings are missing. This introduces a network-dependent, runtime-fetched executable code path which, if the download source or integrity is compromised, could execute untrusted native code.

The module loads and executes platform-specific native Node addons (@next/swc-* / next-swc.*.node). Native binaries can contain arbitrary code; trust depends entirely on the upstream package integrity from the registry.

The code spawns Node.js Worker threads using a filename provided via the creation.options.filename parameter. This filename is passed directly to new Worker(...) without validation. While this is a legitimate pattern for Turbopack's loader worker pool (executing loader files), the filename could originate from build configuration or external input, allowing arbitrary JavaScript files to be executed in a worker thread context if an attacker can control the filename. This constitutes dynamic module loading/execution.

The code uses import('MODULE') with a placeholder 'MODULE' that is later replaced during build. This dynamic import could load arbitrary external modules depending on the build configuration, potentially fetching malicious code from untrusted sources if the placeholder is not properly controlled.

The code permanently monkey-patches net.Socket.prototype.connect to intercept all outgoing TCP connections and record host/port into an external array. While it restores the original method when the returned cleanup function is invoked, until then it silently observes all socket connections made anywhere in the process. This is a legitimate access-trace mechanism for Turborepo, but the same pattern is commonly used to intercept and harvest connection targets (potentially including internal service addresses, databases, or credential-bearing endpoints).

Every TCP connect call is inspected and the destination host and port are pushed into the caller-supplied 'addresses' array. The destination of that array is controlled by the caller; if used maliciously, this could accumulate internal network topology information. In this package it appears intended for tracing/telemetry of accessed network resources.

The loadPlugin function resolves and requires PostCSS plugin modules using require.resolve and require() with plugin names provided from external PostCSS configuration files found in the project directory. While this is the intended behavior of PostCSS plugin loading, it means that a malicious or compromised PostCSS configuration file can cause arbitrary modules installed in the project to be loaded and executed at build time. This is a supply-chain/config-trust concern rather than a direct malicious pattern in this file.

resolveRobots and resolveSitemap build output (robots.txt, sitemap XML, manifest JSON) by directly interpolating user/route-supplied values (userAgent, allow, disallow, crawlDelay, host, sitemap URLs, item.url, alternates languages/hrefs, image locs, and all video fields such as title, description, content_loc, player_loc, restriction, platform, uploader info, etc.) without XML/HTML escaping or newline sanitization. If route metadata is attacker-influenced, this can lead to injection into generated robots.txt (e.g. injecting additional 'Disallow'/'Sitemap' directives via newlines) and malformed or injected XML in sitemap.xml (e.g. breaking out of element content or attributes such as the uploader info attribute or restriction relationship attribute). While this is not a remote code execution or data exfiltration flaw, it is a genuine output-encoding/security issue in a build-time metadata generator.

The generated code includes a dynamic import statement for an incremental cache handler: import incrementalCacheHandler from ${stringifiedCacheHandlerPath}. The path is derived from the cacheHandler loader option. If an attacker can control this option, they could cause the build to import an arbitrary module, potentially executing malicious code.

The loader returns a JavaScript source string that is compiled/executed by webpack. The string is built using dynamic values such as page, absolutePagePath, cacheHandler, middlewareConfig, and rootDir derived from loader options and the build context. While this is typical for webpack loaders, if these values are attacker-controlled (e.g., via a malicious config or compromised dependency), it could lead to arbitrary code execution in the build process.

The code performs require(fontLoaderPath).default where fontLoaderPath is obtained from loader options via this.getOptions(). If the webpack configuration or any upstream source can influence fontLoaderPath, this allows arbitrary module loading and potential code execution during the build process. While this is a legitimate Next.js feature, it represents a dynamic require that should be validated/restricted.

This is a webpack loader that executes at build time and dynamically loads/executes a font loader module specified by fontLoaderPath. Build-time loaders are a known supply-chain risk vector as they run with developer privileges. The dynamic require is the primary concern, though it appears to be an intentional part of Next.js's font system.

The loader reads a 'modules' array from webpack options (potentially attacker-controlled if the build config is compromised or if a dependency injects options) and generates require() calls with dynamically constructed paths. Module specifiers are passed through webpack's resolver against rootContext and then embedded into generated code via JSON.stringify. While JSON.stringify mitigates direct code injection, a malicious config or compromised build chain could force loading of arbitrary modules, including sensitive files if a path resolutions allows it. This is expected behavior for a Next.js internal instrumentation loader, but the dynamic require generation is a notable pattern worth flagging in third-party contexts.

The HTTP handler reads the request body into a string and passes it through JSON.parse(body) before handing it to the MCP transport. There is no length limit on the body, no Content-Type validation, and no streaming limit, so a client can send an arbitrarily large payload to cause memory exhaustion (DoS). The parsed JSON is also accepted without checking the Content-Type or method restrictions expected by the MCP spec.

The MCP HTTP server listens on 127.0.0.1 (loopback only), which is good, but it exposes an unauthenticated tool (query_spans) that returns trace data. Any local process or a DNS-rebinding attack from a browser page can reach 127.0.0.1 and invoke the MCP endpoint. No Origin/Host header validation or authentication is performed, allowing cross-site requests to interact with the local trace server.

The code reads local CPU profile (.cpuprofile) and Turbopack trace files and uploads their contents to an external endpoint (nextjs.org/api/upload-trace, overridable via __NEXT_UPLOAD_TRACE_URL_OVERRIDE). While this appears to be legitimate telemetry for the Next.js team, it constitutes uploading potentially sensitive local build data to a remote server.

The code dynamically installs missing dependencies via installDependencies and then spawns the Playwright CLI binary using cross-spawn with shell: false. While this is part of the legitimate Next.js experimental test workflow, the dynamic installation and execution of package binaries could be abused if an attacker controls package resolution or the project environment.

The code uses child_process.spawn to execute a command derived from getNpxCommand(baseDir).split(' '). If getNpxCommand returns a string influenced by untrusted input (e.g., project directory path or environment), it could allow command injection or execution of arbitrary binaries. The spawn call also passes options.revision directly as an argument, which, while not shell-interpreted, could be manipulated if revision is attacker-controlled.

The component uses dangerouslySetInnerHTML to inject document.documentElement.innerHTML directly into the DOM. While it caches the page's own HTML on mount, this pattern can be exploited if the cached HTML contains attacker-controlled content (e.g., injected via XSS or a compromised dependency), effectively re-rendering arbitrary scripts/markup without sanitization.

The module installs a global window.fetch override during lock scopes. While intended for a testing API and gated by environment checks, monkey-patching fetch could interfere with other scripts or be abused if the lock state is manipulated. It blocks user-initiated fetches until lock release, which is a behavior change outside normal app code.

The code reads and writes the NEXT_INSTANT_TEST_COOKIE via both document.cookie and cookieStore, including a defensive clear that modifies cookies outside the component's immediate scope. This could affect cookie state for the whole origin and potentially leak lock state or resurrect stale cookies if race conditions are exploited.

The code creates a WebSocket connection using a URL derived from options.assetPrefix and options.path. While this is expected behavior for a Next.js hot module replacement (HMR) client, it could be exploited if the assetPrefix is controlled by an attacker, leading to connection to a malicious server.

The WebSocket URL is constructed using getSocketUrl(options.assetPrefix) and options.path. If these values are not properly sanitized, an attacker could potentially redirect the WebSocket connection to an arbitrary server.

The function reactElementToDOM uses dangerouslySetInnerHTML to assign raw HTML to el.innerHTML. If untrusted input reaches this path, it could lead to DOM-based XSS. This is a known React/Next.js head manager pattern, but it is still a dangerous capability if the data source is compromised.

Direct assignment to innerHTML can execute inline scripts and event handlers when combined with attacker-controlled props. This is a common vector for client-side code injection.

File uses '@swc/helpers', 'react', 'react-dom' and Next.js internal shared modules. Confirm the package name, publisher, and integrity hash match the official Next.js distribution; typosquatted republishes of this file would be highly dangerous due to arbitrary script injection capability.

The component supports a 'dangerouslySetInnerHTML' prop that directly assigns HTML content to script element innerHTML without sanitization, enabling arbitrary inline script execution if untrusted input reaches this prop.

The loadScript function dynamically creates <script> elements and sets their src from the 'src' prop, then appends them to document.body. While this is the intended behavior of Next.js's Script component, it allows arbitrary remote script loading if a malicious prop value is passed, which could enable supply-chain or XSS attacks in consuming applications.

In the appDir path, the component emits inline scripts invoking '(self.__next_s=self.__next_s||[]).push(...)' with JSON-encoded props. This pattern is internal to Next.js but executes dynamic payloads at runtime and should be treated as elevated risk surface if the module is not the official Next.js package.

The module patches core Node.js globals including globalThis.Request, globalThis.Response, globalThis.Headers, net.Socket.prototype.connect, https.Agent.prototype.addRequest, and node:http ClientRequest/get/request. This modifies core HTTP behavior process-wide at import time via the applyPatch mechanism, which is a powerful interception mechanism that could be used for man-in-the-middle modification of all outgoing requests.

The function uses require(process.env.NEXT_FONT_GOOGLE_MOCKED_RESPONSES) to load a module based on an environment variable. While this is intended for testing (mocked responses), if an attacker can control this environment variable, they could load arbitrary code. This is a potential security risk in environments where environment variables are not fully trusted or can be influenced by external input.

When the NEXT_FONT_GOOGLE_MOCKED_RESPONSES environment variable is set, the function reads arbitrary files from disk via fs.readFileSync(url) when url starts with '/'. If an attacker can influence the 'url' value (e.g., through a compromised font manifest or build configuration) and the environment variable is set, this could allow reading sensitive files. However, this path is a documented mocking/testing feature and requires environmental precondition, so severity is moderate.

The file dynamically loads './bundle' and calls the function coreLibPluginPass(). While this pattern is common in Babel's build output, the loaded module could contain obfuscated or malicious code. The actual security risk cannot be assessed without inspecting the 'bundle' module it requires.

The file uses require('./bundle') with a relative path and invokes .core() on the imported module. While the path is static and relative, the actual behavior depends entirely on the contents of './bundle', which is not provided for analysis. This pattern is common in Babel but could hide malicious code if the bundle is compromised.

The loadQueries function uses eval('require')(eval('require').resolve(name, {paths:['.', ctx.path]})) to dynamically resolve and load modules from user-controlled config names. While guarded by checkExtend() and dangerousExtend checks, this is still dynamic module loading based on config input and can lead to arbitrary code execution if a malicious package name passes the prefix check (e.g., a malicious 'browserslist-config-*' package installed in node_modules).

The module wraps child_process.spawn and spawnSync to execute external commands. While this is the intended purpose of the cross-spawn library, it is a capability that could be misused if the module is compromised or if inputs are attacker-controlled.

The _createHttpHeader function builds raw HTTP header strings from response headers without sanitizing CRLF characters. If an upstream server returns a header value containing \r\n, this could enable HTTP response splitting/header injection in the websocket upgrade path.

The proxy implementation forwards requests to arbitrary targets provided via options (target/forward/URL). If target URLs are derived from untrusted input, this can be abused for SSRF against internal services. This is inherent to proxy libraries but requires callers to validate targets.

In followRedirects logic, authorization and cookie headers are stripped only when the redirect host differs from the original request's URL object host, but the comparison uses new URL(location, forwardTarget) and compares against 'forwardTarget' host rather than the actual current hop. Under certain redirect chains this comparison may not correctly detect cross-host hops, potentially leaking Authorization/Cookie headers to a different origin.

The code uses eval("require")(file) to dynamically load modules. While this is a known pattern in jest-worker for resolving module paths at runtime, eval-based module loading can be exploited if the file variable is attacker-controlled. In this context, file is received from the parent process via IPC, which is normally trusted, but it represents a dynamic code execution path that could be abused if the IPC channel is compromised.

The child process listens for messages from the parent and executes functions from dynamically required modules based on message content (execMethod). Method names and arguments are controlled by the parent process. If a malicious or compromised parent process sends crafted messages, arbitrary exported functions from the loaded module could be invoked with arbitrary arguments.

The file uses eval('require')(file) to dynamically load modules specified in messages from the parent process. While this is legitimate jest-worker functionality, the use of eval to obtain require bypasses normal module resolution and could be exploited if the parent process is compromised or if the file path is attacker-controlled.

execFunction applies a function (from the dynamically required module) with user-supplied arguments. The method and args come from parent process messages. If the parent process is malicious or compromised, it could invoke arbitrary exported functions with arbitrary arguments.

The loader uses eval() to dynamically import ES modules based on a computed URL from loader.path. While this is standard webpack loader-runner behavior for ESM loaders, eval with computed input is a code execution risk if loader.path can be influenced by untrusted input.

Uses require(loader.path) to load arbitrary modules from computed paths. This is core functionality for a loader runner, but allows loading any module specified by the loader configuration.

The evalModuleCode function uses Node's Module._compile to evaluate and execute arbitrary JavaScript module code (provided as the 'code' argument) at runtime. While this is an expected part of mini-css-extract-plugin's child compiler behavior, it represents a dynamic code execution primitive that could be abused if the extracted CSS content or module code is attacker-controlled.

The code monkey-patches Module.prototype._compile, intercepting the compilation of every CommonJS module loaded after this package is imported. While the modification is gated on 'use client'/'use server' directives and delegates to the original compile, this is an invasive runtime behavior that hooks into Node's core module system and could affect unexpected files.

Uses acorn-loose to parse arbitrary file contents at require time and makes security-relevant decisions based on string directives in the source. This creates a mechanism where the behavior of any required module can be altered based on its content, which expands the attack surface if the package is ever compromised or if attacker-controlled files are loaded.

The code monkey-patches Module.prototype._compile, intercepting the compilation of every CommonJS module loaded after this package is imported. While the modification is gated on 'use client'/'use server' directives and delegates to the original compile, this is an invasive runtime behavior that hooks into Node's core module system and could affect unexpected files.

Uses acorn-loose to parse arbitrary file contents at require time and makes security-relevant decisions based on string directives in the source. This creates a mechanism where the behavior of any required module can be altered based on its content, which expands the attack surface if the package is ever compromised or if attacker-controlled files are loaded.

Uses eval("require").resolve(...) to dynamically load optional Sass implementations. While this is a known pattern in sass-loader, dynamic require resolution can be abused by malicious packages if module resolution is influenced by attacker-controlled paths or environment.

The loader accepts a user-provided 'implementation' option and calls require(s) on it if it is a string. This allows loading arbitrary modules based on build configuration, which could be exploited if untrusted configuration is used.

The code uses new Function(""+e) to convert a non-function argument into a function, which can execute arbitrary code if the input is controlled by an attacker.

The code uses eval() and execScript() to execute arbitrary JavaScript code within iframe contexts. This is inherent to the vm-browserify package's purpose of providing a browser-based VM implementation, but it represents a significant security concern if untrusted code is ever passed to these functions.

The function resolves and dynamically imports adapterPath from a file URL via pathToFileURL(require.resolve(adapterPath)).href, then invokes adapterMod.onBuildComplete(...). This allows arbitrary code from an adapter module to execute with full build-time privileges. While this is an intentional Next.js adapter mechanism, the adapter path is an external input and the invoked callback receives sensitive build outputs, file paths, environment config, middleware matchers, and prerender tokens.

The onBuildComplete callback is passed prerenderManifest.preview.previewModeId as config.bypassToken on prerender outputs (lines ~684 and ~832), and numerous absolute filesystem paths, project directory, repo root, distDir, and full routing/middleware matcher details. A malicious adapter could exfiltrate secrets or use the preview bypass token to access preview-authenticated routes.

The function executes config.compiler.runAfterProductionCompile (a user-provided function from next.config.js) during the production build. This is by design for Next.js, but in a third-party package context it represents arbitrary code execution at build time from configuration, which could be abused if an attacker can influence the configuration.

The code overrides Node.js require.extensions for multiple file extensions (.js, .ts, .cts, .mts, .cjs, .mjs) and dynamically transforms and executes code using swc transformSync. This is a powerful hook that can intercept and modify module loading behavior, potentially allowing arbitrary code execution or code injection if swcOptions are attacker-controlled or if the hook is used to load untrusted modules.

The require hook uses mod._compile to execute transformed code. This is a low-level Node.js API that compiles and runs code. Combined with the fallback to readFileSync and transformSync, it can execute arbitrary JavaScript from files on disk. While this is the intended function of a require hook, it represents a risk if the package is compromised or if the hook is misused.

The transpileConfig function reads a Next.js config file from disk, transpiles it with SWC, and then executes the resulting code via requireFromString. If an attacker can control or modify nextConfigPath (e.g., via a malicious project configuration or path traversal), this could lead to arbitrary code execution. Additionally, the code dynamically imports the config path using import(pathToFileURL(nextConfigPath).href) when the Node.js native TypeScript loader is enabled, which also executes the file. This is expected behavior for loading user config, but the path is derived from input and not validated to be within a trusted scope.

The use of import(pathToFileURL(nextConfigPath).href) dynamically imports a file based on the nextConfigPath parameter. If this path is influenced by external input, it could load malicious modules. However, in the context of Next.js, this is intended for loading the user's own configuration.

The preview signing and encryption keys are generated using crypto.randomBytes, which is cryptographically secure. However, the keys are stored in a plaintext JSON file (.previewinfo) in the cache directory, which could be accessible to other users or processes on the system, potentially leading to key compromise.

The readEntryJSFiles function constructs a file path from user-influenced inputs (pagePath, appRoute) and calls require() on it. While this is intended to load Next.js RSC manifest files from the dist directory, the dynamic require with a path derived from external data could potentially load unintended modules if pagePath or appRoute contain path traversal sequences. The code does not sanitize or validate these inputs before constructing the path.

The code creates a Node.js Worker thread using a filename derived from the creation.options.filename value, which is passed from an external bindings callback. If an attacker can influence this filename (e.g., through a crafted project configuration or module resolution), it could lead to arbitrary code execution in a worker thread. The workerData also includes bindingPath and cwd, potentially exposing environment context to the worker.

The code uses a dynamic import('MODULE') where MODULE appears to be a build-time placeholder that will be replaced with the actual module path. If not properly controlled, this could allow loading arbitrary modules from untrusted sources. This is a common pattern in bundlers/frameworks (like Next.js edge runtime) but could be exploited if the placeholder is user-controllable.

The Proxy get trap dynamically accesses mod[name] and returns a function that calls it. If name is attacker-controlled, this could allow invoking arbitrary exports from the imported module. This is inherent to the design but could be a security concern if the imported module exposes dangerous functions.

The code wraps process.env in a Proxy and records every accessed environment variable key into the provided envVars set. While this appears to be for build-time instrumentation (turborepo-access-trace), it globally replaces process.env for the entire process. Any consumer of this function can capture all environment variable names accessed by subsequent code, which could aid reconnaissance for credential harvesting if the tracked set is exfiltrated or misused. No exfiltration or credential file reads are present in this file itself.

The code permanently overrides net.Socket.prototype.connect, a core Node.js networking primitive. While it only records the destination address/port and then calls the original implementation, this technique can be abused in a supply-chain context to intercept or redirect arbitrary network connections, and it affects all code running in the process. It is a legitimate pattern used by Turborepo for build-time network access tracing, but it is a high-impact behavior that warrants review.

createLazyPostCssPlugin wraps require(pluginPath) and require(pluginPath)(options). The pluginPath is resolved at runtime from external configuration, enabling execution of arbitrary npm packages specified in the PostCSS config. Although this is a legitimate feature of the build system, it represents a code execution vector tied to build-time configuration.

The loadPlugin function calls require.resolve(pluginName, { paths: [dir] }) and then require(pluginPath) or require(pluginPath)(options) where pluginName and pluginPath are derived from user-controlled PostCSS configuration. While this is expected behavior for a PostCSS plugin loader, it means arbitrary modules can be loaded and executed based on config file contents. This is a potential supply-chain risk if a malicious postcss.config.js is present in a project.

The plugin resolves URLs found in CSS declarations (via url() and image-set()). It uses options.resolver and options.context to resolve requests, which can lead to network requests if not properly sandboxed. An attacker controlling CSS input could potentially cause the loader to fetch arbitrary URLs, leading to server-side request forgery (SSRF) or information disclosure. However, this is standard behavior for CSS URL handling and not inherently malicious, but it is a security-sensitive operation.

The createMetadataExportsCode function interpolates metadata file paths and module import source strings directly into generated JavaScript code using template literals. This is a code generation pattern, and if any interpolated value contained malicious content, it could result in code injection into the generated output. In practice the values are derived from controlled file system enumeration and stringify output, but it represents an injection surface worth noting.

The resolveSitemap function builds XML output by directly interpolating untrusted input values (item.url, language keys/values, image URLs, video fields such as title, thumbnail_loc, description, content_loc, player_loc, restriction relationship/content, uploader info/content, etc.) without XML-escaping them. If an attacker can control any of these metadata fields (e.g. via route metadata derived from request data), they could inject arbitrary XML elements/attributes into the sitemap, potentially leading to XSS when the sitemap is served/parsed, or to content spoofing and structure corruption of the generated sitemap. Similarly, resolveRobots interpolates rule values directly into robots.txt without sanitization, which could allow header/line injection if values contain newlines.

The loader performs require(fontLoaderPath) where fontLoaderPath is obtained from this.getOptions(). While this is part of Next.js's internal font loading mechanism, dynamically requiring a module based on loader options can be exploited if an attacker can control the loader options. If a malicious webpack configuration or dependency injection occurs, this could allow arbitrary module loading and code execution at build time.

The loader dynamically resolves module specifiers using this.getResolve() and rootContext, then generates require() calls with the resolved paths. While this is a legitimate webpack loader pattern, it allows arbitrary module inclusion based on the 'modules' option, which could be exploited if the option is attacker-controlled to load malicious modules.

The plugin uses compiler.hooks.compilation.tap, hooks.renderModuleContent.tap, hooks.render.tap, and hooks.chunkHash.tap to inject code into every rendered module during compilation. Hooks that rewrite module content are a legitimate webpack pattern but represent a powerful mutation point: any consumer of this package grants it the ability to inject arbitrary code into the output bundle. Reviewers should ensure the package is pinned and trusted.

The plugin intentionally emits eval(...) calls into the generated bundle to support webpack's eval-source-map devtool. While this is standard behavior for the devtool and not malicious per se, it creates a code-execution sink: any untrusted content interpolated into content + footer is executed in the browser context. The content originates from webpack's own module sources, and footer is JSON-stringified, so injection is bounded, but the pattern still constitutes dynamic code execution and should be flagged when auditing a third-party package.

The component uses React's dangerouslySetInnerHTML to inject previously captured document.documentElement.innerHTML. This bypasses React's XSS protections and could enable HTML/script injection if the captured markup is ever influenced by attacker-controlled content or if the cached snapshot is tampered with in the browser. While intended for error-boundary graceful degradation, it is a notable unsafe rendering pattern.

setAttributesFromProps(el, props) forwards props directly as DOM attributes without visible validation in this file. Combined with the head element injection, untrusted props could set arbitrary attributes (e.g., onerror, nonce, href) enabling script execution or CSP bypass via nonce handling in isEqualNode.

reactElementToDOM() directly assigns props.dangerouslySetInnerHTML.__html to element.innerHTML. If any component props are influenced by untrusted input (e.g., URL parameters, user content), this can insert arbitrary HTML/scripts into <head> elements such as meta, link, style, or script tags, leading to DOM-based XSS. This is standard React behavior but worth noting for a head manager operating on user-influenced data.

updateElements() creates and appends arbitrary 'meta', 'base', 'link', 'style', and 'script' elements to document.head from input components. If callers pass attacker-controlled props (href, src, innerHTML, charset, etc.), this could be abused to load external resources, exfiltrate data via link preloads, or inject scripts.

The function __turbopack_load_page_chunks__ dynamically loads chunks via __turbopack_load__ using data provided at runtime (chunksData). If an attacker can control the chunksData input (e.g., via server-side rendering or injection), this could lead to loading arbitrary modules. While typical for bundlers, it represents a dynamic code loading surface.

The code creates <script> elements from caller-supplied src/children/dangerouslySetInnerHTML values and appends them to document.body. This is the intended behavior of next/script, but it is a code-execution primitive. If a consumer of this package passes untrusted values, it can load and execute arbitrary remote scripts or inline code.

The loadScript function assigns el.innerHTML = dangerouslySetInnerHTML.__html directly to a dynamically created script element. If the dangerouslySetInnerHTML prop originates from untrusted input, this enables arbitrary JavaScript execution (XSS). While Next.js documents this prop as dangerous, it is still a code-execution sink that warrants review.

For appDir beforeInteractive strategy, the component emits an inline <script> whose content is built with template literals embedding JSON.stringify'd props. htmlEscapeJsonString is applied for escaping, which mitigates XSS, but the pattern of constructing executable script content from runtime props is a high-risk sink that should be treated carefully.

The Trusted Types policy 'nextjs' is created with identity functions for createHTML, createScript, and createScriptURL, effectively disabling the browser's Trusted Types XSS mitigation. Any string passed through this policy will be treated as trusted, which can reintroduce XSS vulnerabilities if untrusted input reaches these sinks.

__unsafeCreateTrustedScriptURL is exported and explicitly documented as security-sensitive. It promotes arbitrary strings to TrustedScriptURL, and if callers pass attacker-controlled URLs, it can lead to script loading and execution. The fallback to raw strings when Trusted Types are unavailable means the function does not actually enforce any safety.

The code uses dynamic import() with paths computed from runtime variables (dir, cacheHandler, and handler values from cacheHandlers). This allows loading of arbitrary modules based on user-controlled configuration. While this is typical Next.js cache handler configuration, it constitutes dynamic module loading with external input and could be exploited if the configuration source is untrusted.

The code extracts tar archives to directories outside the package scope (cache directory and node_modules). This is necessary for the package's functionality but could overwrite files if the tar contains malicious paths (zip slip). The tar library used is from next/dist/compiled/tar, presumably safe, but still a risk.