The extension loads its own internal code files from its own folder and runs them so the extension can work. It does not download or run code from anywhere unexpected, and no user input controls what gets loaded or executed. This is a normal way for this type of extension to load its pieces.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The `new Function(xhr.responseText)()` call is a module-loading mechanism. The XHR target URL is constructed from BASE_URL (derived from the extension's own script tag src) concatenated with hardcoded relative paths such as 'lib/config.js'. No user-controlled or remote input flows into the URL or the executed code. The fetched content is the extension's own bundled sub-modules, which is a common pattern in SillyTavern extensions that do not use ES module imports. The synchronous XHR and dynamic execution are proportionate to the stated purpose of loading the extension's internal library files.
The extension loads its code files in a way that freezes the page briefly until each file is ready. This is not a security problem but can make the interface feel less responsive and may cause browser warnings in the future.
Technical assessment
The module loader uses XMLHttpRequest in synchronous mode (xhr.open('GET', moduleUrl, false)). Synchronous XHR is deprecated and blocks the main thread, which can cause UI jank or warnings in modern browsers. This does not introduce a security vulnerability but is a code-quality and compatibility concern.
Impact: low · Exploitability: unlikely
Developer action: Consider migrating to async loading or ES module imports to avoid blocking the main thread and future browser compatibility issues.