TavernKeeper Scan Report

ganon3264/focus

Commit ca33c86 Reviewed

No material or high-risk 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 high 0 material 25 low

What this review found

No material or high-risk item was identified.

Minor cautions

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Minor caution · high confidence

This is a test file that loads one of the project's own JavaScript files to test it. The way it loads the file uses a risky function, but because it only reads a local file from the project itself and never touches outside input, it is not a security danger. It is just a slightly messy way to load code for testing.

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 from a known relative path and executes it to load the module under test within a mock environment. The input is not user-controlled or network-derived, so there is no injection vector. Using eval to load source is a code-quality weakness; a module loader or vm sandbox would be preferable, but the data flow poses no security risk in this test context.

Impact: low · Exploitability: unlikely

Developer action: Consider replacing eval with require or a vm-based loader for cleaner and safer test module loading.

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.javascript-eval
File role
test
Source
tests/frontend/test-delete-mode.js:74
Expected scanner matches (17)

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that loads one of the project's own local JavaScript files so it can run tests against it. It only reads files already inside the repository and does not fetch or execute anything from the internet or from user input.

Technical evidence

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

Contextual assessment: The flagged eval call occurs inside a test file that constructs a mock DOM and global environment, then reads a local committed source file from the repository and evaluates it to bring its definitions into scope for unit testing. The path is built from __dirname with relative segments pointing only to repository-local source. No network content, user input, or remote data flows into the eval. This is a common hobbyist pattern for testing browser-oriented scripts that are not packaged as modules.

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

The test file loads another script from the project itself to test it. It uses a basic method to run the script in the test environment, which is normal for testing purposes and does not pose a security risk.

Technical evidence

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

Contextual assessment: The flagged eval call reads a local JavaScript file from the repository using a hardcoded relative path and executes it within the test environment. This is a common pattern in hobbyist test suites to load browser-oriented scripts that rely on mocked global objects like window and document. There is no external input, network fetch, or obfuscation 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-scroll-manager.js:44

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file that loads the project's own JavaScript code into the test runner so it can check how the code behaves. It only uses code that is already part of the project and does not touch the internet or any user data, so it is not a security problem.

Technical evidence

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

Contextual assessment: The matched eval call occurs inside a frontend test harness. The test reads a local repository source file via fs.readFileSync and evals it in the test process to expose bare functions for unit assertions. No network, user input, or external data is involved; the evaluated content is committed project source. This is a common hobbyist test-loading pattern and poses no 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-status-panel.js:72

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The test file loads one of the project's own JavaScript files so it can be tested. It only reads a local file that ships with the project and does not run anything from outside or from user input.

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 from the repository's own static directory to load a browser-oriented module into the Node test environment. The path is hardcoded and relative to the test file, not derived from user input or network data. This is a common hobbyist pattern for testing scripts that rely on global scope rather than module exports. No external destination, obfuscation, or persistence is 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-state-manager.js:28

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is part of a test file. It loads one of the project's own JavaScript files into the test environment so the tests can check how it works. It does not run anything from outside the project or handle any secrets, so it is not a security problem.

Technical evidence

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

Contextual assessment: The flagged dynamic execution occurs in a frontend unit test file. The test sets up browser-like globals such as window, document, localStorage, fetch, and htmx, then reads a local static UI JavaScript file from the repository and evaluates it in the test process so the module can be exercised under Node. The evaluated content is a committed local source file, not user input, network data, or remote content. There is no credential access, network exfiltration, persistence, or obfuscation. This is a common hobbyist 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-list-manager.js:24

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is test code that loads one of the project's own files into memory so the tests can run. It only uses files already in the repository and does not execute anything from outside, so it is not a security risk.

Technical evidence

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

Contextual assessment: The eval call occurs inside a frontend test file. It reads a local repository source file (static/js/ui/lightbox.js) via fs.readFileSync and evaluates it in the test process to attach the module's functions to a mocked global window object. No external or user-supplied input reaches eval; the evaluated content is the project's own committed source. This is a common hobbyist test-harness pattern for loading non-module browser scripts under Node.js.

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

The code uses eval only to load a local project file during automated tests so the test can run browser code in Node. It does not evaluate anything from users or the internet, so it is not a security threat.

Technical evidence

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

Contextual assessment: The flagged eval call occurs inside a unit test file. It reads a local, committed JavaScript source file using a relative path constructed with path.join and evaluates it in the test context to load browser-oriented code under Node.js. No user input, network data, or untrusted content is passed to eval. This is a common hobbyist pattern for testing non-module browser scripts and 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-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 same project so it can test the code. It uses a blunt method to do so, but only on a fixed local file with no 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 reads a local project source file via a relative path and executes it to load a browser-oriented module into the test's global scope. This is a common hobbyist test-harness pattern for modules that attach to window rather than exporting. The path is fixed and internal to the repository; no external or user-controlled input reaches eval, and no network or persistence behavior is 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-message-renderer.js:46

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a test file loading one of the project's own JavaScript files so it can be tested. It only reads files already in the repository and does not use any external or user-controlled 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-relative JavaScript file from the test directory and executes it in the test process. This is a common hobbyist pattern for loading a browser-oriented IIFE module that attaches exports to a mocked global window object during Node.js tests. The path is constructed from __dirname and fixed relative segments, no user input or network data reaches eval, and the file role is test-only.

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 script loading the project's own frontend code so it can be tested. It only reads a fixed file from the repository itself and does not run anything from outside or from user input.

Technical evidence

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

Contextual assessment: The flagged dynamic execution occurs inside a frontend unit test file. The test reads a local, hardcoded source file from the repository and evaluates it in the Node test environment to load frontend code that attaches to global objects rather than using module exports. No untrusted input, network data, or user-controlled paths are involved, and the behavior is confined to the 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-reasoning-visibility.js:24

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The code uses a potentially dangerous command to load a local file for testing purposes. Because it only reads a specific file already in the project and only runs during tests, it does not pose a security risk to users of the application.

Technical evidence

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

Contextual assessment: The flagged eval statement reads a local, hardcoded source file from the project repository to load it into the test environment. This is a common pattern for testing frontend scripts that are not structured as Node.js modules. It does not process external or user-supplied input and only executes during the test phase.

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

This is a test file that loads the project's own notification code so it can be tested. It uses eval only to run code that already belongs to the project, not anything from users or the internet. This is a normal way for small hobbyist projects 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 flagged eval reads a local repository file (static/js/ui/notifications.js) via fs.readFileSync and evaluates it to load browser-oriented UI code into a Node test harness. The evaluated content is committed project source, not user input, network data, or untrusted configuration. The file role is test, and the surrounding code sets up deterministic timers and DOM mocks before evaluating the module. No exfiltration, persistence, obfuscation, or external destinations are present.

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 another file from the same project to test its color-related functions. The code being loaded is part of the project itself, not anything from the internet or from user input. There is no security risk here; it is just an unconventional way to test code that was not designed to be imported normally.

Technical evidence

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

Contextual assessment: The flagged eval call occurs inside a test file. Its sole input is a source file read from the local repository tree via fs.readFileSync using a path relative to the test directory. No external, user-controlled, or network-sourced data reaches the eval. The purpose is to load a non-modular frontend script and expose its internal functions for unit testing. There is no network call, credential access, persistence, or obfuscation. This is a common hobbyist pattern for testing browser-oriented scripts that lack module exports.

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 is a test file that loads one of the project's own JavaScript files so the tests can run it. It only reads files already inside the project folder and does not contact the internet or handle secrets. This is a normal, if informal, way to test browser-style code outside a browser.

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 fs.readFileSync from a relative path inside the project and executes it to load a browser-oriented IIFE module into the Node test environment. This is a common hobbyist test harness pattern for modules that attach to window/global without exporting. No network, external input, credential access, persistence, or obfuscation is involved. The executed code is committed project source, not attacker-controlled data.

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 code uses a potentially dangerous command to load another file, but this is happening inside a test script and only loads a file that is already part of the project. It does not use any outside information, so it is safe.

Technical evidence

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

Contextual assessment: The eval call is used in a test file to load a local, repository-controlled JavaScript file into the test environment. This allows the test to mock browser globals before the module script executes. The path is constructed using relative directory traversal and does not incorporate any external or user-controlled input, making it a standard test setup pattern rather than 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

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The code uses a potentially dangerous command to load another file from the project for testing purposes. Because it only loads files that are already part of the project and runs only during tests, it does not pose a security risk.

Technical evidence

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

Contextual assessment: The scanner flagged the use of eval at line 44. The code evaluates the contents of a local file read from the repository's static directory to load it into the test environment. This is a common pattern in hobbyist Node.js tests to execute browser-oriented JavaScript files that lack module exports. The evaluated code is part of the repository itself, not external or user-supplied input, and runs within a local test context. There is no network fetching, obfuscation, or credential handling 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-entity.js:44

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

The code uses a dynamic execution feature to load another file from the same project for testing. It does not run any code from outside the project, so it is not a security risk.

Technical evidence

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

Contextual assessment: The flagged eval call executes a local source file read via fs.readFileSync within a Node.js test script to expose browser-oriented functions to the test harness. No untrusted or external input is passed to eval.

Impact: none · Exploitability: unlikely

Developer action: Consider using Node's vm module or refactoring the source file to support standard module exports instead of eval for better test maintainability, though this is not a security issue.

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

Related contextual observations

Local file loaded via eval in test harness

low risk · high confidence

The test uses a shortcut to load project code so it can be tested. It only uses files already in the project and does not pose a security threat.

Technical assessment

The test script reads a local JavaScript file using fs.readFileSync and passes it to eval to attach its functions to the global scope for testing. This is a common workaround for testing browser-oriented code in Node.js and does not process external input.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Local file loaded via eval in test harness

low risk · high confidence

The test loads one of the project's own files using a function that can run arbitrary code. Since it only uses a fixed local file and no outside input, it is not a real threat, but a safer loading method would be better practice.

Technical assessment

The test reads a static JavaScript file from the repository and executes it with eval to populate the mock global environment. The path is hardcoded and relative, and no external data influences the content. This is a test-only pattern with no runtime exposure, but eval-based loading is fragile and could mask errors or accidental global pollution.

Impact: low · Exploitability: unlikely

Developer action: Use require or a vm sandbox instead of eval to load the module under test.

Sources:

Test harness loads local source via eval

low risk · high confidence

The test loads the project's own code file to test it. Since it only uses files already in the repository and runs only during tests, this is normal for this kind of project.

Technical assessment

The test file sets up mock globals and then evaluates a repository-local file to test its functions. The evaluated content is a committed source file within the project, not external or user-supplied data, so the dynamic execution is scoped to the test environment and matches the stated testing purpose.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Test harness uses eval to load local module

low risk · medium confidence

The test loads project code in a rough way that works but is not ideal for maintenance. It is not a security problem, just a code-quality nitpick.

Technical assessment

Using eval to load a local file works for this test but is fragile and can mask syntax errors or accidental global pollution. A module wrapper or a test bundler would be more maintainable, though this does not introduce a security risk in the test context.

Impact: low · Exploitability: unlikely

Developer action: Consider wrapping the loaded module for testability instead of evaling the file contents; no security change required.

Sources:

Test harness loads local module via eval

low risk · high confidence

The test is just loading the project's own code to test it. Nothing from outside the project is executed.

Technical assessment

The test file mocks browser globals and then uses eval with fs.readFileSync to load a fixed local module file for testing. No external or user-controlled data is involved, and execution is confined to the test process.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Local source loaded into test harness via eval

low risk · high confidence

The test runs the project's own notification code in a simulated environment. Nothing from outside the project is executed.

Technical assessment

The eval target is produced by reading a path constructed from __dirname and fixed relative segments pointing to the project's own static JS directory. No external or user-controlled data reaches the eval. The test harness mocks globals and timers before evaluation, consistent with unit testing browser UI code in Node.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Use of eval in test harness

low risk · high confidence

The test uses a risky-looking way to load its own code for testing. It is not dangerous here because only local project code is involved, but a more standard loading method would be cleaner.

Technical assessment

Using eval to load module source into the test process works but is fragile and bypasses normal module isolation. A require or module-loader shim would be safer and more maintainable, though this does not introduce a security vulnerability in the test context.

Impact: low · Exploitability: unlikely

Developer action: Consider replacing eval-based loading with a require or module shim for maintainability and clearer isolation.

Sources:

Coverage and limitations

Tools

Limitations

Technical scan identity