CVE-2023-3686: OpenAI Python unauthenticated SQLi

CISO Take

CVE-2023-3686 is a CVSS 9.8 unauthenticated SQL injection in QuickAI OpenAI 3.8.1, exploitable with a single crafted GET request against the blog search endpoint. The database almost certainly contains stored OpenAI API keys, user credentials, and application data — any internet-exposed instance should be treated as fully compromised. Take deployments offline immediately; no vendor patch exists and the vendor has not responded to disclosure.

What is the risk?

Exploitability is maximum: network-accessible, zero complexity, no authentication, no user interaction required. The threat is compounded in AI context because the database stores OpenAI API keys, which once exfiltrated enable unauthorized LLM usage billed to the victim. QuickAI is a commercial SaaS template sold to non-technical operators who are unlikely to monitor for exploitation or apply workarounds. Active exploitation probability is high given trivial attack complexity and public VulnDB disclosure.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenAI Python	pip	—	No patch
31.0K OpenSSF 6.9 16.6K dependents Pushed 6d ago 14% patched ~23d to patch Full package profile →

Do you use OpenAI Python? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 34% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Block public access to /blog endpoint immediately or take the application offline — no official patch is available from the vendor. 2) Deploy WAF rules filtering SQL injection patterns (UNION, SELECT, sleep(), etc.) in GET parameter 's'. 3) Rotate all OpenAI API keys stored in the application database; revoke old keys in the OpenAI console and audit usage logs for anomalous consumption. 4) Audit web server access logs for /blog?s= requests containing SQL keywords to detect prior exploitation. 5) Review all exposed user credentials for credential-stuffing risk against other services. 6) If patch becomes available, upgrade and verify parameterized queries are used throughout the codebase.

How is it classified?

Data Extraction Auth Bypass API AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.9 - Risk Management System

ISO 42001

A.6.2 - AI System Security

NIST AI RMF

MANAGE-2.2 - Risk Treatment and Residual Risk Management

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2023-3686?

CVE-2023-3686 is a CVSS 9.8 unauthenticated SQL injection in QuickAI OpenAI 3.8.1, exploitable with a single crafted GET request against the blog search endpoint. The database almost certainly contains stored OpenAI API keys, user credentials, and application data — any internet-exposed instance should be treated as fully compromised. Take deployments offline immediately; no vendor patch exists and the vendor has not responded to disclosure.

Is CVE-2023-3686 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2023-3686, increasing the risk of exploitation.

How to fix CVE-2023-3686?

1) Block public access to /blog endpoint immediately or take the application offline — no official patch is available from the vendor. 2) Deploy WAF rules filtering SQL injection patterns (UNION, SELECT, sleep(), etc.) in GET parameter 's'. 3) Rotate all OpenAI API keys stored in the application database; revoke old keys in the OpenAI console and audit usage logs for anomalous consumption. 4) Audit web server access logs for /blog?s= requests containing SQL keywords to detect prior exploitation. 5) Review all exposed user credentials for credential-stuffing risk against other services. 6) If patch becomes available, upgrade and verify parameterized queries are used throughout the codebase.

What systems are affected by CVE-2023-3686?

This vulnerability affects the following AI/ML architecture patterns: LLM API integrations, AI-powered web applications, Content generation platforms.

What is the CVSS score for CVE-2023-3686?

CVE-2023-3686 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.43%.

What is the AI security impact?

Affected AI Architectures

LLM API integrationsAI-powered web applicationsContent generation platforms

MITRE ATLAS Techniques

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art.9

ISO 42001: A.6.2

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

A vulnerability was found in Bylancer QuickAI OpenAI 3.8.1. It has been declared as critical. This vulnerability affects unknown code of the file /blog of the component GET Parameter Handler. The manipulation of the argument s leads to sql injection. The attack can be initiated remotely. The identifier of this vulnerability is VDB-234232. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Exploitation Scenario

An attacker scans the internet for QuickAI deployments (identifiable via HTTP response headers or UI fingerprinting) and sends a single GET request: GET /blog?s=1'+UNION+SELECT+username,password,api_key,NULL+FROM+users-- with no authentication. Within seconds, the response leaks all user credentials and OpenAI API keys stored in the database. The attacker immediately uses the harvested OpenAI API key to spin up high-volume LLM requests for their own operations at the victim's expense, then pivots to exfiltrate all user PII for sale or further attacks. Total time to full compromise: under five minutes using sqlmap or manual injection.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.