Chroma DB
Chromadatabase7 credentials
Unauthenticated Local / Self-hosted Chroma Server
chroma-db / unauthenticated-local-server
Chroma can be run in client-server mode for local or self-hosted vector database access. Authentication is optional and controlled by configured auth providers, so many development deployments expose the API without a credential.
Unauthenticated access
open defaultno authentication required- username
- none
- password
- none
Location
/api/v1, /api/v2, /api/v2/heartbeat, /api/v2/version, /api/v2/tenants, /api/v2/tenants/{tenant}/databases/{database}/collectionsChroma HTTP API contexts for self-hosted client-server deployments
CHROMA_SERVER_HOST, CHROMA_SERVER_HTTP_PORT, CHROMA_SERVER_SSL_ENABLED, CHROMA_SERVER_AUTHN_PROVIDER, CHROMA_SERVER_AUTHZ_PROVIDERdocker-compose.yml, compose.yml, values.yaml, deployment.yaml, service.yaml, ingress.yaml, .env, .env.production, config.yaml, config.ymlContainer, Kubernetes, Helm, and local deployment files that may expose an unauthenticated Chroma service
Chroma server logs, access logs, reverse-proxy logs, Kubernetes logs, and gateway traces
Notes
This represents absence of authentication, not a secret value. It is useful for scanners because reachable unauthenticated vector databases can expose embeddings, documents, metadata, tenant/database names, or application data. Host, port, SSL, authn provider, and authz provider variables are included because they determine exposure/auth posture rather than because they are secret values.
Chroma Cloud API Key
chroma-db / chroma-cloud-api-key
Chroma Cloud clients use an API key with tenant and database identifiers. The official client docs show api_key arguments, CHROMA_API_KEY, and x-chroma-token headers for Cloud database access.
Location
x-chroma-token, AuthorizationChroma Cloud and token-auth client headers
CHROMA_API_KEY.env, .env.local, .env.production, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, config.yaml, config.yml, pyproject.toml, notebook.ipynbProject-local, container, Kubernetes, notebook, and application configuration files
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, hosted app config vars, and password vaults
Python/TypeScript clients, notebooks, examples, tests, MCP servers, LangChain/LlamaIndex integrations, and committed application code
API debug logs, notebook output, CI traces, proxy logs, application errors, and support bundles
Notes
Chroma Cloud key values are opaque; detect by env/header/client-argument context rather than assuming a stable token prefix. CHROMA_TENANT, CHROMA_DATABASE, and CHROMA_HOST are useful Chroma context but are not credential values, so the scanner-facing environment location keeps CHROMA_API_KEY only.
Self-hosted Token Auth Credential
chroma-db / self-hosted-token-auth
Chroma supports token authentication using server and client auth providers. The token may be configured directly through credentials settings or read from a credentials file. The token transport header is Authorization by default, and can also be X-Chroma-Token.
Location
Authorization, X-Chroma-TokenToken-auth headers; Authorization expects a bearer token
CHROMA_CLIENT_AUTH_CREDENTIALS, CHROMA_SERVER_AUTHN_CREDENTIALS, CHROMA_SERVER_AUTHN_CREDENTIALS_FILE.env, .env.local, .env.production, chroma-auth.json, auth.json, credentials.json, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, config.yaml, config.ymlChroma token auth credentials, credentials files, and deployment configuration
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, Chroma server secrets, and password vaults
Chroma client code, server startup scripts, notebooks, examples, tests, and committed deployment manifests
auth failures, API debug traces, server startup logs, proxy logs, CI output, and support bundles
Notes
Upstream token validation permits ASCII letters, digits, and punctuation; token value shape is deployment-defined. Scanner logic should prioritize env/header/config-file context.
Self-hosted Basic Auth Credential
chroma-db / self-hosted-basic-auth
Chroma also supports Basic authentication. Client credentials are configured with chroma_client_auth_credentials, while server Basic auth reads htpasswd-style credential lines from chroma_server_authn_credentials_file.
Looks like
pattern^.+:\$2[aby]\$.{56,}$^.+:\$apr1\$.+Location
AuthorizationBasic auth header used by Chroma clients
CHROMA_CLIENT_AUTH_CREDENTIALS, CHROMA_SERVER_AUTHN_CREDENTIALS_FILE.env, .env.local, .env.production, .htpasswd, htpasswd, chroma.htpasswd, auth.htpasswd, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, config.yaml, config.ymlChroma Basic auth credentials and deployment configuration files
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, and password vaults
Chroma client code, notebooks, examples, tests, container entrypoints, and committed deployment manifests
Basic auth failures, proxy logs, application traces, CI output, and support bundles
Notes
Do not model a default username/password; Basic auth values are deployment-created.
Embedding Provider API Key
chroma-db / embedding-provider-api-key
Chroma applications frequently call embedding providers while writing or querying vector collections. These keys are not Chroma-native credentials, but Chroma client/server deployments often store them beside Chroma settings.
Location
OPENAI_API_KEY, COHERE_API_KEY, VOYAGE_API_KEY, JINA_API_KEY, MISTRAL_API_KEY, GOOGLE_API_KEY, GEMINI_API_KEY, HUGGINGFACEHUB_API_TOKEN, HF_TOKEN, CLOUDFLARE_API_TOKEN.env, .env.local, .env.production, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, config.yaml, config.yml, notebook.ipynbChroma embedding-function configuration, notebooks, and deployment manifests
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, hosted app config vars, and password vaults
embedding function code, LangChain/LlamaIndex apps, notebooks, tests, examples, and committed application code
embedding API errors, request traces, notebook output, CI logs, and support bundles
Notes
Keep provider-specific token shapes in provider templates where available; this Chroma block captures the common product-local storage context.
Persistent Data / Vector Collection Leakage
chroma-db / persistent-data-and-vector-leakage
Chroma persistent clients and servers store vector collections, embeddings, documents, metadata, tenant/database information, and system state on disk. These artifacts may include copied secrets, PII, proprietary content, or retrieval context even when they are not credentials themselves.
Location
.chroma, chroma, chroma.sqlite3, /chroma/chroma, /data/chroma, /var/lib/chroma, /var/lib/chromadb, /opt/chroma, /mnt/chroma, /app/chromaCommon local and container persistence directories/files for Chroma database files and volumes
%APPDATA%\\Chroma, %LOCALAPPDATA%\\Chroma, %USERPROFILE%\\.chromaWindows development-host Chroma persistence paths
PERSIST_DIRECTORY, CHROMA_SERVER_HOST, CHROMA_SERVER_HTTP_PORT, CHROMA_TENANT, CHROMA_DATABASEcollections, embeddings, documents, metadata, tenant/database records, and system tables in Chroma persistence storage
database backups, container images, persistent-volume snapshots, support bundles, notebook exports, and model/RAG demo archives
query traces, retrieved document logs, embedding logs, application debug logs, and backup/restore output
Notes
Treat this as context-dependent sensitive data. Scanner hits should help identify exposed Chroma stores and artifacts that may contain embedded secrets or high-value application data.
Scope
Authorized use
LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.