No material or immediate-danger item was identified.
Expected scanner matches (18)
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files so it can run tests against it. The code being loaded is a local file from the project itself, not anything from the internet or from user input. This is a normal, if informal, way to test browser code outside a browser.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call is inside a test file that constructs a minimal DOM and global stubs, then loads the project's own frontend script by reading a local file relative to the test directory and evaluating it. The input is a fixed path to a first-party source file within the repository, not attacker-controlled data. This is a hobbyist test harness pattern for loading a browser-oriented script under Node.js. No network destination, no credential access, no persistence, and no obfuscation are involved.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files so it can be tested. It only reads files already inside the project and does not use any outside input, 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 flagged eval reads a local repository JavaScript file via a relative path constructed from __dirname and executes it in the test process. This is a common hobbyist pattern for loading browser-oriented modules that depend on global document/window objects during Node.js tests. The file path is hardcoded to a known repository source file, no external or attacker-controlled input reaches the eval, and the code runs only in a 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-scroll-manager.js:44
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This code is part of a test file that loads the project's own JavaScript source so the tests can run it. It only uses files already in the repository and does not accept outside input, 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 operates on a local repository source file read via fs.readFileSync and appends a fixed string to expose functions on the global window object for unit testing. The evaluated content is not derived from user input, network data, or external sources. This is a test-only harness pattern with no runtime reachability in production 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-status-panel.js:72
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads the project's own source code into memory so the tests can run. It only reads a fixed file from inside the project, and nothing from outside can influence it. This is normal for tests and 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 call reads a hardcoded local source file from the repository's own static directory and executes it to load the StateManager into the test scope. This is a common hobbyist pattern for loading browser-oriented JS that lacks CommonJS exports into a Node.js test harness. The file path is static, no external or attacker-controlled input reaches eval, and the code runs only during local test execution.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files by reading it from disk and running it, so the tests can check how it behaves. The file being loaded is fixed and part of the project itself, so there is no way for outside input to sneak in harmful code here.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched eval reads a hardcoded local file path within the repository test directory and executes it to load a browser-oriented UI module into the test global scope. The file path is static, no external or user-controlled input reaches it, and this occurs only in a test harness file. This is a common hobbyist pattern for loading modules that attach to a mocked window object during unit tests.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads the project's own code to test it. It only uses files already in the repository and does not run anything from outside sources, 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: 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-lightbox.js:78
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This test file loads one of the project's own JavaScript files by reading it from disk and running it, so the test can check how that code works. The content being run is a fixed local file that ships with the project, not anything a user or attacker can control. This is a normal, if slightly old-fashioned, way to test browser code in a Node environment.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call reads a local, committed project source file from the repository's own static directory and evaluates it so the test file can access functions defined in a browser-oriented module within a Node test environment. The evaluated content is a trusted local file path constructed from __dirname, not user input, network data, or runtime-controlled content. This is a test-only pattern with no attacker-controlled input reaching the 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-extract-data.js:23
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads another file from the project itself so it can run tests on it. It only reads files already in the project and does not take input from users or the internet, so it is not a security concern.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call reads a local source file from the project's own static directory and evaluates it to load the module under test in a Node test harness. The path is constructed from the test file's directory and a fixed relative path; no external or attacker-controlled input reaches it. This is a common hobbyist test-loading pattern and poses no runtime risk to 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-message-renderer.js:46
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files so it can be tested. The code only reads a fixed local file from within the project folder and does not accept outside input, 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 flagged eval reads a local project source file via a path built from __dirname and fixed relative components, then executes it to load an IIFE module into the test's mock global scope. The file path is not attacker-controlled, no network or external input reaches the eval, and the surrounding code is a test harness that mocks browser APIs and asserts module behavior. This is a common hobbyist pattern for loading browser-oriented IIFE modules in a Node test environment.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files by reading it from disk and running it, so the tests can check how it behaves. It only uses files already inside the project, and nothing from outside can influence what gets run. This is a normal, if unconventional, testing approach.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call reads a fixed local source file from within the repository using a path built from __dirname and static relative segments. No external or attacker-controlled input reaches the evaluated string. This is a test-only module-loading technique used to execute the project's own frontend script under a DOM mock. It runs only in the test harness, not in the shipped application, and the evaluated code is the project's own committed source.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads one of the project's own JavaScript files to check that its URL paths are correct. It only reads a fixed local file from the repository, so there is no way for outside input to influence what gets run.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call reads a hardcoded, repository-local source file (api-paths.js) relative to the test file and evaluates it so the test can assert on its route-builder constants. No external or attacker-controlled input reaches the eval. The file path is fixed at test time and the evaluated content is first-party project source. This is a common hobbyist pattern for loading browser-oriented JS in a Node test harness.
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 one of the project's own JavaScript files by reading it from disk and running it. This is a normal way for a simple test setup to load code that normally runs in a browser. There is no external or user-controlled input involved, 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 executes source read from a local project file (static/js/ui/notifications.js) within a test harness. The input is a committed project source file, not user-controlled or network-sourced data. This is a common lightweight test-loading pattern for scripts that expect a browser global scope, and poses no security risk in this 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-notifications.js:58
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that loads the project's own code to test it. It only runs code that is already part of the repository, not anything from users or the internet, 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 executes a source file read from a fixed local path within the repository and appends a fixed string to expose internal functions for unit testing. No external, user-controlled, or network-derived input reaches the eval. This is a test-only harness pattern with no runtime reachability in shipped application 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-theme-manager.js:83
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This test loads one of the project's own JavaScript files so it can be tested. It does not run any code from users or the internet, 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 reads a committed local source file via a relative path inside a test harness. No untrusted or remote input reaches eval; it is a common hobbyist pattern for loading a non-module browser script into a Node test environment. The evaluated content is project source code already present on disk.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test helper that loads the project's own front-end code into the test environment so it can be tested. It only reads files that are already part of the project, does not contact the internet, and does not handle any secrets. This is normal for tests.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched eval call is inside a test file that reads a local, first-party frontend module from the repository and evaluates it in a Node.js process that has stubbed browser globals. This is a common hobbyist pattern for loading browser-oriented IIFE code under Node without a bundler. The input to eval is a file path constructed from the test directory and a fixed relative path within the project; no external or attacker-controlled data reaches it. There is no network activity, credential access, persistence, or obfuscation.
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
This is test code that loads one of the project's own JavaScript files so it can be tested. It only reads files already in the repository and does not run anything from outside, 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 is in a unit test file and reads a static local JavaScript file from the repository to load the module under test. No external or attacker-controlled input reaches eval; the content is a committed source file. This is a common hobbyist test pattern for loading browser-oriented modules in a Node test harness.
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
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This code is inside a test file and loads one of the project's own JavaScript files so the tests can run against it. It does not accept outside input and only runs during testing, not in the actual application.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The eval call reads a fixed local project file via a relative path constructed from __dirname and executes it in a test harness. No external or user-controlled input reaches the eval argument. The file path is hardcoded to a known source file within the repository. This is a test-only pattern for loading a non-module script into the test environment.
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:44
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This code runs only in tests and loads a file that is already part of the project so the test can check its functions. It does not use any outside or user-provided input, 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 operates on a local repository source file read via fs.readFileSync from a fixed relative path within the project. It appends assignments to expose functions for unit testing. No user-controlled or network-sourced data reaches eval. This is a test-only harness pattern for loading non-module source into a mock global environment.
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