A scanner flagged some text-cleaning patterns as potentially slow. Reading the actual code, these patterns strip labeled blocks of text one line at a time and are very unlikely to cause the slowdowns the scanner worries about. Even in a bad case, the only effect would be a briefly slower response on the user's own machine, so this is a code-quality nit rather than a security problem.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: The repeated signal corresponds to several near-identical block-stripping regular expressions that match a labeled header line followed by a lazily repeated single-line group with a lookahead, used to remove engine-internal blocks from the assembled system message before prompting. Although static analyzers flag the nested repetition shape as a potential runaway-backtracking risk, the dot class here excludes line terminators, so each repetition consumes exactly one line and the lookahead's end-of-line alternative is satisfied at the next line break under multiline mode. Matching is therefore effectively linear over the prompt-sized text it processes, and no catastrophic backtracking path is demonstrated on realistic input. Even in a worst case, the outcome would be a transient slowdown of a single generation inside the user's own tab, which is a low-impact quality issue rather than a security exposure. The same function also builds a regular expression from strip patterns supplied by the active lore module, but lore modules are user-installed code that already runs arbitrary logic, so that path grants no additional capability.
Impact: low · Exploitability: unlikely
Developer action: Optional cleanup: replace the repeated lookahead-based block strippers with straightforward line-by-line parsing to remove the nested-repetition shape and the scanner signal. No security change is required.
The scanner noticed a network call near code that runs JavaScript and flagged the combination. In reality, the network call only saves debugging notes onto the user's own SillyTavern server, and nothing received over that call is ever run. The code-execution part is the extension doing its advertised job: running the gameplay script the user deliberately loaded. No information leaves the user's own server and no passwords or keys are touched.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution. The match applies to this repository.
Contextual assessment: Detailed technical wording was omitted by the public report safety filter.
Impact: none · Exploitability: unlikely
Developer action: Optional hardening only: expose a visible setting to disable or require confirmation for remote lore auto-updates, since refresh-by-default from a stored remote URL is a mild supply-chain surface even though it is disclosed. No security change is required for the flagged flow itself.