# next@16.3.8 security report (npm)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-06T14:22:43.000Z
- Files reviewed: 3305
- Findings: 6 high, 245 medium, 685 low severity findings
- Report: https://security.togoder.click/npm/next
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the npm package next@16.3.8 on Oct 6, 2026. An AI review of 3305 source files produced 6 high, 245 medium, 685 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [high] Remote binary download without integrity verification

Finding ID: `NPS-140248425475`

File: `dist/esm/lib/mkcert.js:32`

The code downloads an executable binary (mkcert) from GitHub releases and writes it to disk without verifying a checksum or signature. If the download is compromised via MITM or a compromised release, arbitrary code could be executed.

### [high] Suspicious process execution

Finding ID: `NPS-64407DC0225B`

File: `dist/esm/lib/mkcert.js:92`

The code uses execSync to run the downloaded binary with shell interpolation of dynamically constructed paths and hostnames. This could allow command injection if host or certDir contain malicious values.

### [high] Node.js Inspector Exposure

Finding ID: `NPS-C0307DEC67A1`

File: `dist/esm/next-devtools/server/attach-nodejs-debugger-middleware.js:12`

The middleware endpoint /__nextjs_attach-nodejs-inspector opens the Node.js inspector on the process debug port (process.debugPort) if not already listening, then fetches and returns the DevTools frontend URL from the inspector's HTTP endpoint. This grants anyone who can reach this route full debugging access to the Node.js process, including the ability to execute arbitrary code in the runtime via the inspector protocol. While this is intended for Next.js development mode, exposing it in a production or non-loopback context is a serious security risk.

### [high] Remote Code Execution Surface via Debugger

Finding ID: `NPS-C2E62E9493B8`

File: `dist/esm/next-devtools/server/attach-nodejs-debugger-middleware.js:12`

By exposing the Node.js inspector endpoint, an attacker with network access to this route could connect to the inspector WebSocket, evaluate arbitrary JavaScript, read environment variables, files, and credentials, and spawn processes. This effectively provides a backdoor-like capability if the endpoint is reachable outside trusted development environments.

### [high] Local debugger/DevTools middleware exposure

Finding ID: `NPS-E847F970F741`

File: `dist/esm/server/dev/hot-reloader-webpack.js:1148`

Middleware getAttachNodejsDebuggerMiddleware and devToolsConfigMiddleware expose Node.js debugger attach functionality and devtools configuration over the dev server. This is a powerful capability that, if the dev server is reachable by untrusted parties, could allow attaching a Node debugger or otherwise inspecting/interfering with the process.

### [high] Path traversal / arbitrary file read

Finding ID: `NPS-2858B1421EE5`

File: `dist/server/web/sandbox/fetch-inline-assets.js:24`

The asset name is taken directly from the 'blob:' input and resolved against options.distDir without validating that the final path stays inside distDir. A crafted blob URL such as 'blob:../../../../etc/passwd' (when options.assets is not provided) would resolve outside the intended distribution directory, allowing arbitrary readable files to be served via the Response stream.

### [medium] Dynamic code execution

Finding ID: `NPS-EA1E608CBEBA`

File: `dist/build/next-config-ts/require-hook.js:87`

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.

### [medium] Dynamic code execution via require hook

Finding ID: `NPS-B95BD7F20964`

File: `dist/build/next-config-ts/transpile-config.js:124`

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.

### [medium] Dynamic require of manifest file

Finding ID: `NPS-7E0B6A9A45A5`

File: `dist/build/route-bundle-stats.js:82`

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.

### [medium] Environment variable input parsing

Finding ID: `NPS-1F042C2DCC6B`

File: `dist/build/route-discovery.js`

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.

### [medium] Dynamic module loading with external/environment-controlled paths

Finding ID: `NPS-649BA217809B`

File: `dist/build/swc/index.js`

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.

### [medium] Native binary download fallback

Finding ID: `NPS-B015E9E68C04`

File: `dist/build/swc/index.js`

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.

### [medium] Runtime execution of native .node binaries

Finding ID: `NPS-07642AF15C7B`

File: `dist/build/swc/index.js`

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.

### [medium] Dynamic worker thread creation from external input

Finding ID: `NPS-044DEF1263C8`

File: `dist/build/swc/loaderWorkerPool.js:22`

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.

### [medium] Dynamic import with placeholder

Finding ID: `NPS-94BCE2D43004`

File: `dist/build/templates/edge-wrapper.js:9`

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.

### [medium] Global prototype patching / network interception

Finding ID: `NPS-AC9E8E26261E`

File: `dist/build/turborepo-access-trace/tcp.js:17`

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

### [medium] Data collection at runtime

Finding ID: `NPS-2166B5ACCC74`

File: `dist/build/turborepo-access-trace/tcp.js:24`

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.

### [medium] Dynamic module loading based on external configuration

Finding ID: `NPS-D7D918118B4B`

File: `dist/build/webpack/config/blocks/css/plugins.js`

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.

### [medium] Improper output encoding

Finding ID: `NPS-F0A2CB05D9EC`

File: `dist/build/webpack/loaders/metadata/resolve-route-data.js:35`

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.

### [medium] Dynamic module import with computed path

Finding ID: `NPS-B98A657918EB`

File: `dist/build/webpack/loaders/next-edge-function-loader.js:24`

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.

### [medium] Dynamic code execution via generated string

Finding ID: `NPS-5E0CA5010645`

File: `dist/build/webpack/loaders/next-edge-function-loader.js:27`

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.

### [medium] Dynamic module loading with computed path

Finding ID: `NPS-6127AD860964`

File: `dist/build/webpack/loaders/next-font-loader/index.js:117`

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.

### [medium] Build-time code execution

Finding ID: `NPS-9FF00E02A6BC`

File: `dist/build/webpack/loaders/next-font-loader/index.js:117`

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.

### [medium] Dynamic module loading with computed specifiers

Finding ID: `NPS-9FDB7BB34D92`

File: `dist/build/webpack/loaders/next-instrumentation-client-loader.js:23`

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.

### [medium] Unvalidated request body JSON parsing

Finding ID: `NPS-372C642EEA69`

File: `dist/cli/internal/turbo-trace-server.js:232`

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.

### [medium] HTTP server bound to loopback without authentication

Finding ID: `NPS-1E8FA9BD5A97`

File: `dist/cli/internal/turbo-trace-server.js:260`

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.

### [medium] Data exfiltration / file upload to external server

Finding ID: `NPS-7F2F7A10C2F7`

File: `dist/cli/internal/upload-trace.js`

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.

### [medium] Process spawning and dynamic dependency installation

Finding ID: `NPS-E1473ABDEB9D`

File: `dist/cli/next-test.js:108`

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.

### [medium] Spawning processes or shell commands

Finding ID: `NPS-23306D2E8EAF`

File: `dist/cli/next-upgrade.js:21`

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.

### [medium] dangerouslySetInnerHTML usage

Finding ID: `NPS-616CB4986FA9`

File: `dist/client/components/errors/graceful-degrade-boundary.js:86`

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.

### [medium] Global fetch override

Finding ID: `NPS-9419F3356D1F`

File: `dist/client/components/segment-cache/navigation-testing-lock.js`

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.

### [medium] Cookie manipulation

Finding ID: `NPS-73819C03677D`

File: `dist/client/components/segment-cache/navigation-testing-lock.js`

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.

### [medium] Suspicious network request

Finding ID: `NPS-3EE231CEEC6F`

File: `dist/client/dev/hot-reloader/pages/websocket.js:88`

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.

### [medium] Dynamic URL construction

Finding ID: `NPS-8D3654B1ED37`

File: `dist/client/dev/hot-reloader/pages/websocket.js:88`

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.

### [medium] Dynamic HTML injection

Finding ID: `NPS-07F24DFDD949`

File: `dist/client/head-manager.js:22`

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.

### [medium] Use of innerHTML

Finding ID: `NPS-4B19CCAB978A`

File: `dist/client/head-manager.js:22`

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.

### [medium] Third-party registry verification needed

Finding ID: `NPS-CE3801CE01BE`

File: `dist/client/script.js`

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.

### [medium] dangerouslySetInnerHTML usage

Finding ID: `NPS-FB5058EE0A6C`

File: `dist/client/script.js:96`

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.

### [medium] Dynamic script injection

Finding ID: `NPS-1AA8077C572F`

File: `dist/client/script.js:105`

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.

### [medium] Dynamic code execution via self.__next_s

Finding ID: `NPS-25B36155EF89`

File: `dist/client/script.js:318`

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.

### [medium] Global runtime patching

Finding ID: `NPS-038C9C80E848`

File: `dist/compiled/@mswjs/interceptors/ClientRequest/index.js:1`

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.

### [medium] Dynamic module loading with environment variable

Finding ID: `NPS-A4586B4E2731`

File: `dist/compiled/@next/font/dist/google/fetch-css-from-google-fonts.js:17`

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.

### [medium] Filesystem read based on user-controlled path

Finding ID: `NPS-AE2C2DFBA76B`

File: `dist/compiled/@next/font/dist/google/fetch-font-file.js:15`

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.

### [medium] Dynamic module loading

Finding ID: `NPS-AC71EFA81CA2`

File: `dist/compiled/babel/core-lib-plugin-pass.js:1`

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.

### [medium] Dynamic module loading

Finding ID: `NPS-9E61358ABB29`

File: `dist/compiled/babel/core.js:1`

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.

### [medium] Dynamic code execution (eval)

Finding ID: `NPS-93E39316FFB2`

File: `dist/compiled/browserslist/index.js`

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

### [medium] process spawning

Finding ID: `NPS-E0AD7E70610F`

File: `dist/compiled/cross-spawn/index.js:1`

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.

### [medium] HTTP header injection risk

Finding ID: `NPS-F5E94C24F7E7`

File: `dist/compiled/httpxy/index.js`

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.

### [medium] Potential Server-Side Request Forgery (SSRF)

Finding ID: `NPS-34AD04B6286C`

File: `dist/compiled/httpxy/index.js`

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.

### [medium] Redirect handling strips credentials on cross-host only

Finding ID: `NPS-4E3CF1EF19E0`

File: `dist/compiled/httpxy/index.js`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-5FE199429AA9`

File: `dist/compiled/jest-worker/processChild.js`

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.

### [medium] IPC message handling / dynamic invocation

Finding ID: `NPS-E7CAA92EA5CD`

File: `dist/compiled/jest-worker/processChild.js`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-0B976F2D2D32`

File: `dist/compiled/jest-worker/threadChild.js`

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.

### [medium] Arbitrary function execution

Finding ID: `NPS-F034F7EAF8AD`

File: `dist/compiled/jest-worker/threadChild.js`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-FD6FFEA0CDA4`

File: `dist/compiled/loader-runner/LoaderRunner.js`

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.

### [medium] Dynamic module loading

Finding ID: `NPS-803DCE97A301`

File: `dist/compiled/loader-runner/LoaderRunner.js`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-C23E95915FBE`

File: `dist/compiled/mini-css-extract-plugin/loader.js`

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.

### [medium] module loading hijacking

Finding ID: `NPS-8BEA123798FF`

File: `dist/compiled/react-server-dom-webpack-experimental/cjs/react-server-dom-webpack-node-register.js:15`

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.

### [medium] dynamic code parsing and directive-based branching

Finding ID: `NPS-AE7B31C67EC6`

File: `dist/compiled/react-server-dom-webpack-experimental/cjs/react-server-dom-webpack-node-register.js:19`

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.

### [medium] module loading hijacking

Finding ID: `NPS-8BEA123798FF`

File: `dist/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-node-register.js:15`

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.

### [medium] dynamic code parsing and directive-based branching

Finding ID: `NPS-AE7B31C67EC6`

File: `dist/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-node-register.js:19`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-C1A4D784974A`

File: `dist/compiled/sass-loader/cjs.js`

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.

### [medium] Unsafe dynamic module loading

Finding ID: `NPS-E612BF01462D`

File: `dist/compiled/sass-loader/cjs.js`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-3C836CB4C77B`

File: `dist/compiled/setimmediate/setImmediate.js:5`

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.

### [medium] Dynamic code execution

Finding ID: `NPS-535773125CD1`

File: `dist/compiled/vm-browserify/index.js`

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.

### [medium] Dynamic module loading from external input

Finding ID: `NPS-83AF5C23A606`

File: `dist/esm/build/adapter/build-complete.js:70`

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.

### [medium] Sensitive data exposure to third-party adapter

Finding ID: `NPS-66953A9A573A`

File: `dist/esm/build/adapter/build-complete.js:684`

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.

### [medium] Execution of user-provided code

Finding ID: `NPS-3FE8E88F8473`

File: `dist/esm/build/after-production-compile.js:15`

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.

### [medium] Dynamic module loading / require hook

Finding ID: `NPS-17EC4BB40AEC`

File: `dist/esm/build/next-config-ts/require-hook.js:10`

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.

### [medium] Dynamic code execution via _compile

Finding ID: `NPS-F8888C959312`

File: `dist/esm/build/next-config-ts/require-hook.js:26`

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.

### [medium] Dynamic code execution / module loading

Finding ID: `NPS-14FBDA24F906`

File: `dist/esm/build/next-config-ts/transpile-config.js`

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.

### [medium] Dynamic import with computed path

Finding ID: `NPS-27F1F22E49A8`

File: `dist/esm/build/next-config-ts/transpile-config.js`

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.

### [medium] Predictable Cryptographic Keys

Finding ID: `NPS-920A63D3A8EF`

File: `dist/esm/build/preview-key-utils.js:46`

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.

### [medium] Dynamic module loading with computed path

Finding ID: `NPS-40085624A8B4`

File: `dist/esm/build/route-bundle-stats.js:48`

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.

### [medium] Dynamic worker thread creation with computed filename

Finding ID: `NPS-0B266DD8B1FD`

File: `dist/esm/build/swc/loaderWorkerPool.js:9`

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.

### [medium] Dynamic import with placeholder

Finding ID: `NPS-833349D71E4E`

File: `dist/esm/build/templates/edge-wrapper.js:10`

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.

### [medium] Proxy with dynamic property access

Finding ID: `NPS-4BA89598AA9D`

File: `dist/esm/build/templates/edge-wrapper.js:13`

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.

### [medium] Environment variable access tracking

Finding ID: `NPS-021ED7585A75`

File: `dist/esm/build/turborepo-access-trace/env.js:8`

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.

### [medium] Global prototype modification / monkey-patching

Finding ID: `NPS-DD283D04DE08`

File: `dist/esm/build/turborepo-access-trace/tcp.js:9`

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.

### [medium] Use of require with dynamic path

Finding ID: `NPS-F2FFA54981D0`

File: `dist/esm/build/webpack/config/blocks/css/plugins.js:47`

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.

### [medium] Dynamic module loading with computed input

Finding ID: `NPS-D23531AA3147`

File: `dist/esm/build/webpack/config/blocks/css/plugins.js:63`

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.

### [medium] Potential SSRF via URL resolution

Finding ID: `NPS-55FE3E7D74B0`

File: `dist/esm/build/webpack/loaders/css-loader/src/plugins/postcss-url-parser.js:260`

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.

### [medium] String interpolation into generated code

Finding ID: `NPS-FA3096F30A65`

File: `dist/esm/build/webpack/loaders/metadata/discover.js:82`

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.

### [medium] XML Injection / Improper Output Encoding

Finding ID: `NPS-AEB737245A53`

File: `dist/esm/build/webpack/loaders/metadata/resolve-route-data.js`

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.

### [medium] Dynamic require with computed path

Finding ID: `NPS-97509A17E1B6`

File: `dist/esm/build/webpack/loaders/next-font-loader/index.js:85`

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.

### [medium] Dynamic module resolution and generation

Finding ID: `NPS-4CA8E0ED19E0`

File: `dist/esm/build/webpack/loaders/next-instrumentation-client-loader.js`

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.

### [medium] build-time plugin hook execution

Finding ID: `NPS-AD090A258B3B`

File: `dist/esm/build/webpack/plugins/eval-source-map-dev-tool-plugin.js:62`

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.

### [medium] dynamic code execution via eval()

Finding ID: `NPS-8D983FA7B4F4`

File: `dist/esm/build/webpack/plugins/eval-source-map-dev-tool-plugin.js:181`

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.

### [medium] dangerouslySetInnerHTML usage

Finding ID: `NPS-C67346563039`

File: `dist/esm/client/components/errors/graceful-degrade-boundary.js:52`

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.

### [medium] Unvalidated attribute propagation

Finding ID: `NPS-F091332A301B`

File: `dist/esm/client/head-manager.js:3`

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.

### [medium] DOM-based XSS via dangerouslySetInnerHTML

Finding ID: `NPS-3DCB51CB9712`

File: `dist/esm/client/head-manager.js:6`

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.

### [medium] Dynamic script/style element injection into document head

Finding ID: `NPS-EDF8534A95DC`

File: `dist/esm/client/head-manager.js:63`

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.

### [medium] dynamic module loading

Finding ID: `NPS-F854A932780C`

File: `dist/esm/client/next-turbopack.js:20`

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.

### [medium] Dynamic script creation and injection into DOM

Finding ID: `NPS-225495BE760E`

File: `dist/esm/client/script.js:65`

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.

### [medium] Dynamic script injection via innerHTML

Finding ID: `NPS-4C783C8942B3`

File: `dist/esm/client/script.js:84`

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.

### [medium] Runtime string interpolation into an inline script tag

Finding ID: `NPS-FDC812A2AC3B`

File: `dist/esm/client/script.js:262`

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.

### [medium] Trusted Types policy bypass

Finding ID: `NPS-7ED31E928262`

File: `dist/esm/client/trusted-types.js:9`

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.

### [medium] Security-sensitive exported function

Finding ID: `NPS-B61AB5DF867E`

File: `dist/esm/client/trusted-types.js:18`

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

### [medium] Dynamic imports with computed paths

Finding ID: `NPS-56527C28AE6D`

File: `dist/esm/export/helpers/create-incremental-cache.js:12`

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.

### [medium] File system manipulation

Finding ID: `NPS-B890EDE3A586`

File: `dist/esm/lib/download-swc.js:12`

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.

## Files reviewed

- `dist/build/collect-build-traces.js` (medium): This appears to be a legitimate Next.js build tracing module with no malicious patterns; the identified concerns are typical of build tooling that manipulates files and reads environment variables but pose only low risk in this context.
- `dist/build/next-config-ts/require-hook.js` (medium): This module provides TypeScript require hook support with dynamic code compilation; it is not inherently malicious but introduces dynamic code execution and global module loading modifications that could be risky in untrusted contexts.
- `dist/build/next-config-ts/transpile-config.js` (medium): The file is part of Next.js build tooling and intentionally transpiles and executes the project's own next.config.ts; no exfiltration, credential harvesting, obfuscation, or malicious process spawning was detected, though dynamic code execution is inherent to its function.
- `dist/build/route-bundle-stats.js` (medium): This is a legitimate Next.js internal bundle-stats module, but it uses dynamic require() of filesystem paths derived from route data and mutates globals, which are patterns that warrant caution though no malicious behavior is evident.
- `dist/build/route-discovery.js` (medium): This appears to be legitimate Next.js route discovery code with no clear malicious patterns, though it contains environment-variable-driven build overrides (NEXT_PRIVATE_PAGE_PATHS/NEXT_PRIVATE_APP_PATHS) that warrant monitoring as potential build-injection vectors.
- `dist/build/swc/index.js` (medium): This is legitimate Next.js SWC binding loader code, but it exhibits several risky patterns — environment-variable-controlled dynamic requires/imports and runtime download of native binaries — that could be abused if those inputs are attacker-controlled.
- `dist/build/swc/loaderWorkerPool.js` (medium): No clear malicious intent, but the file dynamically spawns worker threads using filenames supplied via bindings and mutates global scheduler state, warranting caution if inputs are not validated upstream.
- `dist/build/templates/edge-wrapper.js` (medium): The code is a build template for Edge Runtime module wrapping with dynamic import and global state modification, but no direct malicious patterns are evident; the use of placeholders and global pollution presents minor risks if the build process is compromised.
- `dist/build/turborepo-access-trace/env.js` (medium): The file implements an environment-variable access-tracking Proxy for Turborepo and contains no exfiltration, code execution, network, or process-spawning logic; the only notable concern is its global mutation of process.env and credential-harvesting potential if the tracked Set were misused by other code.
- `dist/build/turborepo-access-trace/helpers.js` (medium): This is Turborepo's legitimate build access tracing helper that proxies environment variables, TCP connections, and filesystem paths for dependency tracking; no malicious patterns detected.
- `dist/build/turborepo-access-trace/tcp.js` (medium): The file monkey-patches net.Socket.prototype.connect to record TCP connection destinations into an external array, which is a network-interception pattern that is benign in Turborepo's tracing context but carries inherent risk of connection-target harvesting if misused.
- `dist/build/webpack-build/index.js` (medium): This file is Next.js's legitimate webpack build orchestrator; it contains no exfiltration, credential harvesting, obfuscation, or backdoor logic, but it does spawn worker processes with inherited environment variables and dynamically loads a sibling module, which are expected build-tool patterns rather than malicious behavior.
- `dist/build/webpack/alias/react-dom-server.js` (medium): The code is a legitimate Next.js shim that conditionally loads React DOM server builds and intentionally disables legacy APIs; no malicious patterns were detected, though environment-dependent module loading is noted as a low-risk observation.
- `dist/build/webpack/config/blocks/css/plugins.js` (medium): This is legitimate Next.js PostCSS plugin loading code; it dynamically resolves and requires plugins from user configuration, which is expected but represents a config-driven code execution surface rather than an inherent malicious pattern.
- `dist/build/webpack/loaders/metadata/resolve-route-data.js` (medium): No malicious patterns (exfiltration, credential harvesting, eval, process spawning, network access, or install-time execution) were detected; the only security concern is missing XML/HTML/text escaping when interpolating metadata into generated robots.txt and sitemap.xml output, which can permit content injection.
- `dist/build/webpack/loaders/next-edge-function-loader.js` (medium): This is a legitimate Next.js webpack loader, but it generates and evaluates code using dynamic build-time inputs (page paths, cache handler paths, base64 config), which could pose a risk if those inputs are compromised.
- `dist/build/webpack/loaders/next-font-loader/index.js` (medium): Legitimate Next.js font loader with a dynamic require of a configurable font loader path, which poses a moderate supply-chain risk if the path can be externally controlled.
- `dist/build/webpack/loaders/next-instrumentation-client-loader.js` (medium): This appears to be a legitimate Next.js instrumentation loader that dynamically resolves and requires user-configured modules; no exfiltration, credential harvesting, obfuscation, or process spawning is present, but the dynamic require generation based on build options warrants a warning-level note.
- `dist/build/webpack/loaders/next-middleware-loader.js` (medium): This is a Next.js webpack middleware loader that decodes base64 configuration and resolves module paths; no clear malicious patterns like exfiltration, credential harvesting, or shell execution are present, but it relies on attacker-controllable build options and dynamic module resolution which warrant low-severity caution.
- `dist/cli/internal/turbo-trace-server.js` (medium): The file is a local Turbopack trace/MCP server: it starts a loopback HTTP endpoint and a native trace server handle, with no data exfiltration, credential harvesting, obfuscation, mining, shells, or install-time execution detected, but it has unauthenticated local HTTP exposure and unbounded JSON body parsing that could enable local DoS or DNS-rebinding-style abuse.
- `dist/cli/internal/upload-trace.js` (medium): Code intentionally uploads local build trace/profile files to an external Next.js endpoint; appears to be legitimate telemetry but does send user files off-machine.
- `dist/cli/next-dev.js` (medium): This appears to be a legitimate Next.js dev server CLI file with expected telemetry, process forking, and trace upload behaviors; no malicious patterns such as credential theft, obfuscation, backdoors, or unauthorized external exfiltration were identified, though telemetry and trace upload to a configurable URL warrant awareness.
- `dist/cli/next-info.js` (medium): This file is a legitimate Next.js diagnostic utility that collects system and package information, performs network requests to the npm registry, and spawns version-check commands; no clear malicious patterns such as credential harvesting, exfiltration, or backdoors were found.
- `dist/cli/next-start.js` (medium): The code appears to be a legitimate Next.js CLI start script with no malicious patterns, but includes dynamic import of inspector and environment variable manipulation, which are low-risk security considerations.
- `dist/cli/next-test.js` (medium): No clear malicious intent detected; findings relate to legitimate but potentially risky operations (dependency installation, process spawning, config file generation) that are standard for the Next.js test CLI.
- `dist/cli/next-upgrade.js` (medium): The file spawns an external process to run '@next/codemod@canary upgrade', which is expected functionality, but the command construction from getNpxCommand and user-supplied options.revision introduces a potential command injection risk if those inputs are not properly validated.
- `dist/client/components/app-router.js` (medium): This is a legitimate Next.js App Router client component with expected framework behaviors (history API patching, dynamic conditional requires, dev-mode globals); no data exfiltration, credential harvesting, obfuscation, shell execution, or other malicious patterns were found, though some patterns warrant low-severity attention.
- `dist/client/components/errors/graceful-degrade-boundary.js` (medium): The component relies on dangerouslySetInnerHTML with cached document HTML and reflects DOM attributes, which introduces a moderate XSS/tampering risk despite no direct exfiltration, credential harvesting, or code execution patterns.
- `dist/client/components/layout-router.js` (medium): The code is part of Next.js's client-side router and contains no obvious malicious patterns; the findings are low-risk architectural concerns typical of framework internals.
- `dist/client/components/segment-cache/navigation-testing-lock.js` (medium): Code implements a testing-only navigation lock with global fetch override and cookie manipulation; no direct exfiltration or malicious payloads, but the global side effects and race conditions merit a warning.
- `dist/client/dev/hot-reloader/app/web-socket.js` (medium): This is legitimate Next.js Hot Module Replacement (HMR) client code with standard development-time WebSocket communication, dynamic imports for Turbopack, and no malicious patterns detected; minor warnings are due to dev-only patterns that are normal for HMR infrastructure.
- `dist/client/dev/hot-reloader/pages/hot-reloader-pages.js` (medium): This is a legitimate Next.js development hot-reloader client file with standard HMR functionality; the WebSocket communication and dynamic module replacement patterns are expected development tooling behaviors, though they represent inherent development-time attack surface.
- `dist/client/dev/hot-reloader/pages/websocket.js` (medium): The code appears to be a legitimate Next.js HMR client, but it constructs WebSocket URLs from configurable options and automatically reloads the page, which could be exploited under certain conditions.
- `dist/client/head-manager.js` (medium): The code is part of a legitimate Next.js head manager but contains dangerous DOM injection capabilities (innerHTML, dangerouslySetInnerHTML) and direct head manipulation that could be exploited if untrusted input is passed to it.
- `dist/client/normalize-locale-path.js` (medium): The code appears to be a legitimate Next.js internal helper for locale path normalization, with no clear malicious intent, though it uses conditional dynamic require and environment variable checks that warrant low-severity caution.
- `dist/client/request/search-params.browser.js` (medium): This appears to be standard transpiled Next.js code that conditionally loads development or production search-params modules based on NODE_ENV, with no evidence of data exfiltration, credential harvesting, obfuscation, or process spawning, though the environment-based dynamic require warrants low-level attention.
- `dist/client/script.js` (medium): This appears to be Next.js's legitimate client-side Script loader, but it contains dynamic script injection and dangerouslySetInnerHTML patterns inherent to its design, so verify provenance and treat as elevated-risk supply-chain surface.
- `dist/compiled/@babel/runtime/regenerator/index.js` (medium): This is a standard Babel regenerator runtime compatibility shim; it only uses Function() for a deliberate global assignment fallback and shows no signs of exfiltration, credential theft, backdoors, or other malicious behavior.
- `dist/compiled/@edge-runtime/primitives/index.js` (medium): The code appears to be a legitimate Edge Runtime primitive loader for WeakRef, but dynamically loads a companion module at import time which cannot be fully verified from this snippet alone.
- `dist/compiled/@edge-runtime/primitives/timers.js.text.js` (medium): The module re-exports modified global setTimeout/setInterval via Proxies that coerce the returned Timeout to a primitive, which is suspicious monkey-patching but no clear exfiltration, credential harvesting, or code execution was found.
- `dist/compiled/@mswjs/interceptors/ClientRequest/index.js` (medium): This is the genuine @mswjs/interceptors ClientRequest interceptor package; it performs extensive runtime monkey-patching of Node.js HTTP/net/TLS globals for legitimate request interception, with no evidence of data exfiltration, credential harvesting, backdoors, or malicious code execution.
- `dist/compiled/@next/font/dist/google/fetch-css-from-google-fonts.js` (medium): The code dynamically loads a module from a path specified by an environment variable, which could allow arbitrary code execution if that variable is attacker-controlled.
- `dist/compiled/@next/font/dist/google/fetch-font-file.js` (medium): The code is a legitimate Next.js font fetching utility with a documented mocking feature; no clear malicious patterns, but the env-var-triggered arbitrary file read warrants caution.
- `dist/compiled/@next/font/local/loader.js` (medium): The file only performs a static relative require of an internal module; no malicious indicators such as exfiltration, credential harvesting, obfuscation, or process execution were found, though the out-of-directory module load is noted as a minor concern.
- `dist/compiled/@next/react-refresh-utils/dist/loader.js` (medium): The loader injects React refresh runtime code into source files, which is expected behavior for a development tool; no malicious patterns were detected.
- `dist/compiled/babel/core-lib-config.js` (medium): Wrapper file with no directly observable malicious patterns, but it defers all behavior to a bundled module that cannot be reviewed from this file alone.
- `dist/compiled/babel/core-lib-plugin-pass.js` (medium): The file is a simple module re-export that dynamically loads a bundle, which requires further inspection of that bundle to determine safety.
- `dist/compiled/babel/core.js` (medium): The file itself is a simple re-export, but its security depends on the unanalyzed './bundle' module, which could contain malicious code.
- `dist/compiled/babel/plugin-syntax-dynamic-import.js` (medium): The file is a thin one-line re-export shim with no direct malicious patterns, but it defers all behavior to an unprovided bundle, giving low-confidence risk pending review of that dependency.
- `dist/compiled/babel/types.js` (medium): This is a trivial re-export shim that delegates to './bundle' with no direct malicious indicators, but its behavior depends entirely on the unreviewed bundle file.
- `dist/compiled/browserslist/index.js` (medium): This is a webpack-bundled copy of the legitimate 'browserslist' library; no exfiltration, backdoors, or malicious payloads were found, but it does contain dynamic eval/require patterns and reads environment variables and config files as part of its normal operation.
- `dist/compiled/cross-spawn/index.js` (medium): This is the legitimate cross-spawn npm package (bundled with ncc) that provides cross-platform child process spawning; it contains standard process spawning, environment variable, and filesystem access expected of such a utility, but no malicious exfiltration, obfuscation, or backdoor patterns were detected.
- `dist/compiled/httpxy/index.js` (medium): This is a legitimate httpxy/http-proxy-style library with no malicious code, but it exhibits typical proxy-library risks (SSRF, header injection, credential forwarding on redirects) that require careful caller-side validation.
- `dist/compiled/image-detector/detector.js` (medium): This is a benign image-dimension detection library with no network, credential, obfuscation, or process-spawning behavior; the only notable concerns are caller-controlled fs access in the TIFF handler and parser robustness against malformed input.
- `dist/compiled/jest-worker/processChild.js` (medium): This appears to be a legitimate jest-worker child process implementation that uses eval-based require and IPC message-driven dynamic function execution; no clear malicious intent (no exfiltration, credential harvesting, network calls, or backdoors), but the dynamic code execution patterns warrant a warning.
- `dist/compiled/jest-worker/threadChild.js` (medium): This appears to be legitimate jest-worker threadChild code (webpack bundled), but it uses eval('require') for dynamic module loading and executes functions based on parent process messages, which are inherent risks in worker architectures.
- `dist/compiled/loader-runner/LoaderRunner.js` (medium): This is the standard webpack loader-runner compiled bundle; it uses eval for dynamic ESM imports and require for loading arbitrary loaders, which are expected behaviors but carry inherent dynamic code execution risk if inputs are untrusted.
- `dist/compiled/mini-css-extract-plugin/loader.js` (medium): This appears to be the legitimate mini-css-extract-plugin loader bundle; it contains dynamic module compilation (expected for its function), a stray debug console.log, and computed require paths, but no clear exfiltration, credential harvesting, backdoor, or process-spawning behavior was detected.
- `dist/compiled/react-experimental/cjs/react.development.js` (medium): This appears to be the legitimate React development build with expected dev-mode behaviors; no clear exfiltration, credential harvesting, obfuscated payloads, or backdoors were identified, though a few dynamic loading patterns and global error reporting paths are noted as low-risk observations.
- `dist/compiled/react-server-dom-webpack-experimental/cjs/react-server-dom-webpack-node-register.js` (medium): This is the official Meta React Server DOM Webpack Node register hook; it contains no exfiltration, credential harvesting, obfuscation, or shell execution, but its monkey-patching of Module.prototype._compile and directive-based runtime branching are invasive patterns worth noting as medium-risk behavior rather than outright malicious code.
- `dist/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-node-register.js` (medium): This is the official Meta React Server DOM Webpack Node register hook; it contains no exfiltration, credential harvesting, obfuscation, or shell execution, but its monkey-patching of Module.prototype._compile and directive-based runtime branching are invasive patterns worth noting as medium-risk behavior rather than outright malicious code.
- `dist/compiled/regenerator-runtime/runtime.js` (medium): This is the legitimate Facebook regenerator-runtime polyfill; it contains no malicious patterns, though its use of the Function constructor as a strict-mode escape hatch and its global assignment are minor security-relevant observations.
- `dist/compiled/sass-loader/cjs.js` (medium): The file appears to be the legitimate sass-loader compiled output, but it uses dynamic require/eval patterns and environment variables that could pose limited risk if untrusted configuration or module resolution is involved.
- `dist/compiled/setimmediate/setImmediate.js` (medium): The file is a standard setImmediate polyfill but contains a dynamic code execution pattern (new Function) that could be exploited if user-controlled input is passed.
- `dist/compiled/timers-browserify/main.js` (medium): This appears to be a standard browserify timer polyfill with no obvious malicious patterns, but uses Function constructor and dynamic require which warrant low-severity review.
- `dist/compiled/vm-browserify/index.js` (medium): This is a legitimate vm-browserify shim that implements a browser-based VM with eval-based code execution; no malicious exfiltration, credential harvesting, or backdoor patterns were found, but its inherent use of dynamic code execution warrants caution.
- `dist/compiled/webpack/lazy-compilation-node.js` (medium): This is legitimate webpack lazy-compilation runtime code making a dynamic HTTP request for HMR; no malicious patterns, credential theft, shell execution, or obfuscation were found.
- `dist/esm/build/adapter/build-complete.js` (medium): This file is legitimate Next.js build orchestration code, but it dynamically imports an external adapter module and hands it extensive build artifacts, paths, and preview tokens; the risk is inherent to the adapter mechanism rather than malicious code.
- `dist/esm/build/after-production-compile.js` (medium): This Next.js build utility executes user-configured code after production builds and emits telemetry; it contains no evident malicious patterns but does perform dynamic code execution driven by configuration.
- `dist/esm/build/load-jsconfig.js` (medium): No malicious patterns detected; the code is a legitimate Next.js build utility that loads TypeScript/JavaScript configuration files, with dynamic require patterns that are expected for this functionality.
- `dist/esm/build/next-config-ts/require-hook.js` (medium): The code is a legitimate require hook for transpiling TypeScript and ESM files using swc, but it modifies global Node.js module loading behavior and executes dynamically transformed code, which could be exploited if the package or its configuration is compromised.
- `dist/esm/build/next-config-ts/transpile-config.js` (medium): The code performs dynamic code execution and module loading based on a config file path, which is a potential security risk if the path is attacker-controlled, but no clear malicious patterns like data exfiltration or backdoors were found.
- `dist/esm/build/preview-key-utils.js` (medium): The code generates and stores cryptographic keys in plaintext files without apparent malicious intent, but the storage mechanism poses a moderate security risk.
- `dist/esm/build/route-bundle-stats.js` (medium): The code appears to be a legitimate build-time utility for collecting route bundle statistics in a Next.js project, with minor security concerns around dynamic require of constructed paths and global variable manipulation.
- `dist/esm/build/route-discovery.js` (medium): This appears to be legitimate Next.js internal route-discovery code, but uses environment-variable-controlled path overrides and hardcoded dynamic require.resolve calls that warrant minor scrutiny.
- `dist/esm/build/swc/loaderWorkerPool.js` (medium): No direct exfiltration, credential theft, obfuscation, or shell execution, but dynamic worker creation from external input and global worker pool management introduce potential risk if inputs are not trusted.
- `dist/esm/build/templates/edge-wrapper.js` (medium): The code is a standard edge runtime wrapper that dynamically imports a module and exposes its exports through a thenable Proxy; while it uses dynamic import and top-level side effects, no malicious patterns like data exfiltration or backdoors are present.
- `dist/esm/build/turborepo-access-trace/env.js` (medium): The file implements an environment variable access-tracking Proxy for build instrumentation; it contains no exfiltration, credential file access, dynamic execution, or network activity, but it globally intercepts process.env which is a moderate information-gathering concern if misused.
- `dist/esm/build/turborepo-access-trace/tcp.js` (medium): This is a legitimate-looking TCP connect tracer used by Turborepo to detect network access during builds; it monkey-patches net.Socket.prototype.connect to log destinations but does not exfiltrate data, harvest credentials, execute dynamic code, or spawn processes.
- `dist/esm/build/webpack/config/blocks/css/index.js` (medium): This is a legitimate Next.js webpack CSS configuration module; no malicious patterns such as exfiltration, credential harvesting, obfuscation, or backdoors were detected, though dynamic module resolution and environment variable usage are present as expected build-time behaviors.
- `dist/esm/build/webpack/config/blocks/css/plugins.js` (medium): This file is a legitimate Next.js PostCSS plugin loader with dynamic require() calls driven by user configuration, which is expected but carries inherent supply-chain risks typical of build tooling.
- `dist/esm/build/webpack/loaders/css-loader/src/plugins/postcss-url-parser.js` (medium): The code appears to be a legitimate PostCSS plugin for parsing URLs in CSS, but it includes dynamic module resolution and URL fetching capabilities that could be security-sensitive if misused, though no direct malicious patterns were found.
- `dist/esm/build/webpack/loaders/metadata/discover.js` (medium): The code is a legitimate Next.js build-time metadata discovery module; it uses dynamic imports and string interpolation of file paths into generated code, which are typical for a webpack loader but represent low-to-medium injection surface if upstream inputs are untrusted.
- `dist/esm/build/webpack/loaders/metadata/resolve-route-data.js` (medium): No malicious behavior (exfiltration, code execution, backdoors, credential harvesting, process spawning, or install-time hooks) was found; the code is a straightforward metadata-to-text/XML serializer, though it lacks output encoding that could enable XML/robots.txt injection if inputs are attacker-controlled.
- `dist/esm/build/webpack/loaders/next-font-loader/index.js` (medium): This is a legitimate Next.js internal webpack loader for font processing; the dynamic require and path resolution are part of its normal operation, but could be abused if an attacker controls loader options or the resource query.
- `dist/esm/build/webpack/loaders/next-instrumentation-client-loader.js` (medium): This is a legitimate Next.js webpack loader for client instrumentation; no malicious patterns like data exfiltration, credential harvesting, or code execution were found, but dynamic module resolution warrants caution if options are untrusted.
- `dist/esm/build/webpack/plugins/eval-source-map-dev-tool-plugin.js` (medium): This is a forked webpack EvalSourceMapDevToolPlugin that legitimately uses eval/createScript and base64 source-map data URIs as part of the eval-source-map devtool; no exfiltration, credential harvesting, process spawning, or backdoor behavior is present.
- `dist/esm/build/worker.js` (medium): This appears to be a legitimate Next.js worker build file with benign top-level imports and environment variable usage; no malicious patterns such as exfiltration, obfuscation, process spawning, or backdoor installation were detected.
- `dist/esm/client/app-dir/link.js` (medium): This is legitimate Next.js Link component code with only minor patterns (dynamic require, location.replace with local-URL guard) that are not indicative of malicious activity.
- `dist/esm/client/app-globals.js` (medium): This is legitimate Next.js client bootstrap code with environment-gated dynamic requires and import-time side effects, but no evidence of data exfiltration, credential harvesting, obfuscation, or other malicious patterns.
- `dist/esm/client/components/app-router.js` (medium): This is a legitimate Next.js App Router client component that patches browser history APIs, installs global event handlers, and dynamically requires internal modules, but contains no clear data exfiltration, credential harvesting, obfuscation, shell execution, or other malicious patterns.
- `dist/esm/client/components/errors/graceful-degrade-boundary.js` (medium): The code is a legitimate-looking React error boundary for graceful degradation, but it uses dangerouslySetInnerHTML and captures/reapplies full document HTML attributes, which are unsafe rendering patterns worth flagging.
- `dist/esm/client/components/links.js` (medium): This is a legitimate Next.js client-side link prefetching module with no malicious patterns; minor warnings are due to dynamic require() calls and browser API usage that are expected for this functionality.
- `dist/esm/client/detect-domain-locale.js` (medium): The file contains a benign Next.js feature-flag pattern using environment variable gating and a hardcoded relative dynamic require; no malicious behavior detected, but dynamic require and env-based execution warrant low-severity notice.
- `dist/esm/client/dev/hot-reloader/app/web-socket.js` (medium): The file contains standard Hot Module Replacement (HMR) WebSocket client logic for Next.js development; no malicious patterns such as data exfiltration, credential harvesting, obfuscated code, or process spawning were detected.
- `dist/esm/client/head-manager.js` (medium): The file is part of Next.js head manager and contains no clear malicious intent, but it performs DOM operations (innerHTML, script/style/meta/link injection into document.head) that could enable XSS if untrusted data reaches component props.
- `dist/esm/client/next-turbopack.js` (medium): The code appears to be a legitimate Next.js Turbopack client entry point with dynamic chunk loading, but no clear malicious patterns such as exfiltration, credential harvesting, or backdoors were detected.
- `dist/esm/client/react-client-callbacks/error-boundary-callbacks.js` (medium): This appears to be a legitimate Next.js internal error-boundary callback module; no clear malicious behavior (no exfiltration, credential harvesting, obfuscation, or process spawning) was detected, though it uses dynamic dev-only require and error reporting hooks that merit routine scrutiny.
- `dist/esm/client/request/params.browser.js` (medium): The code uses environment-based conditional require to load one of two static modules, which is a benign pattern but carries minor risk due to dynamic loading and ESM/CJS mixing.
- `dist/esm/client/request/search-params.browser.js` (medium): Code conditionally loads modules based on NODE_ENV; this is a typical pattern but relies on environment variable control, posing a low risk if the environment is compromised.
- `dist/esm/client/script.js` (medium): This is the legitimate Next.js `next/script` client runtime; it contains expected dynamic script-injection primitives (innerHTML, DOM script appending, inline script emission) that are code-execution sinks but are consistent with the component's documented purpose and contain no exfiltration, credential harvesting, obfuscation, or process-spawning malicious patterns.
- `dist/esm/client/trusted-types.js` (medium): This Next.js Trusted Types helper intentionally implements a no-op Trusted Types policy and exports a documented unsafe string-to-TrustedScriptURL promotion function, weakening XSS protections rather than containing classic malicious code.
- `dist/esm/client/webpack.js` (medium): The code monkey-patches webpack internals to append a deployment ID query string to chunk filenames; while it modifies module/asset loading behavior and exposes a global public-path setter without validation, no exfiltration, credential harvesting, or obfuscated payloads were found.
- `dist/esm/export/helpers/create-incremental-cache.js` (medium): This appears to be legitimate Next.js incremental cache setup code, but it uses dynamic imports with computed paths from configuration which could load arbitrary modules if the configuration is attacker-controlled.
- `dist/esm/lib/download-swc.js` (medium): The code downloads and extracts SWC binaries from a registry, which is expected for Next.js, but it involves network requests and file system operations outside the package scope, posing moderate risk if the registry or tar contents are compromised.
- `dist/esm/lib/find-config.js` (medium): The code dynamically discovers and executes local configuration files, which is a legitimate pattern but introduces a code execution surface if the search path or key is attacker-controlled; no data exfiltration, credential harvesting, obfuscation, or network exfiltration was detected.
- `dist/esm/lib/helpers/get-npx-command.js` (medium): The file contains a benign use of execSync to probe yarn dlx availability, with no malicious patterns detected, though child process execution warrants low-severity caution.
- `dist/esm/lib/helpers/get-online.js` (medium): The code performs expected network and proxy checks with minor process spawning, but no malicious patterns are evident.
- `dist/esm/lib/helpers/get-pkg-manager.js` (medium): The code is a standard package manager detection utility with minor process execution that is not overtly malicious, but execSync calls make it a low-severity concern.
- `dist/esm/lib/helpers/get-registry.js` (medium): The code executes the detected package manager's config command to read the registry URL, which is a legitimate but potentially risky pattern if the package manager name is attacker-controlled; no clear malicious intent, but medium risk due to shell execution.
- `dist/esm/lib/helpers/git.js` (medium): Purpose-built git branch/commit helper that uses execSync with hardcoded arguments; no exfiltration, backdoor, or obfuscation found, but the generic `args` shell interpolation is a latent injection risk if reused.
- `dist/esm/lib/helpers/install.js` (medium): The code is a legitimate package manager installation helper that spawns npm, pnpm, or yarn with user-provided dependencies; no clear malicious patterns were detected, but it does execute processes with input that should be validated to prevent command injection.
- `dist/esm/lib/memory/startup.js` (medium): This Next.js memory debugging module is not malicious but enables heap snapshot generation via SIGUSR2 and near memory limits, which could expose sensitive in-memory data to disk if the module is enabled in production.
- `dist/esm/lib/mkcert.js` (medium): The code downloads and executes a remote binary without integrity checks and uses shell commands with dynamic input, posing security risks.
- `dist/esm/lib/patch-incorrect-lockfile.js` (medium): The code is a legitimate Next.js lockfile patcher but performs unverified network fetches driven by registry configuration and rewrites package-lock.json with fetched tarball/integrity data, creating a supply-chain tampering risk if the registry or network is compromised.
- `dist/esm/lib/recursive-copy.js` (medium): The code performs recursive file copying with potential path traversal and symlink following risks, but no clear malicious patterns were detected.
- `dist/esm/lib/turbopack-warning.js` (medium): The file appears to be legitimate Next.js Turbopack warning/validation code with no exfiltration, obfuscation, shell execution, or credential harvesting; only minor low-severity dynamic loading and process.exit behaviors are present.
- `dist/esm/lib/verify-partytown-setup.js` (medium): The code performs legitimate Next.js build-time operations for Partytown integration, including dynamic module loading and file system cleanup, but carries low-to-medium risk due to dynamic require and recursive deletion.
- `dist/esm/lib/verify-typescript-setup.js` (medium): This is legitimate Next.js TypeScript verification code with expected dynamic require, auto-install, and file-writing behaviors; no malicious patterns such as exfiltration, credential harvesting, obfuscation, or backdoors detected.
- `dist/esm/next-devtools/server/attach-nodejs-debugger-middleware.js` (medium): The middleware intentionally exposes the Node.js inspector debugger endpoint, which if reachable outside a trusted local development environment can lead to remote code execution and credential/data theft.
- `dist/esm/next-devtools/server/devtools-config-middleware.js` (medium): Dev-server middleware exposes an unauthenticated local POST endpoint that buffers unbounded input and writes user-controlled JSON to a cache file, presenting DoS and potential prototype-pollution concerns but no clear exfiltration, credential theft, or code-execution payloads.
- `dist/esm/next-devtools/server/launch-editor.js` (medium): The code is part of Next.js devtools for launching editors and contains legitimate process spawning and environment variable usage, but lacks robust input sanitization in some paths, posing a moderate security risk if misused.
- `dist/esm/next-devtools/server/restart-dev-server-middleware.js` (medium): The code implements Next.js dev-server restart and status endpoints; it contains no data exfiltration, credential harvesting, obfuscation, or backdoor patterns, but exposes unauthenticated process termination and cache-invalidation capabilities that could cause denial of service if the dev server were exposed.
- `dist/esm/next-devtools/userspace/app/forward-logs.js` (medium): Code appears to be legitimate Next.js devtools log forwarding, but it intercepts console/error output and transmits serialized runtime data over a WebSocket, which could leak sensitive information if enabled outside trusted development contexts.
- `dist/esm/next-devtools/userspace/pages/pages-dev-overlay-setup.js` (medium): This appears to be legitimate Next.js devtools code that installs a pages dev overlay and global error handlers; no clear malicious patterns such as exfiltration, credential harvesting, obfuscation, shell execution, or backdoors were detected.
- `dist/esm/server/api-utils/get-cookie-parser.js` (medium): No malicious patterns detected; the code performs standard cookie parsing with a benign runtime require of an internal Next.js module.
- `dist/esm/server/api-utils/node/api-resolver.js` (medium): The file contains legitimate Next.js API resolver logic with some inherent risks around header forwarding and network requests, but no clear malicious patterns or backdoors.
- `dist/esm/server/api-utils/node/try-get-preview-data.js` (medium): The code is part of Next.js's legitimate preview mode handling, but it contains weak validation (dev-mode fallback), dynamic requires of internal modules, and JSON parsing of decrypted cookie data without strict type checks, which could be exploited in misconfigured deployments.
- `dist/esm/server/app-render/action-handler.js` (medium): This is legitimate Next.js internal Server Actions handling code that performs intentional internal worker forwarding, with no malicious exfiltration, credential harvesting, obfuscated payloads, or backdoors, but it does include outbound fetch requests driven by request-derived origin/host metadata that warrant defensive scrutiny against SSRF and header/cookie leakage.
- `dist/esm/server/app-render/app-render-render-utils.js` (medium): The code is part of Next.js's rendering utilities and does not contain malicious patterns, but it calls an explicitly dangerous internal function for flushing immediates, which warrants caution.
- `dist/esm/server/app-render/app-render-scheduling.js` (medium): The code is a Next.js internal workaround that monkey-patches Node.js timer internals to guarantee atomic timer groups; it contains no exfiltration, credential harvesting, dynamic code execution, network, or process-spawning behavior, though its reliance on private timer fields is a fragile practice worth noting.
- `dist/esm/server/app-render/debug-channel-server.js` (medium): This file contains no malicious patterns; it is a legitimate debug channel switcher for Next.js that conditionally loads Node or Web implementations based on an environment variable, with production safeguards.
- `dist/esm/server/app-render/encryption-utils-server.js` (medium): The code is a legitimate Next.js encryption utility that manages encryption keys for server actions; no malicious patterns were detected, but it does handle sensitive encryption keys and environment variables.
- `dist/esm/server/app-render/entry-base.js` (medium): No clear malicious behavior was identified; the file contains standard Next.js internal re-exports and environment-conditional requires that are low-risk but warrant review.
- `dist/esm/server/app-render/instant-test-bootstrap.js` (medium): The file contains no data exfiltration, credential harvesting, obfuscation, miner, or process-spawning behavior; it generates a cookie-gated same-origin RSC prefetch inline script, which is a minor concern due to inline script generation and automatic fetch but consistent with its documented purpose.
- `dist/esm/server/dev/dev-validation-worker-pool.js` (medium): Legitimate Next.js dev-server validation worker code with expected dynamic module loading, worker spawning, and env propagation; no malicious patterns, exfiltration, or credential harvesting detected.
- `dist/esm/server/dev/get-source-map-from-file.js` (medium): This is legitimate Next.js internals for reading source maps, but it resolves user/file-controlled sourceMappingURL paths without sanitization, allowing potential out-of-scope file reads.
- `dist/esm/server/dev/hot-reloader-shared-utils.js` (medium): The code is a benign Next.js hot-reloader utility that checks version information via a fixed public npm registry endpoint; no malicious patterns were detected.
- `dist/esm/server/dev/hot-reloader-webpack.js` (medium): This is legitimate Next.js dev-server hot-reloader code with no evident malware, but it includes powerful dev-only features (inspector fetch, CORS reflection, debugger attach middleware, unauthenticated WebSocket HMR) that could be dangerous if the dev server is exposed beyond localhost.
- `dist/esm/server/dev/middleware-webpack.js` (medium): This is a Next.js webpack dev-tools middleware file; no overt malicious code (exfiltration, credential theft, obfuscation, backdoors, miners) is present, but it exposes unauthenticated dev-server endpoints that can launch editors with user-controlled paths, which could enable process spawning or path traversal if reachable.
- `dist/esm/server/dev/on-demand-entry-handler.js` (medium): This is legitimate Next.js development server code with no overt malicious patterns, though it handles unauthenticated HMR WebSocket messages and includes MCP handler dispatch that warrants caution in untrusted dev environments.
- `dist/esm/server/dev/use-cache-probe-pool.js` (medium): Code is a legitimate Next.js dev-only 'use cache' hang-detection probe pool; no exfiltration, credential harvesting, obfuscation, or shell execution detected, though it spawns workers with inherited env and computes worker paths dynamically.
- `dist/esm/server/lib/app-info-log.js` (medium): Code appears to be legitimate Next.js startup logging with minor file-write side effects (agent rules generation) and env file path enumeration, no clear malicious behavior detected.
- `dist/esm/server/lib/cpu-profile.js` (medium): The code is a legitimate CPU profiling utility for Next.js, but it reads environment variables to determine file write paths without sanitization or containment, presenting a low-to-medium arbitrary file write risk if those environment variables are attacker-controlled.
- `dist/esm/server/lib/module-loader/node-module-loader.js` (medium): This appears to be a legitimate Next.js runtime module loader, but it performs dynamic module loading with require()/__non_webpack_require__() and conditionally branches on environment variables, which warrants monitoring if the loaded module id can be influenced externally.
- `dist/esm/server/lib/module-loader/route-module-loader.js` (medium): No overtly malicious behavior, but the loader dynamically imports a caller-controlled module id through an injectable loader, a potential arbitrary module loading/execution risk that warrants review of the underlying NodeModuleLoader and callers.
- `dist/esm/server/lib/render-server.js` (medium): The code is part of Next.js internals and contains a potential dynamic import from an environment variable in test mode, but no overtly malicious patterns were found.
- `dist/esm/server/lib/router-utils/resolve-routes.js` (medium): This is a standard Next.js internal router utility file; it contains no malicious patterns such as exfiltration, credential theft, obfuscation, or backdoor behavior, though it includes minor trust-boundary considerations around proxy headers and test-gated file reads.
- `dist/esm/server/lib/router-utils/setup-dev-bundler.js` (medium): This appears to be legitimate Next.js development bundler code with no evidence of malicious intent; findings are limited to normal framework behaviors like dynamic requires, env var reads, and telemetry.
- `dist/esm/server/lib/start-server.js` (medium): This appears to be legitimate Next.js server startup code with a minor medium-risk shell command interpolation concern in getProcessIdUsingPort and several low-risk patterns typical of a development server.
- `dist/esm/server/load-components.js` (medium): The file is part of Next.js internal server-side code that loads manifests and page modules dynamically; while it uses eval-like manifest evaluation and computed path module loading, these are expected patterns for this framework and no clear malicious intent (exfiltration, backdoors, credential harvesting) is present.
- `dist/esm/server/load-manifest.external.js` (medium): The code executes manifest files as JavaScript via vm.runInNewContext, which is a potential sandbox escape vector if manifest contents are attacker-controlled, but no immediate malicious patterns are present.
- `dist/esm/server/mcp/get-or-create-mcp-server.js` (medium): The file itself contains no overt malicious patterns such as exfiltration, shell execution, or obfuscation, but it exposes a privileged MCP server with filesystem path forwarding and dev-server control tools that could pose security risks if exposed or if the underlying tool implementations lack input validation.
- `dist/esm/server/mcp/mcp-telemetry-tracker.js` (medium): Code is a benign telemetry counter, but it contains a runtime require() for an internal telemetry events module that warrants inspection of the referenced file.
- `dist/esm/server/mcp/tools/get-project-metadata.js` (medium): No clear malicious patterns found, but the file records telemetry on each tool invocation and returns the local project path, which should be reviewed in context of the telemetry tracker implementation.
- `dist/esm/server/mcp/tools/get-routes.js` (medium): The code is a legitimate MCP tool for scanning Next.js route files; no malicious exfiltration, credential harvesting, obfuscation, or command execution patterns were detected, though it does perform intentional filesystem scanning and internal telemetry tracking.
- `dist/esm/server/node-environment-baseline.js` (medium): The code performs top-level global object modifications and lazy module loading via require(), which are not overtly malicious but represent potential attack surfaces for supply chain compromise.
- `dist/esm/server/node-environment-extensions/console-file.js` (medium): The code patches console methods to mirror output to a file logger during development; while not overtly malicious, it introduces a data persistence mechanism that could leak sensitive console output if the log file is not properly secured.
- `dist/esm/server/node-environment-extensions/fast-set-immediate.external.js` (medium): Legitimate Next.js internal module that globally monkey-patches Node.js timer/nextTick primitives at import time, which is invasive but not malicious; no exfiltration, credential theft, dynamic code execution, or shell commands were found.
- `dist/esm/server/node-environment-extensions/node-crypto.js` (medium): The code is a legitimate Next.js instrumentation patch that wraps node:crypto functions to track dynamic IO during prerendering; no malicious exfiltration, backdoor, or process-spawning patterns were found, though the import-time monkey-patching is a notable behavioral concern.
- `dist/esm/server/node-environment-extensions/process-error-handlers.js` (medium): No data exfiltration, credential harvesting, obfuscation, or backdoor patterns detected, but the code intentionally overrides Node.js process-level error handling by removing all uncaughtException and unhandledRejection listeners, which is a potentially risky global side effect.
- `dist/esm/server/node-environment-extensions/unhandled-rejection.external.js` (medium): The code is not overtly malicious (no exfiltration, exec, or credential harvesting), but it aggressively monkey-patches Node.js process error-handling methods at import time to selectively suppress unhandled rejections, which is an invasive and potentially fragile practice that warrants scrutiny.
- `dist/esm/server/node-environment-extensions/web-crypto.js` (medium): The file is framework instrumentation that transparently wraps crypto.getRandomValues and crypto.randomUUID for prerender IO tracking; it contains no exfiltration, credential harvesting, obfuscation, or process spawning, but does monkey-patch global Web Crypto APIs which warrants caution.
- `dist/esm/server/node-polyfill-crypto.js` (medium): No malicious behavior detected, but the code mutates globalThis.crypto at import time and exposes a settable, configurable global property that could be overwritten by other code, weakening cryptographic trust boundaries on affected Node.js versions.
- `dist/esm/server/post-process.js` (medium): The code is a legitimate Next.js server utility for HTML post-processing with CSS optimization; it uses standard patterns with no clear malicious intent, though dynamic require and env var usage are noted as minor concerns.
- `dist/esm/server/render-result.js` (medium): This is legitimate Next.js internal code for handling render results with no malicious patterns; the dynamic require and environment variable access are standard framework patterns.
- `dist/esm/server/require-hook.js` (medium): This file is a legitimate Next.js require-hook that patches Node module resolution, but its monkey-patching of require and _resolveFilename represents a powerful, high-risk pattern that could be repurposed or abused if the package or its dependencies were compromised.
- `dist/esm/server/require.js` (medium): The code appears to be standard Next.js server-side page loading logic with dynamic requires and file system access, but no clear malicious patterns like data exfiltration or credential harvesting were found.
- `dist/esm/server/route-matcher-providers/helpers/manifest-loaders/node-manifest-loader.js` (medium): This Next.js manifest loader dynamically requires files based on a constructed path; while it appears to be a legitimate internal helper, the lack of path validation on the 'name' input poses a potential arbitrary module loading risk if inputs are not strictly controlled upstream.
- `dist/esm/server/route-modules/app-page/module.render.js` (medium): The file is a benign Next.js internal lazy-render helper; no data exfiltration, credential harvesting, obfuscation, network access, process spawning, or install-time execution was found, though it does use runtime require for an internal compiled module.
- `dist/esm/server/route-modules/route-module.js` (medium): This file is a legitimate Next.js internal module handling route preparation, manifest loading, and cache setup; no exfiltration, credential theft, backdoors, or obfuscation patterns were found, though it does contain dynamic module loading and eval-based manifest loading that are controlled by configuration.
- `dist/esm/server/web/adapter.js` (medium): This is a legitimate Next.js middleware adapter file with no evident malicious intent; the only notable concerns are a dynamic require gated by an environment variable and header/rewrite propagation behavior that could theoretically leak information if misconfigured.
- `dist/esm/server/web/get-edge-preview-props.js` (medium): This file is a benign Next.js edge-runtime helper that reads preview mode environment variables; no exfiltration, obfuscation, process spawning, or other malicious patterns are present in the provided code.
- `dist/esm/server/web/sandbox/context.js` (medium): The code is part of Next.js edge runtime sandboxing and uses dynamic code execution, environment variable exposure, and file system access, but these are inherent to its sandboxing purpose and not overtly malicious.
- `dist/esm/server/web/sandbox/fetch-inline-assets.js` (medium): The code lacks proper path validation when resolving file paths from user-controlled 'blob:' URLs, potentially allowing path traversal and unauthorized file reads.
- `dist/esm/server/web/sandbox/sandbox.js` (medium): The code contains several low-to-medium risk patterns related to sandbox context manipulation and dynamic evaluation, but no clear malicious intent or data exfiltration was detected.
- `dist/esm/shared/lib/bloom-filter.js` (medium): The file implements a standard Bloom filter with no exfiltration, credential harvesting, obfuscation, or command execution; only minor concerns around conditional dynamic require, environment variable usage, and unvalidated import data.
- `dist/esm/shared/lib/image-blur-svg.js` (medium): No exfiltration, credential harvesting, obfuscation, network, or process-spawning code is present, but the function builds an SVG string via unescaped string interpolation of caller-controlled values (notably blurDataURL), creating a potential injection vector.
- `dist/esm/shared/lib/router/utils/middleware-route-matcher.js` (medium): No malicious exfiltration, credential harvesting, or backdoor patterns detected, but the code compiles and executes externally-supplied regex patterns dynamically, which could pose a ReDoS or input-validation risk depending on how matchers are sourced.
- `dist/esm/shared/lib/router/utils/path-match.js` (medium): The file is a legitimate Next.js path-matching utility with no clear malicious behavior, but it has minor security considerations around dynamic regex construction and object spreading that could be abused by untrusted input.
- `dist/esm/shared/lib/size-limit.js` (medium): No clearly malicious behavior identified; only a minor concern about dynamic require() usage in an ESM module.
- `dist/experimental/testmode/fetch.js` (medium): The file is part of Next.js experimental test-mode fetch interception and does not exhibit overt malicious behavior, but it globally monkey-patches fetch and forwards full request details (including credentials and headers) to a local proxy, which could be abused if the proxy endpoint is compromised or misconfigured.
- `dist/experimental/testmode/playwright/next-fixture.js` (medium): No overt malicious code such as exfiltration, credential harvesting, obfuscation, or process spawning was found; however, the module's wildcard route interception and configurable fetch loopback behavior are test-mode capabilities that should be vetted before inclusion in non-test environments.
- `dist/experimental/testmode/playwright/next-worker-fixture.js` (medium): The file implements a scoped local proxy server for Next.js testmode with no clear malicious behavior, though the runtime-registered proxy handlers represent a minor attack surface.
- `dist/experimental/testmode/playwright/page-route.js` (medium): Test-mode Playwright route handler that proxies cross-origin fetch requests and manipulates headers; no malicious patterns such as exfiltration, credential harvesting, obfuscation, or dynamic code execution were detected, but the proxying behavior warrants caution.
- `dist/experimental/testmode/proxy/server.js` (medium): The file implements a test-mode HTTP proxy server that binds to all network interfaces and forwards fetch requests without apparent target restrictions, creating network exposure and potential SSRF/DoS concerns, though no overtly malicious (exfiltration, credential theft, RCE) patterns are present.
- `dist/export/helpers/create-incremental-cache.js` (medium): The code contains dynamic imports with user-influenced paths and global state modification, which pose moderate security risks if inputs are not properly validated.
- `dist/lib/download-swc.js` (medium): No overt malicious patterns (no exfiltration, credential harvesting, or shell execution) were found, but the script downloads and extracts remote tarballs without integrity verification, posing a supply-chain risk.
- `dist/lib/find-config.js` (medium): This is a legitimate configuration file loader from Next.js that dynamically imports config files found via directory traversal, which carries inherent code-execution risk if malicious config files are planted in parent directories, but contains no overtly malicious patterns.
- `dist/lib/helpers/get-cache-directory.js` (medium): The code appears to be a legitimate cache directory resolver, but it uses environment variables and file system checks that could be exploited if the module is used in a malicious context, though no overt malicious patterns are present.
- `dist/lib/helpers/get-npx-command.js` (medium): The file contains child_process.execSync usage and returns shell command strings for package manager invocation, which are low-to-medium risk patterns in isolation but could become dangerous if combined with untrusted input downstream.
- `dist/lib/helpers/get-online.js` (medium): The code appears to be a legitimate helper for checking online status and proxy configuration, with only minor concerns around shell command execution and environment variable access.
- `dist/lib/helpers/get-pkg-manager.js` (medium): No malicious patterns detected; the code performs standard package manager detection using environment variables, lockfile checks, and version commands, with only minor shell execution concerns.
- `dist/lib/helpers/get-registry.js` (medium): The code executes a shell command to retrieve the npm registry, using a package manager name derived from project files, which could theoretically enable command injection if that name is attacker-controlled; otherwise it appears to be a legitimate Next.js helper.
- `dist/lib/helpers/install.js` (medium): The code is a legitimate helper for spawning package manager install commands, with no malicious patterns such as data exfiltration, credential harvesting, obfuscation, or backdoors, though it does spawn processes based on caller-provided dependency names.
- `dist/lib/inline-static-env.js` (medium): This appears to be a legitimate Next.js build-time utility that inlines static environment variables into client and server bundles; no exfiltration, credential harvesting, dynamic code execution, or backdoor patterns were found, though the broad file rewriting and env inlining behavior should be understood by consumers.
- `dist/lib/memory/startup.js` (medium): Legitimate memory debugging code for Next.js that modifies V8 flags, registers a SIGUSR2 handler, and generates heap snapshots, with no malicious patterns detected but minor security considerations around heap snapshot data exposure.
- `dist/lib/mkcert.js` (medium): Legitimate mkcert wrapper, but contains shell-exec of a downloaded binary with unverified integrity and unsanitized host interpolation.
- `dist/lib/patch-incorrect-lockfile.js` (medium): The file performs legitimate-looking lockfile patching for @next/swc packages, but includes outbound network fetches, external lockfile mutation, and dynamic registry resolution that warrant caution despite no overtly malicious payloads.
- `dist/lib/require-instrumentation-client.js` (medium): The file is a benign Next.js internal loader that requires an aliased instrumentation module at import time; no exfiltration, credential harvesting, obfuscation, process spawning, or network activity is present, though the resolved module's behavior cannot be audited from this file alone.

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology