Top-Level Summary

• Vulnerability: CVE-2026-0764
• Product: GPT Academic
• Type: Insecure deserialization leading to remote code execution
• Access: Network-accessible
• Authentication: Not required
• Privilege upon exploit: Root (in common default deployments)
• Severity: Critical
• CVSS v3.1 Score: 9.8
• Exploitability: High
• Exploit Status: PoC concepts demonstrated in controlled environments for educational/defensive work

Vulnerability Background

This issue arises because the GPT Academic application accepts serialized data uploaded by users and reconstructs internal programming objects from that data without adequate safety checks. When the application deserializes untrusted input, it can inadvertently run code hidden in the serialized content. Because the deserialization is triggered directly after upload by remote users and no authentication is required, an attacker can use this behavior to trigger arbitrary code execution.

In typical installations, GPT Academic is run as a service with elevated rights. If the service is uncompartmentalized and performs deserialization with full privileges, then an attacker who successfully exploits this vulnerability can run arbitrary commands at the highest level of system privilege.

Insecure deserialization has been a known class of weakness for many years. It is rooted in trusting complex binary or structured data from unknown sources, and it often leads to code paths that were never intended to run with user-controlled input.

How the Flaw Is Triggered

The public-facing upload endpoint accepts data from remote clients. When that data contains object serialization structures instead of benign content, the application forwards the serialized blob into a routine that interprets it and rebuilds objects in memory. Because this occurs in a context where the programming environment allows special methods to run during reconstruction, crafted serialized objects can cause those special methods to run attacker-chosen instructions.

The failure to restrict what types of objects are allowed, and the absence of cryptographic signatures or allow-lists during deserialization, is what makes the flaw exploitable.

An attacker does not need valid credentials. They only need to send a carefully encoded payload to the upload endpoint. If the target application is publicly reachable, exploitation can be attempted from any network location.

Impact if Exploited

When this vulnerability is successfully exploited:

• Arbitrary code can be executed by the service process.
• Administrative or root-level control of the host may be obtained.
• Persistent malicious tools or backdoors may be installed.
• Sensitive data may be stolen, corrupted, or deleted.
• The compromised host may be used to attack other systems in the environment.
• Normal service operation may be disrupted.

Because the exploitation path does not require authentication and does not depend on user action beyond sending a malicious upload, the risk level is very high.

How It Could Be Exploited

The general exploitation steps, described at a high level for educational and defensive understanding only, are:

1. A structured serialized payload is constructed in a format understood by the application’s runtime.
2. The malicious payload is transmitted to the application’s upload endpoint using a simple HTTP POST.
3. The application accepts the content and passes it to its deserialization mechanism.
4. The deserialization logic recreates objects described in the serialized data.
5. Code embedded in those objects is invoked by the runtime during reconstruction, leading to command execution.

Due to the lack of validation on type and content, the runtime is tricked into performing operations it should not trust.

Defensive Detection Strategies

To catch exploitation attempts early, defenders should collect and correlate the following data sources:

Logs to Review

• Web server logs: Monitor upload requests (especially POST to upload URIs) with unusual content sizes or binary data types.
• Application error logs: Look for deserialization exceptions, type mismatch reports, or stack traces mentioning object reconstruction.
• Host process logs: Monitor for unexpected shell invocations or interpreter launches by the application process.
• File system audit logs: Watch for new executable files in temporary directories.
• Network logs: Detect unusual outbound connections immediately following upload attempts.

Splunk Detection Rules

Suspicious Upload Volume

index=web_logs
method=POST
uri="*/upload*"
| stats count by src_ip
| where count > 20

Triggers when a single source makes many upload requests in a short interval.

Deserialization Errors in App Logs

index=app_logs
message=("*deserialize*" OR "*unpickl*" OR "*readObject*" OR "*InvalidClass*")
| stats count by host, message

Finds errors indicative of failed deserialization attempts.

Unexpected Shell Invocation by App User

index=os_logs
(process_name="bash" OR process_name="sh" OR process_name="python")
parent_process="gpt_academic*"
| stats count by host, process_name

Alerts when the application spawns shell or interpreter processes.

Suricata Signatures

Detect Serialized Payloads to Upload Endpoint

alert http any any -> any any (
  msg:"DEFENSIVE: Possible serialized payload to upload endpoint";
  flow:to_server,established;
  http.method; content:"POST";
  http.uri; content:"upload";
  content:"|AC ED|"; depth:2;
  classtype:web-application-attack;
  sid:9000764;
  rev:1;
)

This signature looks for Java serialization headers sent to an upload path.

Binary Stream to Upload Path

alert http any any -> any any (
  msg:"DEFENSIVE: Binary stream sent to upload endpoint";
  flow:to_server,established;
  http.uri; content:"upload";
  file_data; content:"|00 00 00|";
  classtype:web-application-attack;
  sid:9000765;
  rev:1;
)

This rule catches generic binary sequences in upload traffic.

Signatures should be tuned based on environment to reduce false positives.

Recommended Mitigations

Until an official patch is applied, the following controls should be in place:

• Isolate the upload endpoint behind authentication and network allow-lists.
• Replace unsafe deserialization with safer data formats (e.g., strict JSON schema validated on receipt).
• Run the application as a low-privilege user, not as root.
• Use strong input validation on all upload content.
• Monitor logs in real time for indicators described above.
• Apply firewall filtering to limit access to known good sources.

Official Patch / Upgrade

The only authoritative source for the fix is the advisory and release tracking page maintained by the GPT Academic project maintainers:

👉 Official Patch / Advisory: https://github.com/advisories/GHSA-cq3m-mpr2-gj92

That page will contain patch links, fixed release versions, and upgrade instructions as soon as they are published. Users of GPT Academic should verify they are running a version that incorporates the fix from that advisory before permitting upload traffic in production environments.

Final Takeaway

This vulnerability presents a serious threat because it allows remote attackers to achieve full code execution without authentication. It is highly recommended that systems running GPT Academic be treated as vulnerable until the official patched release is applied and defensive monitoring is active.