TavernKeeper Scan Report

ganon3264/focus

Commit a40e528 Reviewed Aug 10, 2026

No material or immediate-danger concern was identified in this review.

This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.

0 immediate danger 0 material 65 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

JavaScript analysis reported javascript.download-to-execution

Minor caution · medium confidence

The code builds buttons that let you restore or permanently delete items from a trash folder. It sticks information from the server directly into the button's code without cleaning it first. If the server sent back bad information (which would only happen if someone messed with your own server), it could run unwanted commands in your browser. Since you run your own server, this is unlikely to be a real problem, but it's still sloppy.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file uses `fetch` to retrieve a list of trashed items from the API and then constructs HTML containing inline `onclick` event handlers (lines 98-99). The `item.id` and `item.name` from the API response are interpolated directly into JavaScript code within the attribute values. While `item.name` is escaped for single quotes, `item.id` is not escaped for a JavaScript context, and neither value is HTML-encoded before being placed into an HTML attribute. This creates a stored/reflected XSS vector if an attacker can control the API response (e.g., via a compromised backend or a malicious third-party API). In the typical self-hosted deployment, the API is controlled by the same user, making exploitation by an external attacker unlikely. The code also uses `innerHTML` and `insertAdjacentHTML` with data from the API, adding additional XSS surface area. No evidence of active exploitation or malicious intent was found.

Impact: low · Exploitability: unlikely

Developer action: Replace inline `onclick` attributes with event listeners added via `addEventListener` or `element.onclick`. Sanitize `item.id` and `item.name` for both HTML context (via `textContent` or `encodeURIComponent` where appropriate) and JavaScript string context. Avoid string concatenation for HTML construction; consider using `document.createElement` and `textContent`/`setAttribute` instead. For the `innerHTML` and `insertAdjacentHTML` calls, ensure that any string values from the API are escaped or otherwise validated before insertion.

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/modals/shared-entity-modal.js:1-53

Expected scanner matches (61)

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses eval to load a normal part of the program so it can be tested. It never runs on a user's device and doesn't involve any outside information, so it's safe.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval on line 101 of test-edit-message.js loads a fixed project file (file) into a Node.js test environment to exercise its functions synchronously. This is a standard testing pattern for browser-side scripts and does not involve user-controlled input, external sources, or dynamic content. The file is a development artifact (file_role: test) and is never shipped or executed in the production application. There is no data flow from untrusted origins to this eval, and no concrete harm is possible.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-edit-message.js:101

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This test file uses eval to load a production script into the testing environment. The script being loaded is one that the developers themselves wrote, located at a fixed spot in the project folder. Since no outside data or user input goes into the eval, it's just a tool to run the tests—safe and expected.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval statement at line 101 reads a hardcoded file path (`edit-message.js`) and executes its contents. This file is a known production source script from the same repository. The path is entirely static, derived from `__dirname` and fixed relative segments; no user input or external data influences the argument. The call exists solely within a test file (`test-edit-message.js`) that sets up a mock DOM and global stubs before loading the target module for unit testing. This is a standard pattern for testing browser-oriented JavaScript in Node.js when the module relies on globals. Since the argument is constant and under the developer's control, there is no injection vector. The test file is never shipped to production users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-edit-message.js:101

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that uses eval to load the scroll-manager code for testing. Since it only loads a file that comes with the project and isn't used in the real app, it's harmless.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call on line 44 loads a hardcoded local file (scroll-manager.js) into a Node.js test harness to unit-test scroll-manager behavior. The file path is constructed from __dirname and static relative segments, not from any user or external input. This pattern is standard in test files for mocking and loading modules without a bundler. No production browser code is affected, and no untrusted data reaches eval.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-scroll-manager.js:44

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This test file purposely runs the project's own code in a special test environment to check if it works correctly. The code being run comes from a file inside the project itself, not from the internet or from a user. This is a normal testing technique and doesn't pose a security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval at line 47 loads a project-internal source file (file) into the test environment via a hardcoded relative path. This is a standard pattern in Node.js test suites to exercise code that attaches functions to the global scope. The loaded content is not user-controlled; it is the project's own production code committed to the same repository. No attacker-controlled input reaches this eval. The test file is not shipped to end users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-edit-entity.js:47

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that uses eval to load code from the project itself so it can run automated checks. The code being evaluated is a known file from the project, not any outside input. Test files like this only run during development and are never used by real users, so there is no danger.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-status-panel.js:72

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses JavaScript's eval to load a specific file that contains the main code being tested. It's a common way to set up tests for programs that run in a browser-like environment. The test only loads a file that is part of the project itself, so there is no security risk.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call on line 28 loads a known, committed production module (state-manager.js) from a fixed relative path into the test environment. This pattern is common in Node.js test suites when a module expects browser-like globals and cannot be loaded via a standard require. The file path is hardcoded and not influenced by any external or attacker-controlled input. The eval is only executed during test runs, never in the shipped application. No user data or untrusted content reaches the eval argument.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-state-manager.js:28

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This test file uses eval to load the project's own code so it can run tests. Since the code comes from the project itself and is only used by developers during testing, it is not a security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: Line 74 uses eval() to load a project module (file) from a fixed filesystem path. This is a common Node.js test pattern for loading a module's internals during unit testing. The evaluated code originates from the project's own source, not from any user or attacker-controlled input. The file is a test file (file) and is not shipped or executed in production contexts. Therefore, the eval poses no security risk in the built application.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-delete-mode.js:74

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that uses eval to load a piece of the app's own code so it can be tested. It only reads a specific file from the project itself, not anything from the internet or from user input. This is a normal testing practice and not a security problem.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call on line 24 reads a hardcoded project source file (file) and executes it in a test context after setting up global mocks. This is a standard pattern for loading a module that expects a browser-like global environment (window, document, localStorage). The file path is fixed and relative to the test directory; no user input or external untrusted data reaches the eval argument. The test file is not shipped to users and does not affect production behavior.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-list-manager.js:24

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This is a test file that loads the project's own code using eval. The file it loads is always the same, and the test is only run by the developer, not by users. This is a normal way to test browser code in Node.js and is not a security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval on line 24 reads a hardcoded project source file (list-manager.js) and executes it in a test environment where all browser globals are mocked. The file path is fixed within the test, not influenced by any external or user input. This is a common pattern for loading non-CommonJS modules in Node.js test runners. No attacker-controlled data reaches the eval, and the executed code is part of the project's own shipped source. There is no evidence of exposure to untrusted input, and the test file has no production deployment.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-list-manager.js:24

JavaScript analysis reported javascript.download-to-execution

Expected behavior · low confidence

This file is part of the app's user interface and uses network requests to save settings and create items, which is normal for this kind of app. It does not run any remote code or execute hidden commands.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file contains dynamic window property assignments and fetch calls, but no actual code execution sink such as eval, Function constructor, or innerHTML. The htmx.ajax call fetches HTML from a configurable endpoint, but the endpoint is under project control and no attacker-controlled path is demonstrated. Dynamic property names are used for registering callbacks, not for executing attacker-supplied code. The scanner correlation between network retrieval and a code execution sink is not substantiated by the actual code.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/ui/list-manager.js:3-18

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This line is in a test file and loads the project's own code into the test environment. It always reads a fixed file from the developer's computer, not anything from the internet or a user, so it cannot cause any harm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval on line 24 loads a local project source file (`reasoning-utils.js`) from a hardcoded, relative path within the test directory. This pattern is standard for unit testing JavaScript modules without a bundler in a Node.js environment. The evaluated string comes from the developer-controlled repository, not from any untrusted or user-supplied input. There is no attacker-controlled data flow, no exfiltration, no persistence, and no harm beyond the test scope. The scanner signal (xray unsafe-stmt) is a static pattern match that does not account for the safe, intentional test context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-reasoning-visibility.js:24

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses eval() to run the main lightbox code so it can check that the functions work correctly. The code being run comes from a file in the project itself, not from anything a user or attacker could control. This is a normal way to test JavaScript modules in Node.js.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval() call on line 78 is part of a unit test file that loads the production module lightbox.js from the local filesystem and executes it to expose functions for testing. The source string read by fs.readFileSync comes from a hardcoded path within the repository; it is not derived from user input, network data, or any untrusted source. This pattern is standard for Node.js tests that need to evaluate a module's code in a mocked browser environment. No attacker-controlled data flows into the eval argument. The test file (file_role: test) is not shipped or executed in production. The eval use is proportionate to its testing purpose and is transparent in the source code.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-lightbox.js:78

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This file manages the app's settings and state. It stores info like which character or provider you've selected and sends that data to the backend server to save it. It does not download and run any code from the internet, so there's no security risk here.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file contains fetch() calls to internal API endpoints (/api/chats/ and /api/settings/active-provider) for persisting application state, which is standard client-server communication for a frontend application. There is no dynamic code execution (eval, Function constructor, innerHTML injection, or similar) present in the code. The scanner rule appears to flag the co-occurrence of network retrieval and a code execution sink, but no such sink exists in this file. The fetch responses are not processed as code; they are simply API calls. No arguments from network responses are passed to any execution primitive. The code is a straightforward state manager module.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/core/state-manager.js:1-68

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A security scanner flagged a test message as a possible bad link, but it's just a harmless description like 'cap: only 5 active' used to explain what a test is checking.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The flagged line (line 149) contains a static assertion message string 'cap: only 5 active' inside an assertEqual call. This is plain test documentation text, not a URL, hostname, or any network reference. The JS-X-Ray 'shady-link' signal is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-notifications.js:149

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A security scanner flagged a line in a test file as a suspicious link, but that line is just a pretend function returning a fake URL for testing purposes. It has no effect on users.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: This candidate is a JS-X-Ray 'shady-link' signal on line 47 of the test file. The line defines a mock for global.URL.createObjectURL returning a hardcoded string 'blob:url'. This is a test helper, not an actual network call or link to an external service. No user data is involved, and the mock is only used within the test harness. There is no security concern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-lightbox.js:47

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The test file uses eval() to load a JavaScript file from the project's own code. This is fine because the file is a fixed part of the project and no outside user can change what code gets run. It's just a testing helper, not something users would encounter.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval() call on line 23 is used in a test file (file) to load the providers.js module by reading it from a hardcoded project path. The file path is constructed from __dirname and known subdirectories; no user-controlled or untrusted input reaches the eval argument. This is a common testing pattern in Node.js to set up global mocks before executing the module under test. The eval does not introduce dynamic code from external sources and is not present in production code paths. No attacker trigger exists in this test context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-extract-data.js:23

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A security scanner flagged a line in a test file that sets up a fake URL creator. In tests it is normal to replace real browser features with harmless stubs. This line does nothing dangerous.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: Line 55 sets global.URL.createObjectURL to a stub function that returns the fixed string 'blob:url'. This is a standard test mock to prevent real URL API calls. No actual link or network destination is referenced; the 'shady-link' signal is a false positive from static analysis of the string 'blob:url' in a test environment.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-file-staging.js:55

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This eval is in a test file and is used to load the actual code being tested into the test environment. It's a common and safe technique. The file being loaded is always the same static file from the project, not anything provided by a user or attacker. Tests are only run by the developer and never shipped to users, so there is no security risk.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call at line 46 of the test file loads a hardcoded static JavaScript module into the global scope for unit testing. The argument is a synchronous file read of a known project path (file). There is no user input, no dynamic string construction, and no external data flow. This is a standard Node.js testing pattern where the module under test assigns properties to the global/window object. The code runs only when tests are executed, not in production. No attacker-controlled input reaches the eval, and no secrets or credentials are involved. This cannot be exploited in a shipped build.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-message-renderer.js:46

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This test file uses eval to load a project's own JavaScript file so it can run unit tests. The file being loaded is part of the project itself, not something a user or attacker could control. This is a normal testing technique and not a security concern.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval at line 28 loads a hard-coded project source file (state-manager.js) into the test runner. This is a standard pattern in Node.js testing to evaluate a module's source without requiring module exports. The path is fixed and points to a file within the project's own static directory. There is no user-controlled input, no network data, and no runtime variability in the source being evaluated. The file is not shipped to users; it is only executed during development testing. No privilege escalation, code injection from untrusted origin, or exfiltration path is present.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-state-manager.js:28

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This is a test file that uses eval to load the main code for testing. It's only used during development and has no effect on the live app. A normal user would never trigger this code.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The evaluated code is an inline eval of a project source file read from a known hardcoded path, occurring only inside a test file. The eval is not reachable by any user input or network request during production use. This is a standard testing pattern to load browser-targeted modules into a Node.js test environment without a bundler. There is no data flow from untrusted sources, no persistence, and no attacker control over the evaluated string.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-message-renderer.js:46

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

A security scanner flagged an eval statement in a test file. The test loads the real code to check that it works correctly, but this only runs during development tests, not when you use the app. There is no danger.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: This candidate is a JS-X-Ray 'unsafe-stmt' signal on line 78 of the test file. The line uses eval() to execute the source code of lightbox.js loaded from the local filesystem. This is a standard Node.js testing technique to invoke the module's functions in a mocked environment without modifying the production source. The evaluated code is entirely from a known local file, and no attacker-controlled input reaches the eval. The test never runs in production.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-lightbox.js:78

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This is a test file that uses eval to load a module for testing purposes. Since it's only used by developers when testing and never runs in the real app, it's not a security concern.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval at line 84 loads the message-pruner.js module into a Node.js test harness using a hardcoded project path. This is a standard unit-test pattern for client-side code that expects a window global. The test file is not shipped or executed in production. No attacker-controlled input reaches the eval argument; the file content is static and project-supplied. Therefore the eval poses no security risk to end users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-message-pruner.js:84

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This test file uses eval() to run the notification code in a controlled test environment. Since the code being evaluated comes from a file that is part of the project itself (and not from any outside source), there is no security risk. This is the same as importing a module, just done without a module system. Test files like this are never shipped to users.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval(src) call at line 58 is used within a test harness to load the notifications.js module's source code into the test environment. The src variable is read from a project-internal file (static/js/ui/notifications.js) using fs.readFileSync with a hardcoded local path. No user input, network data, or untrusted external source flows into this eval. The test file also overrides setTimeout, clearTimeout, and DOM methods to create a deterministic, isolated test sandbox. This is a standard pattern for testing non-modular JavaScript in Node.js without a module bundler. There is no potential for code injection because the source is entirely project-controlled and accessed via a fixed relative path. The scanner signal (unsafe-stmt) is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-notifications.js:58

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This code retrieves a list of AI models and OpenRouter routing options from the server, but it only shows them in dropdown menus. It never runs any downloaded code, so there is no security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The candidate code contains two fetch() calls: one to api.providerFetchModels (line 119) and one to /api/providers/openrouter/endpoints/ (line 159). Both responses are parsed as JSON and used only to dispatch custom DOM events or populate UI option arrays. No eval, Function constructor, innerHTML injection, or any dynamic code execution sink is present in lines 119-160 or elsewhere in the provided file. The scanner rule 'javascript.download-to-execution' is a false positive; there is no executable content derived from network responses.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/modals/providers.js:119-160

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The test file uses eval to load a piece of the app’s code so it can test it in a fake browser environment. This is a normal way to test code that was written for a web browser. The eval only runs during tests and only loads a file from inside the project, so there is no danger.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval on line 72 loads the source code of status-panel.js from a fixed local file path. The string passed to eval is constructed from the file contents plus a small wrapper that exports functions to the global window object. No untrusted or user-controlled input is included; the data source is a static project file read via fs.readFileSync with a path relative to __dirname. This pattern is standard in Node.js test harnesses for frontend modules that expect a browser global scope and lack module exports. The test file is not shipped to end users and runs only during development or CI. Therefore, the eval does not create a security vulnerability.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-status-panel.js:72

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

The code was flagged because it uses both 'fetch' (to send files to a server) and 'innerHTML' (to show icons). But the icons are fixed pictures, not anything that came from the server or a user, so there is no risk of malicious code execution.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The scanner rule 'javascript.download-to-execution' flagged the co-occurrence of a network retrieval primitive (fetch) and an innerHTML assignment in the same file. However, the innerHTML assignments (lines 33, 43-46) are limited to hardcoded SVG sprite strings returned by window.getSvgSprite and do not incorporate any data from the fetch response. The fetch at line 150 uploads file data to a server endpoint and only parses JSON response for attachment IDs—no dynamic code execution or command injection is present. Therefore, the flagged pattern does not constitute a security issue.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/messages/file-staging.js:1-150

JavaScript analysis reported javascript.xray.encoded-literal

Expected behavior · high confidence

A security scanner flagged a short string of letters and numbers as possibly hidden data, but it's just a test color code, not a secret or encoded message.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.encoded-literal in this repository.

Contextual assessment: The encoded-literal signal on line 95 corresponds to a hex color string '6366f1' passed as an argument to the hexToRgb function during a unit test. This is a static test input, not encoded or obfuscated data. It is a legitimate test case for parsing a hex color without the '#' prefix.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.encoded-literal
File role: test
Source: tests/frontend/test-theme-manager.js:95

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This file handles theme colors and fetches data from the app's own API. It never runs code downloaded from the network or executes anything dangerous. The scanner warning was a false alarm—fetching data and changing colors is normal and safe.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file contains fetch calls for theme CRUD operations and a character endpoint, but no response data is passed to eval, innerHTML, Function, setTimeout with string, or any other dynamic code execution sink. The only DOM mutation is setting CSS custom properties via document.documentElement.style.setProperty, which is not a code execution primitive. There is no data flow from network responses to any execution sink. The scanner alert is a false positive based on co-occurrence of fetch and DOM manipulation, not actual dangerous behavior.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/ui/theme-manager.js:38-107

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

This code is just reading a streaming chat response from the server, line by line. There's no hidden link or malicious network call.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The scanner flagged a 'shady-link' signal at line 168, which is part of standard Server-Sent Events parsing logic. The code checks if a line starts with 'data: ' and then slices and trims the content for JSON parsing. No fixed suspicious URL or malicious link is present. This is standard and expected behavior for a chat streaming client.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: production
Source: static/js/core/chat-stream.js:168

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

This file just shows an empty backup message with a folder icon. There is no code that connects to the internet or does anything suspicious. The scanner warning was a false alarm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The supplied source is a static HTML fragment containing an SVG icon and a message placeholder. No JavaScript code, URL strings, network fetch calls, or dynamic data flows are present. The 'shady-link' scanner signal appears to be a false positive triggered by the XML namespace attribute in the SVG. No evidence of network access, credential handling, data exfiltration, or any executable behavior exists in the provided lines.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: production
Source: static/js/features/backup-manager.js:1

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This file loads extra parts of the page (like a prompt arranger panel) when you pick a preset. It uses a library called HTMX to fetch that content from the same server and insert it. That's a normal, safe way to build a web app – not a security problem.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The flagged region (lines 79–104) contains a normal HTMX `ajax` call that fetches a server partial based on the user-selected preset value and swaps it into the DOM via `innerHTML`. This is the intended pattern for dynamic UI content loading within the application. The `htmx.ajax` call is a standard library function; the URL is constructed by `window.api.partials.promptArranger` using the preset select value, which is a same-origin request. No raw `fetch`, `eval`, or dynamic script execution is present. The scanner heuristic correlated a network retrieval with an innerHTML swap (a code-execution sink), but in this context the swap is performed by HTMX and the response content is server-controlled and expected. No attacker-controlled input reaches the response body, and no direct execution of untrusted content occurs.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/ui/status-panel.js:79-104

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses a JavaScript eval to load a message-pruning script so it can run unit tests. Since the file being loaded is always the same local file and never user-controlled, this is a normal testing technique, not a security issue.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval on line 84 of this test file loads a fixed, hardcoded production JavaScript file (message-pruner.js) from a known path within the repository. There is no user input, runtime variable input, or attacker-controlled data involved. The pattern is standard for Node.js test harnesses that need to evaluate an IIFE-style module in a simulated browser environment. This eval is never executed in production or shipped to end users. It is a test-only construct with no exploitable attack surface.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-message-pruner.js:84

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A test checks that a provider's address is stored correctly using a harmless example URL. No real connection is made.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The URL is a test assertion string used to verify that the base_url field is correctly preserved. No actual network access occurs during test execution. The string is compared as part of validation logic. This is expected test data.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-extract-data.js:38

JavaScript analysis reported javascript.download-to-execution

Expected behavior · medium confidence

This code loads parts of the page from the server, which is normal for this app. It doesn't run dangerous commands from the internet or take user input in a risky way. There's no evidence this could be misused.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file uses htmx.ajax to load a server-side partial into a DOM element via innerHTML swap. This is a standard pattern for dynamic content loading in this project, which uses a local Python server. The presetId parameter originates from internal application state (StateManager or DOM parsing), not from direct untrusted user input. The fetch call for file uploads also retrieves data but only processes JSON safely. No dynamic code execution (eval, Function, etc.) is present. The scanner correlation does not reflect an actual exploitable path because the server endpoint is controlled by the application and the inputs are not user-controllable in a meaningful way.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/modals/edit-entity.js:1-38

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses eval to load one of the project's own code files so it can run tests against it. Since the file being loaded is part of the project itself and this only happens during testing, it is a normal and safe practice.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call on line 24 loads a fixed, project-owned source file (reasoning-utils.js) from disk for unit testing purposes. The file path is constructed from __dirname and hardcoded relative path segments, with no user-supplied or attacker-controlled input involved. The file role is 'test', meaning this code runs only during development and testing, never in production. The eval simply enables the module to be executed in a DOM-mocked global context so that its functions are available for test assertions. There is no dynamic code generation, no untrusted data flow, and no persistence or exfiltration risk.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-reasoning-visibility.js:24

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The test file uses a common trick to load the code being tested by reading and running it. This is safe because it only happens when developers run tests, not when the app is used normally.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval call on line 35 reads the production module source file using a hardcoded path and executes it to load the module in the test environment. This is a standard pattern for testing browser-focused JavaScript modules in Node.js without a build step. The test file is not shipped or executed in production, and there is no attacker-controlled input reaching this eval. Therefore, it poses no security risk in shipped code.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-backup-manager.js:35

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A test uses a sample local address as example data, but no actual browsing or connection happens.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The URL is test fixture data passed to a mock form object. It is only read as a field value and never used to initiate a connection. This is standard practice in unit tests to simulate provider configuration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-extract-data.js:30

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The test file loads its own JavaScript code using eval() to test it. This is a normal way to run code for testing purposes, and since the code being loaded comes from the project's own files, there is no danger.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: Line 44 uses eval() to execute the contents of the project's own scroll-manager.js file, read via fs.readFileSync from a hardcoded relative path. This pattern is common in test files to load a module into a mocked global environment for unit testing. The input is a fixed file within the project's own source tree; there is no dynamic user input, no external data flow, and the code is only executed during test runs. The scanner signal (unsafe-stmt) is triggered by the use of eval, but in this context it does not introduce a security risk because the evaluated string is not attacker-controlled.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-scroll-manager.js:44

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The scanner flagged an eval() call as potentially dangerous. In this case, it's only used in a test file to load up the theme manager functions for testing. No user data is involved, so it's not a real security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The unsafe-stmt signal on line 83 corresponds to eval(src + '...') where src is read from a hardcoded theme-manager.js file using fs.readFileSync. This eval is used within a Node.js unit test to load functions that are not exported by the module. No user input or external data reaches the eval argument. The eval is confined to the test environment and does not run in production or affect users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-theme-manager.js:83

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This file lets you select and delete messages in a chat app. It uses standard web techniques (fetch and htmx) to talk to the server and update the page. There is no hidden code execution or dangerous behavior here—it's just what a normal delete function does.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The scanner rule 'javascript.download-to-execution' flagged a correlation between network retrieval (fetch, htmx.ajax) and a putative code execution sink. However, the actual source code in this file does not contain any dynamic code execution mechanism such as eval, Function constructor, innerHTML assignment of untrusted content, or similar. The fetch call is used to POST a bulk delete request to an API endpoint, and the response is only checked for HTTP status; htmx.ajax performs a GET to reload a message list partial safely via the htmx library, which processes the response as HTML in a managed way. No attacker-controlled input reaches an executable context. The correlation is a false positive; no code execution path exists.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/messages/delete-mode.js:1-68

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The code uses eval to load a character editor for testing. This is a normal way to test browser-based code in Node.js. The eval is not used in the actual app that users run, so there is no danger to anyone using the program.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: This test file uses eval() to load and expose functions from a browser-oriented module (char-editor.js) into Node.js's global scope for unit testing. The evaluated string is a hardcoded combination of the project's own source file and a fixed snippet that assigns function references to window. No user-controlled or external input is involved. The file is not shipped or executed in production; it is solely a developer tool for test execution. The scanner flagged eval() as a generic unsafe statement, but in this test context it is standard practice for testing JavaScript modules that rely on global/window bindings. There is no attacker-controlled path, no credential exposure, and no persistent harm.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-char-editor.js:69

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This code loads a message from the app's own server to let you edit it. It uses the data to create text boxes and labels, but it never runs any code from that data. All text that appears is safely cleaned up before being added to the page. This is exactly how a message editing feature should work.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The scanner flags a correlation between a network fetch (line 120) and a potential code execution sink. However, the actual code uses `fetch` to retrieve a chat message from the application's own API and then renders the content into DOM elements using `createElement`, `innerHTML`, and `escapeHtml` for user-controlled fields (function name, arguments, result, image URL). There is no dynamic code execution (eval, Function, setTimeout with string) present. The `innerHTML` assignments use hardcoded HTML templates and escaped data, which is a standard and safe UI pattern. The scanner's download-to-execution signal is a false positive because no executable code path arises from the network data.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/messages/edit-message.js:1-120

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The test file uses eval() to load the app's route-helper code so it can check that all API paths are correct. This is a normal testing trick—like opening a textbook to check your answers. The file being loaded comes from the project itself (not from a stranger), and the test only runs when the developer is working on the code. No one using the app will ever run this test.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval() call on line 7 reads a hardcoded project source file (static/js/core/api-paths.js) for unit testing. This is a standard Node.js testing pattern where a non-module file that defines globals is loaded into the test runner's scope. The file path is static and determined at build time; no user or attacker input is involved. The test file is not shipped as part of the runtime application and only runs during development or CI. There is no mechanism for an external attacker to control the evaluated code. Even if the source file were compromised, that would require write access to the repository—a separate, out-of-scope threat. Therefore, the use of eval here is proportional to its legitimate testing purpose and poses no concrete risk to end users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-api-paths.js:7

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The test file loads a small notification module into the test environment so it can check that the notification popups work correctly. It only loads the project's own code, not anything from the internet or from a user. This is a normal part of testing and is not dangerous.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The `eval(src)` on line 58 is used in a test file to load the project's `notifications.js` module into the Node.js test context so that its exported functions (showToast, showErrorToast, etc.) can be unit tested. The source is read from a hardcoded project path (`static/js/ui/notifications.js`) via `fs.readFileSync`. No user input, network data, or attacker-controlled content reaches this eval. The test runs only in a development/test environment and is not shipped to production. This pattern is standard for testing non-modular frontend code in Node.js and does not represent a security concern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-notifications.js:58

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

This is a test file that loads its own project code to run tests. It uses a JavaScript 'eval' command, but only on a file the project itself wrote, so there is no risk of someone sneaking in malicious code from outside.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: Line 7 uses eval with fs.readFileSync to load a project-owned source file in a unit test. This is a common pattern in Node.js testing to evaluate a module's code without a proper module system. The input is a hardcoded path to a file within the same repository (static/js/core/api-paths.js). No attacker-controlled or untrusted data reaches the eval. The test file is not shipped to end users; it is only executed during development or CI. Therefore, there is no demonstrated security exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-api-paths.js:7

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

The other signal is just a test mock that simulates a browser API, not real network access. It exists only in the test file and has no effect on the actual app.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: Line 31 mocks the global URL object with stub methods (createObjectURL, revokeObjectURL) for use in test fixtures. It performs no actual network access or URL parsing. This mock is only present in the test environment and is not shipped to users. No security concern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-backup-manager.js:31

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A security scanner flagged a test message as a possible bad link, but it's just a harmless description like 'cap: oldest evicted' used to explain what a test is checking.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The flagged line (line 150) contains a static assertion message string 'cap: oldest evicted' inside an assert call. This is plain test documentation text, not a URL, hostname, or any network reference. The JS-X-Ray 'shady-link' signal is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-notifications.js:150

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The code uses eval() in a test file to load a helper module. The evaluated source code comes from a file the developer wrote, and it's only used during testing. Since nobody else can control what gets evaluated, it's safe.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval statement in this test file reads a hardcoded project source file (file) via fs.readFileSync and appends a hardcoded string to expose functions for unit testing. The input to eval is entirely developer-controlled; no user input or external data flows into it. The file is a test file (file_role: test) and is never shipped to end users. This is a standard pattern for loading modules in a test environment without a module bundler. There is no security vulnerability.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-theme-manager.js:83

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

A security scanner flagged an eval statement in a test file. This test reads the app's own code from a fixed file and runs it to check if it works. It is a normal testing technique and does not run any outside or harmful code.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: Line 83 uses eval to load and execute the project's own file-staging.js source code in a test environment. This is a common pattern for unit testing browser-like modules in Node.js. The source path is hardcoded and references a known project file. There is no dynamic or untrusted input; the eval is part of test setup and not present in production code. No security risk.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-file-staging.js:83

JavaScript analysis reported javascript.download-to-execution

Expected behavior · medium confidence

This file fetches data from the app's own server to manage characters, and updates the page accordingly. That is normal for any web app. The scanner saw that the code also builds some HTML to show dialogs, but there is no evidence this is dangerous or could be exploited.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file uses fetch() calls to communicate with the backend API, which is standard and expected for a frontend web application. The rule flags a correlation between network retrieval and a potential code execution sink, but no dynamic code execution (eval, Function, setTimeout string) is present. The only candidate sink is a template literal passed to window.customConfirm, whose implementation is not provided and may safely handle HTML. No attacker-controlled data flow to a code execution sink is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/features/char-editor.js:5-52

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

A security scanner flagged a test message as a possible bad link, but it's just a harmless description like 'cap: evicted removed after animation' used to explain what a test is checking.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The flagged line (line 152) contains a static assertion message string 'cap: evicted removed after animation' inside an assertEqual call. This is plain test documentation text, not a URL, hostname, or any network reference. The JS-X-Ray 'shady-link' signal is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: test
Source: tests/frontend/test-notifications.js:152

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses eval to load a piece of the app's own code so it can run checks on it. That's a normal way to test browser code in Node.js, and it only runs the app's own files, not anything from a stranger or the internet.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call reads a project-owned JavaScript file from a hardcoded local path and executes it within a mock DOM environment. This is a standard pattern for unit-testing browser modules in Node.js. The evaluated content is a first-party source file, not user-controlled or external input. No untrusted data flow reaches eval. The test fixture does not introduce a runtime security risk.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-delete-mode.js:74

JavaScript analysis reported javascript.xray.unsafe-regex

Expected behavior · medium confidence

This is a normal part of the app that replaces automatically loaded images with placeholders you can click to load. The regex used is safe and does not pose a security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex in this repository.

Contextual assessment: The regex on line 55 replaces img tags with external src attributes with click-to-load placeholders. It uses non-greedy quantifiers and clear delimiters, making catastrophic backtracking unlikely. The scanner signal 'unsafe-regex' does not show a demonstrated vulnerability.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-regex
File role: production
Source: static/js/messages/message-renderer.js:55

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that uses eval to load a regular part of the app's code so the tests can check that it works. It's like a practice run – the evaluation only happens when the developer runs tests, not when you use the app. The test reads a fixed file from the project's own source, so there's no way for an attacker to abuse it.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call on line 83 reads and executes a local, hardcoded project source file (file) within a Node.js test environment. This is a standard pattern for unit-testing a client-side module that exports via an IIFE and global assignments. The path is constructed with __dirname and literal path components, not from any external or user-supplied input. The file is a test file (file_role: test) and does not run in production or shipped contexts. There is no data flow from untrusted sources into eval, no concealment of purpose, and the file's comment explicitly documents the intent.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-file-staging.js:83

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The test file uses a special JavaScript function (eval) to load the actual code it's testing. This is a common technique in test files and doesn't create any security risk because the path is fixed and the code is only run during testing, not in the real app.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: This eval call in a test file synchronously loads a fixed local module (edit-entity.js) into the test environment's global scope. The file path is hardcoded to the project's own static directory. No untrusted input reaches the eval argument. This is a standard pattern for testing frontend scripts that are not written as modules and rely on global/window exports. The eval only executes during test runs, never in production. No security exposure exists.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-edit-entity.js:47

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This code gets a chat response from a server and displays it on the page. That's exactly what a chat app should do. It's not doing anything dangerous like running hidden code.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The scanner correlated a network retrieval primitive (fetch at line 136) with a code execution sink (innerHTML assignments at lines 43 and 282). The fetch posts chat data to the server's streaming endpoint, a core app function. The innerHTML calls render chat messages via window.renderMessage, which is assumed to safely convert markdown to HTML. No dynamic code execution (eval, Function constructor) is present. The combination is expected for a chat application that displays AI responses.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/core/chat-stream.js:1-136

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses eval to load its own code (the backup manager feature) into a simulated browser environment so it can be tested. It's a common technique and not a security issue because the code being run was written by the same developers and is not influenced by outside users.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval on line 35 executes a hardcoded file path (backup-manager.js) read via fs.readFileSync. This is a standard testing pattern to load a browser-oriented module into a Node.js test environment after setting up mock globals. The argument is not user-controlled; the file is the project's own source code. No external input, no attacker control, and no production execution. The eval does not introduce a security vulnerability.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-backup-manager.js:35

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This code fetches a list of backups from the app's own server and displays them. It builds the list using standard web techniques. There is no attempt to run hidden code or steal information—the buttons just call the app's own restore or delete functions. The item IDs come from the server, which you control, so this is safe normal behavior.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The scanner flags the co-occurrence of `fetch` and `innerHTML` assignment as a potential code-execution path. The code fetches a JSON list of backups from the project's own API (`window.api.backups`), then builds UI strings that include backup IDs and sizes. The `innerHTML` assignments (lines 40–41, 46–53, 56–78, 80–82) insert these server-supplied values into the DOM. However, no dynamic code execution (eval, Function constructor, setTimeout with string) occurs. The inline `onclick` handlers refer to hardcoded `BackupManager.restore(...)` and `BackupManager.delete(...)` with the backup ID interpolated as a string literal. Since the backup ID originates from the same local server the user operates, and no untrusted external input enters this flow without server sanitization, the combination does not create a remotely exploitable vulnerability. The use of `innerHTML` is consistent with typical client-side UI rendering for a hobbyist project, and no credential handling, exfiltration, or hidden behavior is present.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/features/backup-manager.js:1-43

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This code updates chat messages on screen by asking its own server for new HTML and swapping it in, exactly like a normal web app refreshes content. It only talks to the app's own backend, so there is no hidden danger.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The file fetches partial HTML from the same-origin server and replaces DOM nodes using standard DOM manipulation (replaceWith, innerHTML). No eval, remote code execution, or data exfiltration. The fetch target is a relative URL controlled by the application's own backend; user-supplied values are only used to construct the URL parameter from existing DOM attributes. The innerHTML calls are on markdown content processed by a designated renderer, which is standard chat UI behavior. The scanner correlation between network retrieval and code execution sink does not indicate actual vulnerability in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: static/js/messages/message-refresh.js:1-45

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This test file uses a special command to load and run the character editor code so it can check that everything works correctly. The command only uses a file that is part of the project, not anything from outside or from a user. This is a normal way to test code.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The eval call is in a test file and operates on a local module source file read from disk with a known static path. No user-controlled or external input reaches the eval. The pattern loads the module for unit testing functions, which is a standard testing approach in Node.js environments. There is no mechanism for an attacker to influence the evaluated string, and the file is part of the project's own codebase.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: test
Source: tests/frontend/test-char-editor.js:69

JavaScript analysis reported javascript.xray.unsafe-stmt

Expected behavior · high confidence

The test loads the actual code file to run tests against it. This happens only when developers are testing, not when users use the app.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-stmt in this repository.

Contextual assessment: The eval loads a fixed project source file at test time using an absolute derivation of the path. The file path is known and controlled entirely by the project. No external or user input influences the content. This is a standard technique used in Node.js test setups to load modules that have not been bundled. It does not execute in production.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-stmt
File role: test
Source: tests/frontend/test-extract-data.js:23

Related contextual observations

Unreviewed HTML template in customConfirm may allow DOM injection

low risk · low confidence

When you delete a character, a confirmation box shows the character's name. If someone created a character with a tricky name containing code, and the popup isn't careful, that code could run. Since the app controls the character data, this is unlikely, but worth reviewing the popup function.

Technical assessment

In promptDeleteChar (lines 29-52), a template literal containing charName from btn.dataset.charName is passed to window.customConfirm. If that function uses innerHTML without sanitization, an attacker who can inject a malicious character name (e.g., via imported character data) could cause DOM-based XSS. The implementation of customConfirm is not visible in the evidence, so the risk is unconfirmed but noted.

Impact: low · Exploitability: unlikely

Developer action: Review the window.customConfirm function to ensure it escapes HTML before inserting into the DOM, or use safe DOM methods like textContent.

Sources:

static/js/features/char-editor.js:29-52

False positive: static assertion strings flagged as shady-link

low risk · high confidence

A security scanner thought some test messages might be bad links, but they are just harmless text used to explain what each test checks.

Technical assessment

The JS-X-Ray scanner flagged three lines in a test file as potential 'shady-link' signals. All three lines contain static assertion message strings used to describe test expectations (e.g., 'cap: only 5 active'). These strings are not URLs, hostnames, or network references. The file is a test file (not shipped to users) and performs no network access. The signal is a false positive from static analysis.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

tests/frontend/test-notifications.js:149-152

Test file uses eval for module loading

low risk · high confidence

In testing, developers sometimes use eval to load a piece of code. Here it's done with a file the developer wrote, and it's only for tests. It's not dangerous.

Technical assessment

The test file employs eval to dynamically evaluate a project source file and expose its functions. This is a common technique in Node.js test environments when a module is not bundled or exported. The eval input is entirely static and hardcoded, posing no security risk.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

tests/frontend/test-theme-manager.js:83

Coverage and limitations

Inventory: 227 files · 2473812 bytes
Contextual coverage: 62 of 62 candidates assessed

JavaScript coverage

Status: Incomplete
Candidates: 57 files · 343274 bytes
Representations: 57 raw · 13 decoded · 2 normalized · 0 bundle modules
Stage scans: 57 raw signatures · 57 raw AST · 57 raw OpenGrep · 15 derived signatures · 4 derived AST · 15 derived OpenGrep

Unresolved JavaScript stages

static/js/features/backup-manager.js — derived-ast / parse
static/js/features/backup-manager.js — normalize / unsupported
static/js/messages/edit-message.js — derived-ast / parse
static/js/messages/edit-message.js — normalize / unsupported
static/js/modals/shared-entity-modal.js — derived-ast / parse
static/js/modals/shared-entity-modal.js — normalize / parse
static/js/ui/lightbox.js — derived-ast / parse
static/js/ui/lightbox.js — normalize / parse
static/js/ui/list-manager.js — derived-ast / parse
static/js/ui/list-manager.js — normalize / parse

Tools

inventory 0.1.0 — completed
tavernkeeper-static 4 — completed
gitleaks 8.30.1 — completed
opengrep 1.26.0 — completed
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1 — completed
osv-scanner 2.4.0 — not-applicable
zizmor 1.28.0 — not-applicable
malcontent 1.25.7 — completed

Limitations

This advisory review cannot prove the absence of unknown behavior.
JavaScript analysis was incomplete, so this first-filter scan supports no clean conclusion about unobserved behavior.

Technical scan identity

Full commit: a40e528d939de0d7aaaa9e8373469665ad5480bc
Completed: Aug 10, 2026
History depth: 1 commit
Method: Deterministic evidence with contextual review
Reviewer: nano-gpt.com · deepseek/deepseek-v4-flash:thinking
Scanner: 0.1.0
Scanner policy: 4
Rule catalog: 1
Contextual policy: 4
Ecosystem context: sillytavern-community-v1
Prompt: contextual-review-v7
Assessment schema: contextual-assessment-v2
Review provenance: 53 fresh / 0 reused groups · 62 fresh / 0 reused candidates
Review source reports: none
Review usage: 801776 input · 83693 output · 10240 cache read · 0 reasoning tokens
Report: 2c51c5e680ad3f95302e005a3208d1dae8372b45cb807dcbe63c9d8d24e0092c