TavernKeeper Scan Report

prolix-oc/Lumiverse-SimTracker

Commit 1a76d48 Reviewed

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

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

0 immediate danger 0 material 21 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Minor caution · medium confidence

The scanner flagged the extension running template code on demand. That fits the project's purpose: templates are custom mini-programs users can author or import, and this feature runs a template's data-processing snippet when the template is active. The real concern is only that an imported template shared by someone else could contain unwanted code — but importing someone else's template already runs its script in the page when displayed, so this is a known consequence of the feature, not a hidden one. Nothing in the supplied evidence shows the developer using this to do anything beyond the

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval. The match applies to this repository.

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

Impact: medium · Exploitability: plausible

Developer action: Document that imported preset JSON can contain executable template logic, and consider gating first execution of a newly imported preset behind an explicit user confirmation and surfacing a visible indicator when a preset's logic block runs. Restricting the sandboxing illusion (for example, removing the Function constructor in favor of a declarative transform, or exposing the logic block in the preset editor for review before activation) would reduce the chance that a user imports executable code unknowingly.

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.javascript-eval
File role
production
Source
src/frontend.ts:1107
Deterministic technical evidence (9)
  • Dependency advisory GHSA-xhpv-hc6g-r9c6:pkg:4114756074b3c1883ca427a6 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-xjpj-3mr7-gcpf:pkg:2c93c7ce30edf86304d17bbe applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-3mfm-83xf-c92r:pkg:146840b9eb3231ae1d463c20 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-2qvq-rjwj-gvw9:pkg:bde04755dd174b8acbe6de92 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-442j-39wm-28r2:pkg:c54738cea96a333e19b8bd79 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-7rx3-28cr-v5wh:pkg:2d05cf734c06fd6d1e77b848 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-9cx6-37pm-9jff:pkg:ca52f57e7f6518348696e910 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-48c2-rrv3-qjmp:pkg:15fc6ff22ccf7f2f103da797 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-2w6w-674q-4c4q:pkg:d25708df68737694eb8e6977 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

Contextual expected matches (8)

JavaScript analysis reported javascript.xray.prototype-pollution

Expected behavior · high confidence

The scanner saw code that mentions prototype-related special names and assumed danger. Actually, this code is a safety check from a widely used template library that blocks those special names from being abused. It protects against the very problem the scanner was worried about.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.prototype-pollution. The match applies to this repository.

Contextual assessment: The flagged line is part of the bundled handlebars 'createNewLookupObject' internals, which explicitly block dangerous properties (__proto__, __defineGetter__, __defineSetter__, __lookupGetter__, __lookupSetter__) by setting them to false in a null-prototype lookup object. This is the library's own prototype-pollution defense, not a pollution sink. A nearby source-map utility similarly only tests for the '__proto__' string to prefix it in output. There is no demonstrated code path where untrusted keys are merged into Object.prototype or Function.prototype. The scanner matched defensive literal references, which is the inverse of the risk the rule targets.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.prototype-pollution
File role
generated
Source
dist/frontend.js:567

JavaScript analysis reported javascript.xray.obfuscated-code

Expected behavior · high confidence

The file looks 'obfuscated' to a scanner only because it is a machine-assembled bundle of many libraries into one file. It is actually fully readable, keeps its original comments and structure, and shows no effort to hide what it does.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.

Contextual assessment: The file is a Bun/esbuild-generated bundle of a TypeScript extension: helper-prefixed runtime shims (__create, __defProp, __commonJS, __toESMCache) at line 1, followed by readable, unminified CommonJS and ESM module sections with original node_modules paths preserved in comments. Every examined region (handlebars, source-map utilities, the yaml library, project trackerData.ts code) is plain readable JavaScript with no hex/string-array/eval-packed obfuscation. The obfuscation signal is a low-confidence false positive triggered by the bundle's generated prelude and dense nested syntax, not by any concealment technique. Nothing is hidden: the code retains comments, identifiers, and structure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.obfuscated-code
File role
generated
Source
dist/frontend.js:1

JavaScript analysis reported javascript.xray.unsafe-regex

Expected behavior · high confidence

The flagged 'unsafe' patterns are simple, well-bounded text-matching rules from the standard YAML library this project bundles. They are like basic checklist rules for recognizing numbers and dates, not the kind of tangled patterns that can freeze a browser by choking on specially crafted input. This is a false alarm from an automated tool that flags cautious-looking patterns without understanding the context.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.

Contextual assessment: The flagged 'unsafe-regex' signals at line 7908 and the 10 other occurrences fall within bundled code from the well-known 'yaml' package (eemeli/yaml) inlined into the generated dist/backend.js. The regexes in the supplied window are bounded, linear-time patterns: alternations of character classes and simple quantifiers (e.g., the plain-scalar safety check at line 7908, the numeric/int/float tag tests such as /^[-+]?[0-9][0-9_]*/, and the timestamp matcher constructed as a concatenation of bounded numeric groups with explicit character-count limits like {1,2} and {1,4}). None of these patterns exhibits the catastrophic nested quantifier structure (e.g., (a+)+ or overlapping alternation over unbounded input) that causes exponential backtracking. They run against short field values like scalar strings and YAML token labels, not attacker-controlled large inputs in this file's context, and the parsing is wrapped in try/catch by the project's own tracker-payload parser. JS-X-Ray's 'unsafe-regex' heuristic is a static complexity estimate that commonly flags any regex with multiple quantifiers or alternations regardless of actual backtracking risk; the medium confidence and the fact that

Impact: none · Exploitability: unlikely

Developer action: No change is warranted. These regexes come from a widely used YAML parsing library and pose no demonstrated denial-of-service or security risk in this context. The scanner's 'unsafe-regex' heuristic can be safely treated as noise here.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-regex
File role
generated
Source
dist/backend.js:7908

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

The flagged 'link' is just part of the standard YAML data format's official tag names (the yaml.org prefix), repeated throughout the bundled YAML parsing library. It is like flagging every occurrence of 'http' in documentation about web addresses. No code here connects to the internet or sends data anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.

Contextual assessment: The flagged line sits in bundled code from the well-known 'yaml' package (eemeli/yaml) inlined into the generated dist/backend.js. The surrounding source consists of standard YAML directive and tag-registration logic (e.g., the default '!!' handle mapped to the official yaml.org tag prefix, scalar tag definitions for bool/int/float/timestamp, and tag resolution helpers). These 51 occurrences are the recurring literal 'tag:yaml.org,2002:' tag-prefix strings inherent to YAML's standard tag system. No outbound network call, fetch, WebSocket, or credential/data exfiltration path appears anywhere in the supplied window; the text merely constructs YAML directives like '%TAG ! handle prefix' for serialization. The scanner's 'shady-link' heuristic appears to have pattern-matched the repeated domain-like literal (yaml.org) without retaining context, a classic false positive on an identifier-like string rather than an external endpoint. The host's network fetch logic, if any, is not in this window, and nothing here demonstrates a destination, untrusted-input path, or attacker-controlled trigger.

Impact: none · Exploitability: unlikely

Developer action: No change warranted. The scanner's repeated-literal heuristic should be treated as noise on this library code; no fix or code change is needed.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.shady-link
File role
generated
Source
dist/backend.js:7100

JavaScript analysis reported javascript.xray.unsafe-regex

Expected behavior · high confidence

The scanner flagged some pattern-matching expressions as potentially slow. Looking at them, they are simple, short patterns from standard YAML parsing and the extension's own data cleanup, applied to small pieces of text. There is no realistic way to make them hang a user's browser.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.

Contextual assessment: All inspected occurrences are short, linear regexes inside the yaml library schema tag definitions (float/int/bool/null/timestamp/merge forms) and small handlebars/source-map project regexes, including the project's own cleanupPlusSigns used to preprocess LLM-emitted tracker data. None exhibit catastrophic nested quantifiers like (a+)+ over overlapping alternations. They are applied to short scalar tokens and small tracker blocks, so exponential backtracking is not plausible. Even a hypothetical pathological input would at worst cause a local tab slowdown, which does not meet the materiality bar. The scanner flags these as unsafe due to their nested grouping shape, but no demonstrated denial-of-service 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_families-1
Rule
javascript.xray.unsafe-regex
File role
generated
Source
dist/frontend.js:1848

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

The scanner saw a network call near template-rendering code and flagged it as suspicious. In reality, the network call only asks the local app for its version number, and the template rendering is the extension's advertised feature. Nothing is downloaded from the internet and executed.

Technical evidence

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

Contextual assessment: The scanner correlated a network retrieval primitive with a dynamic code sink in the same file, but the supplied source shows no data flow between them. The only network call is a same-origin fetch to the host's local system-info endpoint, used solely to read a backend version string for a version comparison; the response body is never executed or passed to a code sink. The apparent execution sink is Handlebars template compilation, which matches the project's documented purpose of rendering tracker cards from built-in or user-imported preset templates compiled locally and cached. No remotely retrieved content is compiled or executed. Attacker-controlled LLM output enters only as template data, not as template source, and no exfiltration destination or obfuscation is present in the supplied evidence.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.download-to-execution
File role
production
Source
src/frontend.ts:121-1107

JavaScript analysis reported javascript.download-to-execution

Expected behavior · medium confidence

The scanner saw that the file both makes network requests and contains code-execution-like operations, and flagged the combination. Since this is one large bundled file for an extension that legitimately fetches data and renders templates, that combination is expected. The supplied code shows no case where something downloaded from the network is actually executed as code.

Technical evidence

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

Contextual assessment: This heuristic flags any representation containing both a network primitive and a dynamic execution sink anywhere in the file. The file is an 18,600-line bundle: the network capability appears to be the extension's fetch of the host application's own context/asset endpoints and standard fetch/XHR plumbing bundled from libraries, while 'execution sinks' are the bundler's __commonJS/__require module wiring, handlebars template compilation from user-imported presets, and DOM/HTML rendering used by the stated purpose. No evidence shows a path where network-retrieved content flows into eval, Function, or script injection: no retrieved string is passed to a code-evaluating sink in any supplied window. Correlation across an entire bundled file is candidate-locating evidence only, and no concrete download-to-execution data flow 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_families-1
Rule
javascript.download-to-execution
File role
generated
Source
dist/frontend.js:36-18619

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

The scanner flagged 51 'links,' but they are all the same standard YAML specification tag prefix embedded in the YAML parsing library. It is an identifier string, like a part number, not a web address the code visits.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.

Contextual assessment: All 51 occurrences visible in the supplied context are the literal string 'tag:yaml.org,2002:' used repeatedly by the bundled yaml library as the standard YAML 1.1/1.2 tag prefix and default directives table. This is a well-known URI fragment from the YAML specification, not a URL the code connects to. No evidence window shows these strings being fetched, requested, or used as network destinations. The scanner's link-detection heuristic misclassifies the spec namespace identifier as a shady link.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.shady-link
File role
generated
Source
dist/frontend.js:12483

Related contextual observations

Bundled handlebars security whitelist is the source of the prototype-pollution signal

low risk · high confidence

The flagged code is a built-in safety filter from the template library that turns off the dangerous special properties, the opposite of creating a problem.

Technical assessment

Line 567 sits inside handlebars' internal lookup-object creation, which explicitly disallows __proto__, __defineGetter__, __defineSetter__, __lookupGetter__, and __lookupSetter__ by mapping them to false on a null-prototype object. The scanner matched these defensive assignments as a prototype-pollution pattern. The function is a mitigation present in the standard handlebars distribution; the evidence shows no merge or assignment of attacker-controlled keys into a live prototype.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Additional contextual observation

low risk · high confidence

The extension's own pattern that cleans up model output is simple and fast; the other flagged patterns come from the YAML library and are also simple. None can be made to hang the app.

Technical assessment

The only project-authored regex in the flagged set, cleanupPlusSigns in src/trackerData.ts, removes plus signs preceding numbers in LLM-emitted tracker data. It is a single-pass replace with non-overlapping character classes and a bounded numeric group, so it cannot backtrack exponentially. The remaining flagged regexes belong to the bundled yaml schema definitions and handlebars lexer and are short, anchored, and applied to small tokens.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Handlebars template compilation of local and user-imported presets

low risk · high confidence

Detailed wording was omitted by the public report safety filter.

Technical assessment

The file compiles Handlebars template sources into executable template functions with a cache. Compilation of template markup is inherent to the project's stated purpose, and template sources come from bundled presets or presets the user deliberately imports. This is disclosed in the project documentation. The behavior only becomes a concern if untrusted template source could be compiled without user action; the supplied evidence does not show such a path.

Impact: low · Exploitability: unlikely

Developer action: Review the cited evidence and confirm the intended behavior.

Sources:

Coverage and limitations

JavaScript coverage

Unresolved JavaScript stages

Tools

Limitations

Technical scan identity