The flagged code is part of a standard, widely used AI runtime library (ONNX Runtime Web) that this extension bundles for local image processing. The dynamic code generation is how the library's underlying WebAssembly engine connects to JavaScript efficiently. It does not use any user-controlled or external data to build code, and it is not custom to this extension.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The scanner matched a `new Function` call inside the bundled ONNX Runtime Web (v1.27.0) library. This is standard emscripten embind glue code that dynamically generates method-caller functions to bridge JavaScript and WebAssembly-compiled C++ code. The function bodies are constructed from internal type-registration metadata during library initialization, not from user input, network data, or extension configuration. This pattern is inherent to how emscripten optimizes WASM interop and is present in the upstream onnxruntime-web package unchanged. The extension's stated purpose is local AI image restoration via ONNX Runtime, so bundling this library is expected and proportionate.
This is part of the official ONNX Runtime Web engine that the extension bundles to run AI image processing locally in the browser. The dynamic code construction flagged here is a standard internal mechanism that ONNX Runtime uses to connect its WebAssembly core to JavaScript. It does not use any user input or network data, and it is a known, expected pattern in this library.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched `new Function(...)` on line 49 is inside the `Pb` function of an Emscripten-generated embind binding layer for ONNX Runtime Web. This is the standard embind method-caller factory: it builds a small wrapper function from internal type-conversion helper names and a generated body string, then instantiates it with `new Function`. The keys and values passed in (`h`) are internal wire-type binding objects (`toValue`, `argFromPtrN`, `getStringOrSymbol`, etc.), not user-controlled or network-supplied data. The file path and surrounding code (WebAssembly instantiation, pthread management, WebGPU bindings, Ort* exports) confirm this is the bundled `onnxruntime-web` runtime glue, consistent with the project's stated purpose of local Real-ESRGAN inference via ONNX Runtime Web. No external data flow reaches this constructor; it is static code generation at module initialization.