Please do not open a public GitHub issue for a security vulnerability. Public disclosure before a fix is available puts all OmniPanel users at risk.
Report security issues privately through GitHub's private vulnerability reporting. You'll receive a response within 72 hours acknowledging the report.
Include in your report:
- A description of the vulnerability and its potential impact
- Steps to reproduce (a proof-of-concept is helpful but not required)
- Affected component (
app/auth.py,app/utils/nl_to_sql.py, etc.) - Any suggested fix, if you have one
In scope:
- Authentication and authorization bypass (
app/auth.py) - The SQL console safety model — allow-list, read-only transaction, auto-LIMIT, timeout (
POST /analysis/sql) - NL-to-SQL prompt injection that produces SQL bypassing the safety guardrails
- Privilege escalation between roles (viewer / analyst / admin)
- Sensitive data exposure via API endpoints
- Token forgery or JWT weaknesses
Out of scope:
- Vulnerabilities in third-party dependencies — report those upstream (FastAPI, SQLAlchemy, Streamlit, etc.)
- Issues that require physical access to the host server or database
- Denial-of-service attacks against a self-hosted instance you control
- Social engineering
All queries — whether typed by a user or generated by NL-to-SQL — run through the same pipeline:
- SELECT/WITH allow-list check (anything else is rejected)
- Automatic
LIMITinjection if absent - Read-only transaction (
SET LOCAL transaction_read_only = on) - Statement timeout
If you believe a crafted query or NL-to-SQL prompt can bypass any of these controls and produce a write, expose server state, or exfiltrate data beyond what the querying user's role permits, that is a valid security issue and worth reporting privately.
OmniPanel does not yet publish versioned releases. Report vulnerabilities against the current main branch.
Once a fix is available we will:
- Push the fix to
main - Publish a GitHub Security Advisory crediting the reporter (unless they prefer to remain anonymous)