No material or high-risk item was identified.
Expected scanner matches (16)
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
The bridge sends your Remix.Camera login token only to the Remix.Camera server when fetching a generated image, which is exactly what the tool is supposed to do. It does not send the token to other websites.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The fetch on line 1894 sends an Authorization header only when includeAuth is true and item.sourceUrl starts with config.apiBaseUrl. This restricts the session token or API key to the project's own configured API endpoint, matching the stated purpose of a local bridge that stores credentials server-side and calls the Remix.Camera API. A fallback retry without auth is performed on 401/403. No evidence shows the credential being sent to arbitrary or unintended destinations.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- bridge/server.mjs:1894
Credential access and network transmission in one file
Expected behavior · high confidence
This code uses a Telegram bot token to talk to Telegram's official API, which is exactly how all Telegram bots work. The token is only sent to Telegram's own servers, not to any third party. This is normal and expected for a Telegram bot adapter.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The file is a Telegram bot adapter. The botToken variable is used in a fetch call to api.telegram.org, which is Telegram's official Bot API endpoint. Embedding the bot token in the URL path is the documented authentication method for the Telegram Bot API. The token is sent only to the official Telegram API domain and is used for legitimate bot operations such as setMyCommands and getUpdates. This is the standard, expected pattern for any Telegram bot integration.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 3
- Rule
- credential-exfiltration
- File role
- production
- Source
- adapters/telegram/lily-bot.mjs:124
OpenGrep reported tavernkeeper.credential-exfiltration.python-secret-to-network
Expected behavior · high confidence
This Poe bot adapter reads non-secret settings like a profile ID and character name from the environment, then sends the user's chat command to a local bridge service. No passwords, API keys, or session tokens are read or sent by this file. The actual Remix.Camera session token lives in the separate bridge component, not here. This is normal behavior for an adapter whose job is to relay commands.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.python-secret-to-network in this repository.
Contextual assessment: The scanner matched because environment variables are read and a network request follows. Examining the actual data flow, the environment variables consumed are REMIX_BRIDGE_URL (defaulting to a localhost address), REMIX_PROFILE_ID, REMIX_CHARACTER_NAME, and REMIX_CHARACTER_VISUAL_IDENTITY. None of these are credentials or secrets. The session token described in the project purpose is stored and used by the separate local bridge, not by this Poe adapter. The POST body contains character configuration and user prompt text, sent to the local bridge endpoint, which matches the stated project purpose of forwarding image-generation commands to the bridge.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.python-secret-to-network
- File role
- production
- Source
- adapters/poe/remix_camera_poe_bot.py:79
Gitleaks reported curl-auth-header
Expected behavior · high confidence
This is a how-to guide showing users how to test their own local setup. The secret in the example is a placeholder that was already removed, so no real password or key is exposed.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule curl-auth-header in this repository.
Contextual assessment: The flagged line is a curl example in a demo runbook showing how to test an authenticated dry-run endpoint against a local bridge. The Authorization header value is already redacted to a placeholder. The surrounding documentation instructs the user to set their own random value for the action API key. No real credential is present in the file; this is instructional documentation for local testing.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- curl-auth-header
- File role
- documentation
- Source
- demos/chatgpt-actions/demo.md:41-43
Credential access and network transmission in one file
Expected behavior · high confidence
This file creates a code snippet for Flowise that sends chat context to a local helper program on the same machine. It does not touch any passwords, API keys, or login tokens. Sending data to the local bridge is exactly what this project is designed to do.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged line is inside a string template exported as flowiseCustomToolSnippet, which is a Flowise custom-tool code snippet. It performs a POST to a bridge URL that defaults to the local loopback address and is configurable via a Flowise variable. The request body contains character name, chat text, mood, location, and a consent flag—no credentials, tokens, or secrets are read, constructed, or transmitted. The scanner's credential-exfiltration heuristic appears triggered by the co-occurrence of a configuration variable and a fetch call, but no credential source exists in this file. The network call to the local bridge matches the project's stated architecture of keeping the Remix.Camera session token server-side in the bridge and having adapters call that bridge.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 3
- Rule
- credential-exfiltration
- File role
- production
- Source
- adapters/flowise/remix-camera-flowise-tool.js:51
Credential access and network transmission in one file
Expected behavior · high confidence
This is a testing script that checks whether a local helper program is running correctly. It contacts a local address to verify health and available features. No passwords or secret tokens are sent in the flagged code; the scanner flagged it because credential-related code exists elsewhere in the same file, but the two are not connected here.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged region is the requestBridge helper in a tooling script (verify-adapter-demos.mjs). It performs fetch calls to a local bridge URL (127.0.0.1:8787 per surrounding context) for health checks, OpenAPI schema verification, and ChatGPT Actions endpoint verification. The visible call sites pass only pathname strings and standard JSON headers; no credential or secret value is read, constructed, or forwarded into the request headers or body. The scanner matched on co-occurrence of credential-related code and network code in the same file, but the actual data flow at this location shows benign local bridge contract checks with no credential transmission.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 3
- Rule
- credential-exfiltration
- File role
- tooling
- Source
- scripts/verify-adapter-demos.mjs:677
Gitleaks reported curl-auth-header
Expected behavior · high confidence
This is a how-to guide showing an example command for testing a protected endpoint. The secret value was already removed and replaced with a placeholder, and the guide tells users to use their own randomly chosen key. No real password or key is exposed.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule curl-auth-header in this repository.
Contextual assessment: The flagged line is an example curl command in a documentation runbook demonstrating how to test an authenticated bridge endpoint. The bearer token value has already been redacted to a placeholder. The surrounding documentation instructs the user to supply their own randomly generated value for the action API key. No real credential is present in the file.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- curl-auth-header
- File role
- documentation
- Source
- demos/chatgpt-actions/demo.md:41-43
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
When a Discord command fails, the bot uses the temporary token Discord gave it for that specific command to send an error message back to Discord. This is exactly how Discord bots are supposed to work and does not involve any secret being stolen or sent anywhere unexpected.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The flagged data flow passes a Discord interaction token (interaction.token) to tool.send to deliver a followup error message back to Discord. This is the standard, intended use of Discord interaction tokens: they are ephemeral, per-interaction values provided by Discord specifically so bots can post followup responses. The token is not a user credential, API key, or session secret, and it is sent only to Discord's own interaction endpoint via the tool. No exfiltration to an unrelated destination is present.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- adapters/discord/lily-interactions-server.mjs:57-64
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
This script registers Discord slash commands by sending the bot token to Discord's own official API. That is exactly how Discord bot tokens are meant to be used. The token is not sent anywhere unexpected.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The file reads DISCORD_BOT_TOKEN from an environment variable and includes it as a Bearer-style Authorization header in a PUT request to the official Discord API endpoint. This is the documented, standard method for registering application slash commands with Discord. The credential is sent only to Discord's first-party API domain and is used for its intended authentication purpose. There is no exfiltration to a third-party destination, no obfuscation, and no persistence of the token beyond the single request.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- adapters/discord/register-commands.mjs:18-25
Credential access and network transmission in one file
Expected behavior · high confidence
The bot token and the network request appear together because registering Discord commands requires authenticating with Discord. The token goes only to Discord's official API, which is the expected and correct behavior.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The scanner flagged co-occurrence of credential access and a network call in the same file. Here the credential is a Discord bot token read from the environment, and the network call is a PUT to the official Discord API to register slash commands. The token is used solely as an Authorization header for its intended Discord API authentication purpose. The destination is Discord's first-party API, not an external or attacker-controlled sink. This is normal, disclosed adapter behavior for a Discord integration.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 3
- Rule
- credential-exfiltration
- File role
- production
- Source
- adapters/discord/register-commands.mjs:18
Credential access and network transmission in one file
Expected behavior · high confidence
This code sends a chat message and character details to a local helper program to request an AI-generated image. It does not access, read, or send any passwords, API keys, or secret tokens. The actual account token is kept by the local bridge program, not by this adapter. This matches what the project says it does.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged line 58 is inside a string-raw code snippet exported for Botpress to execute. It performs an HTTP POST to a bridge URL that defaults to the local loopback address. The request body contains character name, chat text, mood, location, and a consent flag — all prompt-context fields consistent with the project's stated purpose of requesting generated companion images through a local bridge. No credential, token, or secret is read, constructed, or transmitted in this file. The README confirms the bridge holds the opaque session token server-side, so the adapter intentionally never touches credentials. The scanner's heuristic of credential-source-plus-network-sink in one file does not hold here because no credential source exists in this code.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- tavernkeeper 3
- Rule
- credential-exfiltration
- File role
- production
- Source
- adapters/botpress/remix-camera-botpress-action.js:58
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is test code that loads one of the project's own plugin files in a sandbox to verify it works. It does not run anything from outside the project and does not touch the real network, so it is not a security concern.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The flagged vm.runInNewContext call is inside a Node test file. It reads a local adapter source file from the same repository and executes it in a fresh VM context with a mock fetch implementation and an empty globalThis. This is a standard test-harness pattern for loading a browser-oriented plugin module under Node without a real DOM or network. No untrusted input is passed to the VM; the executed source is a committed repository file, and the context is isolated with mocked globals.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- test
- Source
- tests/host-plugin-adapters.node-test.mjs:29
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
This code sends your Remix.Camera login token to the Remix.Camera website so the bridge can prove who you are when requesting image generations. That is the normal, intended job of this bridge tool. The token goes only to the expected Remix.Camera service, not to anywhere unexpected.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The flagged code reads a session token or API key from local configuration and includes it as a Bearer Authorization header in outbound requests to the configured Remix.Camera API base URL. This is standard API-client authentication behavior. The destination is the project's own backend API endpoint, not an unexpected third party. The project's stated purpose explicitly describes a local bridge that stores a session token server-side and calls the Remix.Camera API, which matches this data flow exactly. No evidence of redirection to alternate destinations, logging of the token, or exfiltration to unrelated services is present in the supplied context.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- bridge/server.mjs:1335-1338
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
The scanner saw a network call in a file that also mentions credentials elsewhere. Looking at the actual code, the network call only checks whether a local service is healthy and exposes the expected features. No secret values are sent through this code path.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The OpenGrep rule matched the requestBridge function's fetch call (lines 677-684) as a network sink potentially reachable from a credential source in the same file. Examining the actual data flow, requestBridge issues GET-style requests to a local bridge URL for /health, /openapi.json, and /chatgpt-actions/openapi.json. The options spread allows callers to pass custom headers, but none of the visible call sites inject credentials, tokens, or secrets. The function is part of a demo-verification tool whose stated purpose is validating adapter and bridge contracts. No credential-to-network path is demonstrated in the supplied source context.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- tooling
- Source
- scripts/verify-adapter-demos.mjs:677-684
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
This code sends an error message back to Slack when an image generation request fails. The web address it sends to is a normal reply link that Slack provides for responding to slash commands, not a secret. The incoming request is checked against a Slack signature first, so only genuine Slack requests reach this code. This is standard behavior for a Slack bot.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The flagged code is an error-handling path inside a Slack slash-command server. When the tool's command handler throws, the catch block sends a user-facing error message to the Slack response_url that was provided in the incoming slash-command payload. The response_url is a standard, temporary webhook URL that Slack itself supplies for asynchronous responses; it is not a credential or secret. The entire HTTP handler verifies the Slack request signature using a signing secret before the payload is parsed or acted upon, so the response_url is only trusted after cryptographic validation. The tool.send call uses the response_url and channel_id as routing parameters for delivering an error notification back to the originating Slack channel, which matches the stated purpose of a Slack adapter. No credentials are forwarded to the response_url; the bot token is encapsulated inside the tool object and is not passed as data to the network sink.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- adapters/slack/lily-slash-command-server.mjs:60-71
OpenGrep reported tavernkeeper.credential-exfiltration.javascript-secret-to-network
Expected behavior · high confidence
The scanner flagged this because a secret and a network call are in the same code. But the secret is a Telegram bot token and the network call goes to Telegram's official API. This is the correct and only way to authenticate a Telegram bot. There is no exfiltration.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.credential-exfiltration.javascript-secret-to-network in this repository.
Contextual assessment: The scanner matched because a credential source (botToken) and a network sink (fetch) appear together. However, the fetch target is api.telegram.org, Telegram's official Bot API. The token is used as the authentication credential for calling Telegram Bot API methods, which is the only supported authentication mechanism for that API. No other destination receives the token. The project explicitly includes a Telegram adapter, making this data flow consistent with stated purpose.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.credential-exfiltration.javascript-secret-to-network
- File role
- production
- Source
- adapters/telegram/lily-bot.mjs:124-130