TavernKeeper Scan Report

Promansis/summary-sharder

Commit 17c3f9a 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 4 low

What this review found

No material or immediate-danger item was identified.

Expected scanner matches (2)

Credential access and network transmission in one file

Expected behavior · high confidence

The extension retrieves an API key for embeddings and sends it to the local SillyTavern server's own embedding endpoint. This is how the RAG feature is supposed to work—the local server needs the key to call the embedding service on the user's behalf. The key is not sent to any external or suspicious location.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The flagged code resolves an embedding API key via a dedicated secrets module and transmits it in a POST body to a relative endpoint on the local SillyTavern server. The destination is a same-origin plugin API path, not an external or attacker-controlled host. The key is conditionally included only when present and is passed to the local server which proxies the embedding request. This matches the project's stated RAG integration purpose with the Similharity plugin. Standard SillyTavern request headers are used. No obfuscation, hidden exfiltration, or off-host destination is present.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 3
Rule
credential-exfiltration
File role
production
Source
core/rag/debug-pipeline.js:1151

Credential access and network transmission in one file

Expected behavior · high confidence

The extension needs an API key to talk to a reranker service as part of its RAG feature. It reads the key from the user's settings and sends it only to the reranker service the user configured, which is exactly what it should do. There is no sign of the key being sent anywhere unexpected.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: This file is a reranker client for the extension's RAG pipeline. It resolves a reranker API key from a user-configured override or a local secrets resolver, then sends that key as a Bearer token to the user-configured reranker API URL in direct mode, or includes it in the request body when routing through a plugin proxy endpoint using SillyTavern's standard request headers. Both paths are consistent with the stated RAG reranker feature: the credential is used to authenticate with the reranker service the user selected, and there is no evidence of transmission to an undisclosed or unauthorized destination.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 3
Rule
credential-exfiltration
File role
production
Source
core/rag/reranker-client.js:177

Related contextual observations

Reranker API key sent to user-configured endpoint in direct mode

low risk · high confidence

When calling the reranker service directly, the extension attaches the API key as an auth header to the request, which is the normal way to authenticate with an API.

Technical assessment

In direct mode the resolved API key is attached as an Authorization Bearer header to a fetch call against the user-supplied reranker API URL. This is the standard authentication pattern for calling a reranker service and matches the project's stated RAG reranker capability.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Reranker API key forwarded to plugin proxy endpoint

low risk · medium confidence

When using a plugin to handle reranking, the extension passes the API key to that plugin so the plugin can call the reranker service. This matches the documented plugin integration.

Technical assessment

In plugin mode the API key is included in the request body sent to a plugin rerank URL using SillyTavern's getRequestHeaders. This routes the reranker call through a plugin proxy, which is consistent with the README's reference to the Similharity plugin integration. The key is forwarded to enable the proxy to authenticate with the reranker service on the user's behalf.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Coverage and limitations

Tools

Limitations

Technical scan identity