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 danger0 material4 low
What this review found
No material or immediate-danger item was identified.
Contextual expected matches (4)
Credential access and network transmission in one file
Expected behavior · high confidence
The flagged text is a technical document explaining that if a user chooses to connect the widget to their own AI service, the extension sends the user's own API key to that same service so the request can be authorized. That is how every app that talks to a custom AI endpoint works. The key goes only to the service the user picked, stays in their browser, and is never sent anywhere else. Nothing here suggests the key is being stolen or leaked
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The scanner flagged the co-occurrence of a credential reference and an outbound network call in a single file. The flagged location is documentation text describing the extension's optional custom-LLM backend: a direct browser request to a user-configured OpenAI-compatible endpoint, optionally carrying an Authorization Bearer header containing a key the user themselves supplied. This is the standard and necessary pattern for a user-chosen custom API backend — the key is only transmitted to the endpoint the user explicitly configured, which is the destination the key belongs to. The documentation further states the key is kept in browser localStorage rather than extension settings, avoiding server sync or chat-metadata persistence. There is no evidence of the key being transmitted to any fixed third-party destination, embedded telemetry, or hidden sink; the flagged credential-to-network pairing is the legitimate authentication path of the documented feature, not exfiltration. Note the evidence is documentation of intended behavior; actual implementation code was not part of this evidence group, so no code-level verification was possible, but nothing described constitutes an exposure
The scanner saw both 'downloads something from the internet' and 'runs some code' in the same file and flagged the combination. In reality, the internet parts are just decorative icon images and calls to an AI service the user set up themselves, and the code-running parts load SillyTavern's own built-in scripts. Nothing downloaded from the internet is ever run 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: The scanner flags a co-occurrence of network retrieval and a code-execution sink in the same file. The visible network references are static icon image URLs used for UI decoration and outbound LLM API calls to a user-configured endpoint, not retrieval of executable code. The dynamic execution sinks shown are import() calls against fixed relative host-local SillyTavern script paths (the host's main script and its regex engine) used to reuse documented host functionality, which is standard extension behavior. There is no evidence of remotely fetched content being evaluated or executed.
Credential access and network transmission in one file
Expected behavior · high confidence
This file is just documentation explaining how the analysis requests are sent. It describes the same legitimate behavior seen in the code: the user's API key is sent only to the AI service address the user chose. A documentation file cannot do anything by itself.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: This is a documentation file describing the extension's re-scan feature. It mentions a direct fetch() to a user-configured endpoint with an optional Authorization Bearer header, which is documentation of the same disclosed custom-backend behavior reviewed in the runtime code: the key goes only to the user's own configured endpoint. A Markdown documentation file does not execute, so no runtime exposure exists here, and the described behavior matches the project's stated purpose.
Credential access and network transmission in one file
Expected behavior · high confidence
The extension lets users plug in their own AI service by providing a web address and API key. The key is only ever sent to the exact service address the user typed in, which is how such a feature has to work. There is no sign of the key being copied or sent anywhere else.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The candidate is a same-file correlation between credential access and a network sink. The credential is an API key the user explicitly configures for a custom OpenAI-compatible backend, read from extension-local storage and sent only as an Authorization header to the endpoint URL the user themselves configured, for the exact documented purpose of running MBTI analysis calls. The key is never transmitted to any destination other than the user's chosen endpoint, and the base URL is not hardcoded or remotely influenced. This is the standard, disclosed behavior for a custom-API feature, not credential exfiltration.