NextChat 2.16.0 and 2.16.1 let anyone make the server fetch any URL through the x-base-url header. A public PoC exists and the fix is still an open PR.
CVE-2026-105238 is a server-side request forgery in NextChat, the open-source ChatGPT-style web client from ChatGPTNextWeb. A route in app/api/proxy.ts fetches whatever URL a caller names in the x-base-url header, without authentication. VulDB lists versions 2.16.0 and 2.16.1 as affected, a public proof of concept exists, and as of 6 October 2026 the fix is an open, unmerged pull request.
What happened
NVD published the record on 5 October 2026, with VulDB as the CNA. It describes a flaw in the proxyHandler function of the Proxy Fallback Handler, where manipulating x-base-url causes SSRF that can be started remotely. NVD's status is "Received", so NVD has not yet done its own analysis. All scores come from VulDB: CVSS 3.1 7.3 (High) and CVSS 4.0 5.5 (Medium).
The underlying report is older. A researcher (geo-chen) opened public issue #6813 on 5 July 2026. The issue says the flaw was reported privately through a GitHub security advisory on 2 June 2026 and got no response. An outside contributor with no repository role said on 21 July they were working on a fix, and a separate contributor opened pull request #6884 on 28 August. It is still open, and the maintainers have not publicly responded.
Why it matters
NextChat is a widely forked project (about 88,800 stars and 58,900 forks on 6 October 2026), and the issue's proof of concept targets the self-hosted Docker image. Those numbers show popularity, not exposure. No source we reviewed counts internet-facing instances, so the number of reachable servers is unknown.
Technically, the flaw needs no credentials and no user interaction, and the reporter says the CODE access-code setting does not protect the route. Operationally, the damage depends on what the server can reach. A NextChat container on a home network, in a cloud VPC with instance metadata enabled, or beside internal services each carries a different risk. We covered the same flaw class in Dify's remote-file upload, and the MCP fetch server SSRF is another AI-tooling SSRF with no released fix. The CVSS Low impact ratings fit that uncertainty.
Exploitation of the SSRF: the CNA says an exploit is public. CISA's SSVC entry records exploitation as "poc" and automatable as "yes". We found no report of the SSRF being exploited in the wild, and it is not in CISA's KEV catalogue. The key leak below is different: one user reports abuse.
Technical details
The catch-all route app/api/[provider]/[...path]/route.ts hands requests to named provider handlers (OpenAI, Anthropic, Google and others). Any provider segment it does not recognise reaches the default case, which calls proxyHandler. On the current main branch that is still the case.
proxyHandler builds the outbound URL from the x-base-url header, the request path and the query string. Per the issue, the OpenAI, Anthropic and Google handlers call auth() first, while proxy.ts does not, and no allowlist restricts the target. So a request to /api/<any-unknown-name>/<path> with an x-base-url header makes the server issue a request to that host.
The reporter's proof of concept pointed the header at a Python HTTP listener and saw the connection arrive from the NextChat container, with the listener's Server header returned to the caller. That confirms a server-side request. The report also gives a request to 169.254.169.254 (the cloud metadata address) as an example of reachable targets and claims temporary IAM credentials could be retrieved. The issue shows no output from such a request, so treat that as a plausible consequence, not a demonstrated one.
The reporter also notes that next.config.mjs sets Access-Control-Allow-Origin: * and Access-Control-Allow-Headers: * on API routes (unless built in static export mode). They argue this lets a web page open in a victim's browser send these requests, which could reach servers only the victim's network can see. We did not test this. The route file declares an edge runtime, and whether that changes what an edge-hosted deployment can reach was not established in the sources.
A related but separate flaw: the OpenAI key
Issue #6814, from the same reporter, describes a different bug in the same file. proxy.ts decides whether to attach the server's OPENAI_API_KEY by checking x-base-url with includes("api.openai.com"). A URL such as http://attacker.example?q=api.openai.com passes the check. The reporter says they validated this on commit 89b8f26 (v2.16.1) and showed a test key, sk-test-dummy-key-for-ssrf-research, arriving verbatim in the Authorization header at their own server. Our check of the main branch shows that code is still there. It only matters if the operator has set OPENAI_API_KEY on the server, which the reporter calls the normal configuration for self-hosted instances.
One commenter on #6814 (ballerbude, 15 July) wrote that they "got hit by that yesterday" and that their "5$ OpenAPI credits" were gone. That is an unverified user report, but it is the only sign of real-world abuse we found.
This is not part of CVE-2026-105238. The CVE description covers SSRF only, and we found no CVE for #6814. PR #6884 addresses both, and its title says "key leak and SSRF".
What defenders should do
Fix status first. v2.16.1 (29 July 2025) is the latest release, more than 14 months old, and it contains no fix. The repository was last pushed on 11 August 2026, which says little about whether a release is coming. PR #6884 is open, has no review comments and shows an unstable merge state. It states that it:
- sends the server OpenAI key only when the parsed hostname is exactly
api.openai.com; - rejects non-HTTP(S) targets and private, loopback, link-local and metadata destinations with HTTP 400.
Its own test plan has three manual checks not yet ticked, and its description does not mention adding authentication, which the 21 July commenter had listed in their plan. Its 11 unit tests passed according to the author. Review the diff yourself before building from it.
Steps that follow from the sources and general practice (the sources themselves state no vendor mitigation):
- Find NextChat deployments, especially the Docker image and any exposed to the internet, and check whether they run 2.16.0 or 2.16.1.
- Restrict network access to them (VPN, authenticated reverse proxy, IP allowlist) since the application's own access code does not cover this route, per the reporter.
- On cloud hosts, enforce IMDSv2 or equivalent metadata protections and limit the instance role's permissions. Block egress from the container to internal ranges where possible.
- If
OPENAI_API_KEYis set on an exposed server, consider the key at risk given #6814, and rotate it once the instance is patched or isolated. - Look in access logs for requests to
/api/<name>/...where the name is not a known provider, and for anx-base-urlheader if your proxy logs headers. Outbound connections from the container to metadata or internal addresses are worth a look. - A reverse-proxy rule that blocks the
x-base-urlheader or unrecognised/api/provider paths is a reasonable stopgap. Test it, because legitimate plugin features may use the proxy route.
What is still unclear
- Whether the maintainers will merge #6884 or cut a release, and when. The maintainers have not publicly responded to the reports.
- How many instances are exposed. No telemetry was found.
- Whether metadata credential theft works on real deployments. Only a listener-based PoC is shown.
- Whether versions before 2.16.0 are affected. The CNA lists only 2.16.0 and 2.16.1, and the
proxy.tshistory suggests older code may be similar, but that is untested. - Whether #6814 receives its own CVE.
- NVD analysis is pending and the scores could change.
Disclosure timeline for CVE-2026-105238.
Sources
- NVD record for CVE-2026-105238: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-105238
- NextChat issue #6813 (SSRF): https://github.com/ChatGPTNextWeb/NextChat/issues/6813
- NextChat issue #6814 (OpenAI key leak): https://github.com/ChatGPTNextWeb/NextChat/issues/6814
- NextChat pull request #6884: https://github.com/ChatGPTNextWeb/NextChat/pull/6884
- NextChat releases: https://github.com/ChatGPTNextWeb/NextChat/releases
- proxy.ts on main: https://raw.githubusercontent.com/ChatGPTNextWeb/NextChat/main/app/api/proxy.ts
- NextChat repository: https://github.com/ChatGPTNextWeb/NextChat