CVE-2024-11037: gpt_academic: path traversal exposes LLM API keys

UNKNOWN PoC AVAILABLE CISA: TRACK*
Published March 20, 2025
CISO Take

Any internal deployment of gpt_academic on Windows is at risk of full OpenAI API key exposure via a single unauthenticated HTTP request. Rotate all API keys on affected instances immediately and update to a commit beyond 679352d. If you cannot patch now, block external access to gpt_academic at the network perimeter.

What is the risk?

Effective severity is HIGH despite missing CVSS. The vulnerability is trivially exploitable (no authentication required, no special tooling), the payload is a crafted URL, and the impact is direct credential theft. Windows-specific path normalization quirks allow bypassing the blocked_paths allowlist. API key theft from config.py enables immediate financial harm (unauthorized LLM usage billed to the victim) and potential data exfiltration through the stolen API access.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
GPT Academic pip No patch

Do you use GPT Academic? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
1.0%
chance of exploitation in 30 days
Higher than 57% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
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 should I do?

6 steps
  1. IMMEDIATE

    Rotate all API keys stored in config.py (OpenAI, any other services).

  2. UPDATE

    Pin deployment to a commit after 679352d or apply the patch from the huntr advisory.

  3. NETWORK

    Restrict gpt_academic to internal networks only; block public internet exposure.

  4. DETECT

    Search web server access logs for requests containing absolute Windows paths (e.g., C:/) or '%5C' patterns targeting /config.py.

  5. HARDEN

    Move API keys out of config.py into environment variables or a secrets manager.

  6. AUDIT

    Check OpenAI API usage logs for anomalous spike in requests or calls from unfamiliar IP ranges indicating prior exploitation.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2 - AI System Access Control
NIST AI RMF
GOVERN 6.2 - Policies and procedures are in place to address AI risks MANAGE 2.2 - Mechanisms are in place to sustain treatment of AI risks
OWASP LLM Top 10
LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2024-11037?

Any internal deployment of gpt_academic on Windows is at risk of full OpenAI API key exposure via a single unauthenticated HTTP request. Rotate all API keys on affected instances immediately and update to a commit beyond 679352d. If you cannot patch now, block external access to gpt_academic at the network perimeter.

Is CVE-2024-11037 actively exploited?

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

How to fix CVE-2024-11037?

1. IMMEDIATE: Rotate all API keys stored in config.py (OpenAI, any other services). 2. UPDATE: Pin deployment to a commit after 679352d or apply the patch from the huntr advisory. 3. NETWORK: Restrict gpt_academic to internal networks only; block public internet exposure. 4. DETECT: Search web server access logs for requests containing absolute Windows paths (e.g., C:/) or '%5C' patterns targeting /config.py. 5. HARDEN: Move API keys out of config.py into environment variables or a secrets manager. 6. AUDIT: Check OpenAI API usage logs for anomalous spike in requests or calls from unfamiliar IP ranges indicating prior exploitation.

What systems are affected by CVE-2024-11037?

This vulnerability affects the following AI/ML architecture patterns: LLM API integrations, academic/research AI deployments, self-hosted AI assistants, API gateway proxies.

What is the CVSS score for CVE-2024-11037?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM API integrationsacademic/research AI deploymentsself-hosted AI assistantsAPI gateway proxies

MITRE ATLAS Techniques

AML.T0037 Data from Local System
AML.T0040 AI Model Inference API Access
AML.T0048.000 Financial Harm
AML.T0049 Exploit Public-Facing Application
AML.T0055 Unsecured Credentials

Compliance Controls Affected

ISO 42001: A.6.2
NIST AI RMF: GOVERN 6.2, MANAGE 2.2
OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

A path traversal vulnerability exists in binary-husky/gpt_academic at commit 679352d, which allows an attacker to bypass the blocked_paths protection and read the config.py file containing sensitive information such as the OpenAI API key. This vulnerability is exploitable on Windows operating systems by accessing a specific URL that includes the absolute path of the project.

Exploitation Scenario

Attacker discovers a Windows-hosted gpt_academic instance via Shodan or Google dorking. They craft a request to a route that serves files, using a Windows absolute path (e.g., C:\path\to\gpt_academic\config.py) URL-encoded to bypass the blocked_paths check. The server returns config.py in plaintext. Attacker extracts the OpenAI API key, sets it in their own environment, and begins high-volume LLM inference — either for direct use or resale on underground markets — while the victim receives the invoice. Total exploitation time: under 2 minutes.

Weaknesses (CWE)

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

  • [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
  • [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.

Timeline

Published
March 20, 2025
Last Modified
July 31, 2025
First Seen
March 20, 2025

Related Vulnerabilities