A crafted input might briefly slow or freeze the local client, without showing broader security harm.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: The expression may permit a local CPU slowdown, but this evidence shows no credential, persistence, code-execution, or cross-user impact.
Impact: low · Exploitability: plausible
Developer action: Bound the input length or replace the expression when practical.
A code scanner flagged this file as possibly disguised, but the shown code is normal, readable markup-building code for the extension's lorebook interface. It hides nothing and communicates only with the extension's own data functions.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.
Contextual assessment: The scanner reports a static obfuscation signal with low confidence on the raw source of the desktop lorebook renderer. The supplied code is clearly readable ES module JavaScript: named panel-rendering functions, plain imports, standard DOM manipulation, escaping of user-controlled values (world names, campaign names, colors, entry titles, comments) before HTML interpolation, and use of a CSS-escaping helper for selectors. Data flow is local: reading world info through the project's API, rendering panels, and saving edits. No encoded strings, eval, packing, hidden destinations, or concealed execution exist; behavior matches the stated lorebook-management purpose.
A code scanner thought this file might be deliberately disguised, but the actual code shown is ordinary, readable interface code for displaying and editing lorebook entries. Nothing is hidden, encoded, or doing anything beyond what the extension says 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 scanner reports a static obfuscation signal with low confidence on the raw source of a mobile lorebook UI renderer. The supplied code is plain, readable ES module JavaScript with descriptive identifiers, normal imports, explicit template-literal HTML construction, and use of an HTML-escaping utility for user-controlled values such as world names and entry text. There is no minification, encoded strings, packed eval, concealed execution, or unusual data flow; all work is local UI rendering and lorebook data save/load through the project's own API modules, matching the stated lorebook-manager purpose.
Icon picker interpolates campaign identifier into HTML without escaping
low risk · medium confidence
One small helper builds interface markup using an internal identifier without the same safety escaping used elsewhere in the project. This is a code-quality inconsistency, not an observed problem, since the identifier is created by the extension itself.
Technical assessment
The icon picker builder inserts the campaign identifier directly into an HTML attribute via template literal without the escaping utility, while the same identifier is escaped in the mobile file's parallel function only for world names. Campaign identifiers appear to be internally generated rather than attacker-controlled, so this is a quality inconsistency rather than demonstrated injection exposure. If campaign identifiers ever became user-supplied free text, attribute injection into the extension's own modal UI would be possible.
Impact: low · Exploitability: unlikely
Developer action: Apply the same HTML-escaping utility to the campaign identifier in attribute interpolation for consistency and defense in depth.
Campaign identifier interpolated into HTML attributes without escaping in several places
low risk · medium confidence
Several places build interface markup using an internal folder identifier without the safety escaping the project applies to names and colors elsewhere. The identifier is generated by the extension itself, so this is a consistency issue rather than an observed flaw.
Technical assessment
Multiple template literals insert the campaign identifier into data attributes and title text without the HTML-escaping utility, while user-facing names, colors, and icons are escaped. Campaign identifiers appear internally generated, so no attacker-controlled input path is demonstrated; this is an escaping-consistency gap. Were identifiers ever sourced from imported or user-entered free text, attribute or title injection within the extension's own modal would become possible.
Impact: low · Exploitability: unlikely
Developer action: Route the campaign identifier through the existing HTML-escaping utility wherever it is interpolated into attributes or title text.