Critical SSRF in Repomix (CVE-2026-59702): The Popular AI Code-Packing Tool's Server Could Leak Cloud Keys — Update to 1.14.1

A critical flaw has been found in Repomix, the popular tool that bundles an entire codebase into a single file so you can hand it to an AI such as ChatGPT or Claude. It is tracked as CVE-2026-59702, rated CVSS 9.3 (Critical, out of 10). No login is required to exploit it.

The problem lived in the server behind the official web tool at repomix.com, where you can paste a repository URL and have it packed for you. By sending a crafted URL, an attacker could turn Repomix's own server into a proxy and read internal data from the cloud environment it runs on — a classic Server-Side Request Forgery (SSRF), an attack that tricks a server into making requests it should never make. The real target was the production environment on Google Cloud Run that powers the official site.

The fix is Repomix 1.14.1. According to VulnCheck, every version before 1.14.1 is affected. The public repomix.com site is already patched, but if you self-host this server feature of Repomix and expose it, update to 1.14.1 now. If you only use Repomix as a local command (more below), you are not the direct target of this SSRF, yet the same 1.14.1 release fixes another flaw too, so updating is still recommended. As of publication, there is no entry in the U.S. CISA catalog of vulnerabilities under active attack (KEV) and no report of real-world exploitation.

What Repomix is, and why this hole is dangerous

Repomix is an open-source tool published by Japanese developer yamadashy. Source code is split across dozens or hundreds of files, and feeding it to an AI file by file is tedious. Repomix bundles an entire repository (the place where source code is stored) into a single AI-friendly file, which has made it a go-to tool in modern AI-assisted coding — you can hand your whole codebase to Claude, ChatGPT, or Gemini and ask questions. It has over 20,000 GitHub stars and shows up often on lists of handy tools around Claude Code.

There are three main ways to use it: (1) install it as a local command and run it on your own machine (npx repomix); (2) open repomix.com in a browser and paste a GitHub URL to have it packed; and (3) connect it directly to an AI assistant via MCP. This vulnerability was in the server side that powers option (2), the web version.

In the web version, the server receives the repository URL you enter and runs git clone (the operation that fetches a copy of the code) against it, then packs the result. The trouble is that the server trusted the user-supplied URL and made a request to it as-is. An attacker could dress up an address that is only reachable from inside the server as if it were a "GitHub repository," and the server would dutifully start talking to its own internals. That is SSRF. The cloud's internal management address, the private network, and local files on the server — all normally out of reach — become accessible by using the server itself as a stand-in. That is what makes this flaw dangerous.

Who attacks this, what they want, and how far the damage reaches

"SSRF" may not mean much at first, so let's pin down the blast radius. Not everyone who uses Repomix is equally at risk. Which way you use it decides whether this is your problem.

The people who profit from this hole are not pranksters. They are financially motivated attackers and bots that spray SSRF at cloud-hosted services to steal the cloud's credentials (keys) and pivot into full takeover. What they really want is not the source code Repomix bundles. It is to reach the "management address" of the cloud (here, Google Cloud) where Repomix's server runs, using the server itself, and lift the access token (key) tied to that service.

Cloud servers expose a special address (the metadata service) for checking their own configuration and permissions. It is meant to be reachable only from inside that server and is not exposed externally. But once SSRF works, an attacker can tell the server, "Go query your own management address and show me the result." What comes back is the key the server uses to access other cloud services. Hold that key, and the attacker can impersonate the legitimate server and spread into other cloud assets — databases, storage, and more.

The first to suffer is whoever operates the web service. Leaked cloud keys lead to data exfiltration, fraudulent billing, and service tampering. Ordinary users of the service can also be caught in the blast: the code you pasted and the information you entrusted to the service could leak too. Behind a "just paste a URL" free tool, all of this was possible. The official site is already fixed, but if you stand up the same setup yourself and expose it, this is not someone else's problem.

What was actually happening — the technical detail

The problem sat at the POST /api/pack endpoint behind the web version — the entry point that takes the user's repository URL and starts packing. Per the reported issue (#1703), the isValidRemoteValue function that checks the URL only looked at whether it had the "owner/repo" shape.

That check pulled out the path with the git-url-parse library and accepted anything matching a loose [a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+ ("something/something") pattern. So whether the URL began with http://, https://, or even file:// pointing at a file on the server, as long as the tail looked like "something/something," it passed and went straight to git clone. The issue showed three examples.

The second one, http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token, is the most dangerous use of this flaw. That is the standard address a Google Cloud server uses to fetch its own credential token, and reaching it via SSRF hands over the key to impersonate that server, wholesale. VulnCheck's score leans heavily on confidentiality (read) impact, landing at CVSS 9.3, precisely because it "reaches the cloud key." The first, internal address enables private-network reconnaissance; the third, file://, enables reading files on the server. The VulnCheck advisory also notes reachability to other internal services such as Redis.

The fix, in Pull Request #1706, tightens URL validation so that anything other than a valid git repository target (internal addresses, file://, and so on) is rejected. This "the server makes a request to a user-supplied URL" pattern is a textbook pressure point where convenience and danger sit back to back — the same shape as the AI tool Langflow, which came under attack right after disclosure. Because developer tools like Repomix that handle code and dependencies sit upstream in the open-source supply chain, the ripple effects when they are compromised tend to be large.

Timeline from discovery to fix

← Swipe to navigate

The first private report came on June 2, 2026, but the fix took a while, and on July 5 the details, including proof-of-concept code, became public. The identifier CVE-2026-59702 was assigned on July 8. The reporter is security researcher geo-chen.

What to do right now

The response depends on how you use Repomix.

• If you self-host the web version: update to Repomix 1.14.1 or later as a top priority. If you cannot update, consider stopgaps such as blocking outbound traffic from that server to the cloud management address (the metadata service) and the internal network, and narrowing the range from which it can be reached.
• If you only use the official repomix.com site: the site is already fixed and no action is needed on your end. That said, as with any "just paste a URL" free service, think carefully before handing highly sensitive private repositories to an external service at all.
• If you only use it as a local command: you are not the direct target of this SSRF. But the same 1.14.1 also fixes a separate flaw where a crafted branch name can lead to command execution (CVE-2026-49987) and an MCP information disclosure, so updating is recommended.

Because the server feature itself ships as part of the npm package, check and update the version even if you have embedded it into CI/CD or internal tooling.

A developer's view: the recurring "trusting a URL too much" problem

The root cause comes down to one thing: the user-supplied URL was not narrowed down enough before the server made its request. It only checked whether the URL "looked like" a git repository, not whether the destination was an internal address, or whether the protocol should reject http/https/file. The standard defense against SSRF is not string-pattern matching on the URL but looking at the actual resolved IP address and rejecting internal-facing ones (private addresses and the cloud metadata address). A string-match-only check, paired with a permissive parser like git-url-parse, slips through as easily as it did here.

This shape keeps recurring in developer tools. The AI tool Langflow, attacked right after disclosure, the vulnerability in Snowflake's command-line tool, the flaw in the mise dev tool, and the vulnerability in Amazon's AI dev tool Kiro all follow the pattern where a tool that suddenly caught on in the AI era takes external input with a convenience-first implementation, and holes surface later. Repomix is actively developed and handled the report, fix, and disclosure as a whole, which is healthy; but the lesson that "a feature where the server itself reaches out to a user-supplied URL" is always a breeding ground for SSRF applies to every tool of this kind.

This case is one of the developer-tool CVEs that clustered around this period, which we also touched on in the July 8 security roundup.

FAQ

Bottom line

Repomix, the popular tool for handing code to an AI, had a critical SSRF (CVE-2026-59702, CVSS 9.3) that let attackers use its public server as a proxy to read internal data. The target was the production environment on Google Cloud that powers the official site, and reaching the cloud's credential key is the most dangerous part. The official site is already patched, but if you self-host the same server feature, update to 1.14.1 now. Even if you only use it as a local command, update for the separate flaw fixed at the same time. Behind the convenience of "just paste a URL," the plain-but-effective discipline of controlling what a server is allowed to talk to is exactly what this incident drives home again.

Sources

• ›NVD — CVE-2026-59702
• ›VulnCheck — Repomix SSRF Advisory
• ›GitHub Issue #1703 — SSRF via /api/pack
• ›GitHub Pull Request #1706 — the fix
• ›Repomix Releases (1.14.1)
• ›GitLab Advisory — CVE-2026-49987 (a separate flaw fixed at the same time)
• ›Repomix official repository