LibreChat Verification Deep-Dive — Notable Findings Re-Profiled

NuClide Research · 2026-06-06

Deeper verification on the six notable finding clusters surfaced in the LibreChat population survey. Restraint maintained throughout: no registration, no LLM invocation, no account creation. Methods used: /api/config, /api/endpoints, PTR lookup, TLS cert inspection, WHOIS, marketing-site cross-reference.

The key disclosure surface beyond /api/config is /api/endpoints, which returns the configured LLM provider list per host without authentication. The crucial field is userProvide:

• userProvide: true — each registered user must bring their own API key. Lower LLM10 risk: the operator’s account is not consumed by attackers.
• userProvide: false (or absent) — the operator has configured a server-side API key. All registered users invoke completions against that key. This is the canonical Denial-of-Wallet condition.

---

Finding 1 — UC Berkeley: Severity downgrade after verification

Host: 169.229.156.181:3080 PTR: fixed-169-229-156-181.ce.berkeley.edu → UC Berkeley Civil & Environmental Engineering Department Title: “LibreChat” (default — no operator customization) Server domain: http://localhost:3080 (default; reverse proxy not configured)

DCWF KSAT coverage

Auto-derived from DCWF AI work-role rule files (ksat-tag).

• 672 (AI Test & Evaluation Specialist): K7003, K7004, S7068, S7075, T5904, T5919
• 733 (AI Risk & Ethics Specialist): K7040, K7051, T5854, T5868, T5882, T5893
• overlap (Common AI KSATs (all 5 roles)): K108, K1157, K1158, K22, K6311, K6935, K7003

Configured providers (all USER_KEY mode):

openAI(USER_KEY), google(USER_KEY), bingAI(USER_KEY),
gptPlugins(USER_KEY), anthropic(USER_KEY)

Revised assessment: The host is on UCB CEE department infrastructure with registration open, but all configured LLM providers require user-supplied API keys. The LLM10 Denial-of-Wallet surface is not present on this host — an attacker who registers cannot consume any UCB-paid LLM budget.

The finding remains a registration-open finding on institutional infrastructure but downgrades from HIGH (LLM10 + institutional) to MEDIUM-institutional. The risk reduces to: registered users could potentially access other registered users’ chat content depending on workspace isolation, and the instance is consuming UCB compute + storage.

Disclosure target: security@berkeley.edu (still warranted; institutional finding stands)

Research-program insight: USER_KEY mode is the best-practice deployment configuration for LibreChat when public registration is intentional. It eliminates the LLM10 surface entirely. UCB’s deployment appears to be a research-lab or student project that defaulted to USER_KEY — likely the LibreChat install template behavior for non-customized deployments.

---

Finding 2 — Santepair.fr: Severity confirmed at HIGH-SENSITIVE

Host: 51.77.213.247:443 PTR: vps-cc60b3e5.vps.ovh.net (OVH France) Server domain: https://chat.santepair.fr (confirms operator) Title: “Santepair.fr - ChatBot IA Bien-être et santé psychique”

Marketing-site verification: santepair.fr returns title “Santé Pair - Pair-aidance et médiation en santé mentale et psychique”. The operator is Santé Pair, a French nonprofit providing peer-support mediation in mental and psychic health.

Configured providers (SERVER_KEY confirmed):

agents(SERVER_KEY), Mistral(SERVER_KEY)

Auth surface: Six social login providers enabled (Google, Facebook, OpenID, GitHub, Discord, SAML) + email login + open registration.

Revised assessment: CONFIRMED HIGH-SENSITIVE.

• LLM10 surface confirmed: anyone who registers can invoke Mistral against Santé Pair’s API key.
• GDPR Article 9 (special categories of personal data — health-related): mental health is the specific example given in Article 9(1).
• Operator is a healthcare nonprofit; the chat interface is the public-facing peer-support tool.
• Open registration on a mental-health AI = privileged-conversation exposure across user boundary if workspace isolation misconfigured.

Disclosure path: CNIL coordination + Santé Pair DPO contact via santepair.fr legal page.

---

Finding 3 — TruslerLegal / Lexpertcloud: White-label legal-AI SaaS

Host: 144.126.133.109:3080 PTR: vmi2783240.contaboserver.net (Contabo VPS, Germany) Server domain: https://chat.lexpertcloud.com Title: “TruslerLegal AI Assistant”

Operator identification:

• Trusler Legal is truslerlegal.com, which redirects to a marketing site titled “Better Divorce Austin — Settlement-First Family Law in Austin, Texas.” This is a family-law boutique in Austin, TX. The “TruslerLegal AI Assistant” is a divorce/family-law AI assistant tied to a specific Texas family-law firm. Privileged divorce-and-family-law conversations are an elevated sensitivity class for any client base.
• Lexpertcloud (lexpertcloud.com / chat.lexpertcloud.com) appears to be the underlying SaaS platform hosting the TruslerLegal tenant. The domain is Cloudflare-fronted with NameCheap registrar email-forwarding — pattern of a small operator. Wayback Machine shows lexpertcloud.com active since at least February 2025. Likely a small consultancy or solo operator reselling LibreChat as white-label legal AI to law-firm tenants. Only 2 subdomains in CT logs (lexpertcloud.com, code.lexpertcloud.com) — single product, not enterprise multi-tenant.

Configured providers:

openAI(SERVER_KEY), agents(SERVER_KEY), google(USER_KEY), anthropic(SERVER_KEY)

Three of four providers are SERVER_KEY. The TruslerLegal tenant has the operator’s OpenAI, agents, and Anthropic keys configured server-side.

Assessment: CONFIRMED HIGH-PRIVILEGED.

• LLM10 surface on three providers
• Multi-tenant white-label deployment: open registration means a new user could potentially access other tenants’ chat content depending on isolation
• Attorney-client privilege exposure risk
• Legal-AI tenant branding (Trusler Legal) on a shared infrastructure (Lexpertcloud) creates a brand-trust gap: clients expect privacy commensurate with a law firm, but the auth posture is consumer-grade

Disclosure path: Direct to Trusler Legal (LinkedIn/website contact) + Lexpertcloud platform operator. Trademark search recommended to surface other Lexpertcloud-hosted legal-AI tenants.

---

Finding 4 — LegalMatch AI: MVP on AWS ALB

Host: 18.207.2.243:80 PTR: ec2-18-207-2-243.compute-1.amazonaws.com (AWS us-east-1) Server domain: http://growth-rag-mvp-alb-1391618126.us-east-1.elb.amazonaws.com (AWS Application Load Balancer, RAG MVP environment) Title: “LegalMatch AI”

Operator identification: LegalMatch is a known US legal-services-directory company (legalmatch.com). The growth-rag-mvp-alb ALB name indicates a product growth team’s MVP environment — likely an internal pilot or beta product not yet at full production.

Cross-check via subdomain enumeration: Certificate transparency for *.legalmatch.com surfaces AI-relevant subdomains:

Pattern recognition: LegalMatch has proper Cloudflare-fronted auth on their production AI endpoints (lmassist, ai-api). The Shodan-discovered MVP environment (18.207.2.243:80, the unprotected AWS ALB growth-rag-mvp) is a separate environment that wasn’t put behind Cloudflare. The finding is therefore a hardening-gap between LegalMatch’s production discipline and their MVP / growth-team experimentation environment.

This is a constructive observation for the disclosure: LegalMatch knows how to deploy this securely — they did it for production. The growth-team MVP either skipped the standard hardening or hasn’t migrated to it yet.

Configured providers:

openAI(SERVER_KEY), agents(SERVER_KEY), LM Atlas(SERVER_KEY)

“LM Atlas” appears to be LegalMatch’s proprietary endpoint (LM = LegalMatch). All providers SERVER_KEY.

Assessment: CONFIRMED HIGH-PRIVILEGED.

• LLM10 surface on all configured providers
• MVP environment with open registration: testing artifact not hardened for public
• Custom internal endpoint “LM Atlas” exposed by name (configuration intelligence about LegalMatch’s AI architecture)

Disclosure path: LegalMatch corporate security contact (security@legalmatch.com per their published security page, or via responsibledisclosure@legalmatch.com).

---

Finding 5 — Atticus + Legal-KG-Chatbot: Smaller legal-AI deployments

Host A: 34.75.202.219:80 (Atticus: Legal Assistant)

• GCP us-east1 hosting
• Server domain: http://localhost:3080 (uncustomized)
• Providers: agents(SERVER_KEY), anthropic(USER_KEY)
• Apple login distinctively enabled (most LibreChat instances don’t have Apple)

Host B: 20.77.81.170:443 (Legal-Knowledge-Graph-Chatbot)

• Azure hosting (20.x = Azure)
• Server domain: localhost:3080 (uncustomized)
• /api/endpoints returned empty — newer LibreChat may auth-gate this endpoint, or no providers configured

Assessment:

• Atticus: MEDIUM. SERVER_KEY on the agents endpoint = limited LLM10 surface. The anthropic USER_KEY config means the typical chat path requires user-supplied keys.
• Legal-KG: MEDIUM-UNKNOWN. Empty /api/endpoints is unusual and warrants confirmation that the host is actually using LLM providers vs. being a graph-only system.

Disclosure path: Both require WHOIS / operator identification before direct outreach. Default LibreChat branding + localhost server_domain suggests small operations.

---

ADDENDUM (added post-initial verification) — Capitol.ai customer-tenant fleet expanded via CT logs + probed

After Nicholas Kloster’s explicit authorization to extend verification beyond the original Shodan-indexed survey set, certificate transparency log enumeration via certspotter.com revealed 64 distinct *.capitol.ai subdomains issued in publicly-logged certificates. Subsequent SNI-correct GET probes against the customer-tenant subdomains confirmed:

All 4 customer-tenant Langfuse instances: SIGNUP_OPEN confirmed

Capitol.ai runs a dedicated Langfuse observability instance per customer per region. Each is behind Cloudflare (invisible to direct Shodan IP probing — discoverable only via CT logs or subdomain enumeration). Every one ships with signUpDisabled: false, the Langfuse upstream default. A non-customer who registers can potentially see LLM trace data for that customer’s deployment, depending on Langfuse workspace isolation.

Additional LibreChat instances surfaced beyond the 20-host Shodan set

chatagent.capitol.ai and chatagent-development.capitol.ai both return appTitle: "Capitol AI Chat Agent" with registrationEnabled: true. These are the canonical production + development LibreChat deployments that the original Shodan survey could not surface directly (Cloudflare-fronted).

Confirmed customer mapping via subdomain + service composition

The CT log + probe data confirms the customer-tenant prefixes correspond to identifiable enterprise customers:

The eont customer-environment is the most internally-extensive: 7+ subdomains across services (chatagent, ClojureScript backend services, websocket server, monitoring, LLM, platform-API). This is a fully-deployed customer environment.

Severity finalization (post-addendum)

The Capitol.ai finding is multi-product, multi-tenant, multi-customer auth-permissive default at enterprise SaaS scale:

• LibreChat (chat UI): registrationEnabled: true across 20+ confirmed instances including customer-tenant deployments
• Langfuse (observability): signUpDisabled: false across 4 customer-tenant deployments

A user who registers on chatagent-ey-eu-west-1.capitol.ai or langfuse-ey-eu-west-1.capitol.ai could potentially:

• Invoke completions against Capitol.ai/EY SERVER_KEY for OpenAI, Anthropic, Cerebras (LLM10 Denial-of-Wallet)
• View LLM trace data showing the EY user activity, prompts, tool calls, retrieved documents (LLM02 Sensitive Information Disclosure + LLM07 System Prompt Leakage)

Operator pedigree (from Capitol.ai /about page)

Capitol.ai is a Washington-DC-area government-tech-adjacent startup:

• CEO — “launched over 60 products and holds 15 patents. Previously led foundational design at Airbnb and contributed to key projects at Google, NASA, the White House, and the Department of Defense.”
• CTO — “Previously directed the AI Center of Excellence at the U.S. General Services Administration (GSA)” (i.e., federal AI policy infrastructure leadership)
• Customer profile consistent with the founders’ background: HMG / Plexal (UK government-adjacent), Ernst & Young (audit firm with substantial government practice), Politico (political journalism), Dow Jones (financial media)

This is not a small startup with an inattentive default. The auth-permissive condition on customer-tenant Langfuse and LibreChat instances is a single configuration oversight at deployment-template level, propagated across the customer fleet.

Disclosure contacts (published by Capitol.ai)

The security@capitol.ai address is published in their own privacy policy — i.e. Capitol.ai has anticipated security-research outreach. This is the canonical responsible-disclosure channel.

Important disclosure-handling notes for Capitol.ai

1. NuClide’s customer mapping is hypothesis, not assertion. The subdomain prefix → customer-identity mapping is strongly evidenced but requires Capitol.ai’s confirmation. The disclosure pathway should let Capitol.ai self-verify and self-route.

2. No actual customer data was accessed. All probes returned only configuration metadata (registration flag, version string, app title). No user accounts were created. No LLM completions were invoked. No trace records were viewed.

3. Capitol.ai’s tooling choices are sound. They use AWS XKS (External Key Store) for high-compliance crypto, Cloudflare for edge protection, multi-region deployment. The auth-permissive default is a single configuration oversight, not a systemic security failure. A one-line config change per customer tenant closes the entire class.

4. The upstream context matters. Both LibreChat and Langfuse ship auth-permissive defaults (the explicit finding of Insight #76). Capitol.ai inherited those defaults across their customer-tenant template. This is a third data point for the cohort-default hypothesis: enterprise SaaS providers building on auth-permissive OSS inherit the default unless they actively override it.

---

Original Finding 6 (preserved for chronology) — Capitol AI Chat Agent: Enterprise multi-tenant SaaS (CRITICAL ESCALATION)

20-host AWS fleet across us-east-1, us-east-2, eu-west-1, eu-west-2, ap-southeast-1 regions.

Operator confirmation: capitol.ai resolves to www.capitol.ai (Framer-hosted marketing site). Self-description: “Capitol is the agentic AI platform that transforms structured data, live research, and internal knowledge into high-quality content, reports, and artifacts in moments – not months.”

Capitol.ai is a real US AI-platform startup (not a NuClide hallucination from the title alone).

Server-domain enumeration across the fleet reveals customer-tenant naming pattern:

Configured providers (SERVER_KEY confirmed on sampled instance):

openAI(SERVER_KEY), agents(SERVER_KEY), anthropic(SERVER_KEY), Cerebras(SERVER_KEY)

All four providers SERVER_KEY. Cerebras provides ultra-fast inference at premium pricing — the LLM10 surface here is economically substantial.

Assessment: CRITICAL.

This is the most significant LibreChat finding of the day. Capitol.ai has deployed customer-segregated LibreChat instances under named subdomains, but every customer-tenant instance has registrationEnabled: true. The implications:

1. Brand-trust gap: a customer engaging Capitol.ai (e.g. EY, HMG) expects an enterprise-grade AI deployment. The public-registration default contradicts that expectation. A non-customer can register on the customer-tenant instance.

2. Cross-tenant exposure potential: if registration is open AND the workspace isolation is misconfigured, a registered user on (say) chatagent-ey-eu-west-1.capitol.ai could potentially access content created by EY users — exactly the scenario that breaks enterprise SaaS trust.

3. LLM10 at customer-tenant scale: every customer-tenant instance burns Capitol.ai’s (or the customer’s) SERVER_KEY budget on every registered user’s queries.

4. Suspected enterprise customers: If ey- and hmg- prefixes truly map to Ernst & Young and the UK Government, this is a finding with substantial reputational and regulatory implications for Capitol.ai. Verification of the customer mapping by Capitol.ai itself is the responsible disclosure step — NuClide does not claim the EY/HMG identification, only flags the suspected pattern.

Disclosure path:

• Direct to Capitol.ai security contact: capitol.ai marketing site → security/contact page → coordinated disclosure with the customer-tenant mapping confirmation request
• Recommended Capitol.ai remediation: change customer-tenant template to registrationEnabled: false by default; require Capitol.ai admin allowlist for user provisioning on customer-tenant instances; document this as part of the standard customer-SaaS contract.

---

Summary of revised severities

---

Research-program contributions

LLM10 disclosure-method advancement

The /api/endpoints endpoint with userProvide field is a LibreChat-specific LLM10 severity discriminator. Updated herald probe class will distinguish SERVER_KEY from USER_KEY findings in future LibreChat sweeps.

This generalizes: the population-scale auth-permissive finding is necessary but not sufficient for LLM10 — the configuration-disclosure layer reveals whether the operator’s account is actually consumable. For three platforms surveyed today (Open WebUI, Dify, LibreChat), the per-instance LLM10 risk depends on configuration data exposed at the same layer as the registration flag.

Capitol AI as the canonical enterprise-customer-tenant finding

The Capitol AI fleet pattern (per-customer named subdomains all with open registration) is a new finding class for the survey program: enterprise SaaS providers using LibreChat as the underlying technology, with customer-tenant naming that creates an “I am a security-conscious enterprise vendor” impression while shipping consumer-grade auth defaults.

The class is testable against other LibreChat-based commercial SaaS — searching for chatagent.*.com patterns in DNS could reveal similar deployments.

Operator-attribution discipline

Six of six profiled hosts had attributable operator information via PTR, server_domain, and marketing-site cross-reference. Direct restraint-bounded operator-attribution is fully sufficient for disclosure-grade findings at LibreChat scale. No registration was required for any of these identifications.

This validates the NuClide methodology: high-confidence finding identification from the metadata layer alone, with the data layer left untouched per the restraint ethic.

---

Updated disclosure pipeline state