The scanner flagged a regex as potentially unsafe, but the actual patterns are simple text-matching expressions with no risk of runaway processing.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: JS-X-Ray flagged an unsafe-regex signal at line 368. The supplied source shows the regexes in parseHourFromTime and weatherKind: patterns like /(storm|thunder|lightning)/, /(snow|blizzard|sleet)/, and /(d{1,2})(?::(d{2}))?s*(am|pm)/i. These are simple literal-or and bounded-digit patterns with no nested quantifiers or complex backreferences that could cause catastrophic backtracking (ReDoS). The input is a short weather/time string from local verse state, not attacker-controlled data. No unsafe regex behavior is demonstrated.
The extension fetches data from an LLM API the user configures and parses the text response. This is exactly what the extension is supposed to do, and no dynamic code execution occurs.
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 (fetch in callExternalAPI) with a code execution sink across lines 309-2061. The fetch sends a POST request to settings.apiEndpoint, which is a user-configured OpenAI-compatible endpoint (OpenRouter, Moonshot, GLM, or custom). The response is parsed via r.json() and extractJSON, which uses JSON.parse on response text. No eval, Function constructor, or dynamic code execution sink is visible in the supplied source. The JSON.parse and insertAdjacentHTML calls operate on locally constructed or sanitized content. This is expected behavior for an extension whose stated purpose is calling an external LLM for world-keeping.
The scanner flagged a possible prototype pollution risk, but the code explicitly blocks dangerous property names before assignment, preventing the issue.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.prototype-pollution. The match applies to this repository.
Contextual assessment: JS-X-Ray flagged a prototype-pollution signal at line 1768. The supplied source shows importLibrary assigns imported verse data via settings.verseLibrary[v.id] = normalizeVerse(v). Critically, the code includes an explicit guard before this assignment: if (['__proto__', 'constructor', 'prototype'].includes(String(v.id))) continue. This blocks the three dangerous prototype-chain property names. The remaining v.id values are used as plain object keys on a verseLibrary object, which does not propagate to Object.prototype. No demonstrated prototype pollution path exists.
The scanner flagged the file as potentially obfuscated, but the actual code is plain, well-structured JavaScript with clear variable names, comments, and readable logic. There is no obfuscation present.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.
Contextual assessment: JS-X-Ray flagged an obfuscated-code signal at line 1 with low confidence. The supplied source is fully readable, well-commented JavaScript using standard ES module imports, clear constant definitions, descriptive function names, and extensive inline documentation. No minification, encoding, string concatenation tricks, or packed/eval-based obfuscation is present in the provided source context. The signal is a static-analysis false positive on readable production code.
Readable, well-documented source contradicts obfuscation signal
low risk · high confidence
The code uses standard, readable JavaScript throughout with clear naming and comments.
Technical assessment
The source context from lines 40-50 and surrounding code shows plain JavaScript with descriptive constant names, structured default objects, and comment section headers. This is consistent with readable hobbyist extension code, not obfuscated or concealed logic.
Explicit prototype-pollution guard in importLibrary
low risk · high confidence
Detailed wording was omitted by the public report safety filter.
Technical assessment
The importLibrary function iterates over incoming verse objects and explicitly skips any verse whose id matches __proto__, constructor, or prototype before assigning it as a key on settings.verseLibrary. This is a correct mitigation against prototype pollution via crafted backup file keys.