Listen to this Post
How the mentioned CVE works:
CVE-2026-40315 was initially patched by adding input validation (regex ^[a-zA-Z0-9_]$) to `table_prefix` in `sqlite.py` only. However, nine other backend files – mysql.py, postgres.py, async_sqlite.py, async_mysql.py, async_postgres.py, turso.py, singlestore.py, supabase.py, `surrealdb.py` – still pass the unsanitized `table_prefix` directly into f-string SQL queries. This creates 52 unvalidated injection points. The vulnerable pattern appears in DDL statements like CREATE TABLE IF NOT EXISTS {table_prefix}sessions. An attacker controlling `table_prefix` (e.g., from a multi-tenant tenant name, API parameter, or user-editable config) can break out of the identifier context and execute arbitrary SQL. Additionally, `postgres.py` accepts an unvalidated `schema` parameter used directly in CREATE SCHEMA IF NOT EXISTS {schema}, adding a second injection vector. The default `table_prefix=”praison_”` is not exploitable, but any external input triggers the flaw. The PoC demonstrates that while SQLite rejects a payload like x'; DROP TABLE users; --, MySQL and PostgreSQL happily embed it, generating SQL like CREATE TABLE IF NOT EXISTS x'; DROP TABLE users; --sessions .... The injected SQL runs with the database user’s privileges, enabling read, write, or delete on all tables. CVSS 8.1 (High) due to low attack complexity, required low privileges, and high impact on confidentiality and integrity.
dailycve form:
Platform: PraisonAI Agents
Version: Unpatched backends
Vulnerability: SQL Injection
Severity: High (8.1)
date: 2026-04-17
Prediction: 2026-05-15
What Undercode Say:
Find all vulnerable f-string table_prefix injections
grep -rn 'f".{.table_prefix.}' praisonai-agents/praisonaiagents/storage/backends/
Count injection points per backend
for f in mysql.py postgres.py async_.py turso.py singlestore.py supabase.py surrealdb.py; do
echo "$f: $(grep -c 'f".{' praisonai-agents/persistence/conversation/$f)"
done
Simulate unsafe query building (do not run on production)
python3 -c "
table_prefix = \"x'; DROP TABLE users; --\"
sessions_table = f'{table_prefix}sessions'
print(f'CREATE TABLE IF NOT EXISTS {sessions_table} (id INT)')
"
How Exploit:
- Identify an endpoint where `table_prefix` is derived from user input (e.g.,
POST /api/tenant/{tenant_name}/config). - Set `tenant_name` to a payload: `test’; DROP TABLE critical_data; –`
3. Trigger any database operation that uses the affected backend (e.g., creating a conversation session). - The backend executes
CREATE TABLE IF NOT EXISTS test'; DROP TABLE critical_data; --sessions ..., droppingcritical_data. - For PostgreSQL, also inject via `schema` parameter: `public; DROP SCHEMA payroll CASCADE; –`
Protection from this CVE:
- Apply input validation identical to sqlite.py: `if not re.match(r’^[a-zA-Z0-9_]$’, table_prefix): raise ValueError`
– Use parameterized identifiers (if supported) or an allowlist of allowed prefixes. - Treat `schema` parameter with same strict regex before using in
CREATE SCHEMA. - For multi-tenant setups, map external tenant names to a fixed internal prefix (e.g., a hash) instead of using raw input.
- Upgrade to a patched version once released (expected May 2026).
Impact:
Successful exploitation grants attacker full SQL execution on the backing database. They can read all tables (exfiltrate user credentials, messages), modify or delete any data, and potentially escalate to RCE via database-specific features (e.g., `COPY … PROGRAM` in PostgreSQL). The impact is total compromise of database confidentiality and integrity. In multi-tenant SaaS deployments, one tenant can attack another tenant’s data or the entire shared database.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
