CVE-2025-7659 is a high severity (CVSS 8.0) incomplete validation flaw in the GitLab Web IDE. It could let an unauthenticated user steal tokens and read private repositories. It affects GitLab CE and EE 18.2 before 18.6.6, 18.7 before 18.7.4 and 18.8 before 18.8.4. Upgrade to a fixed release.
What's affected
From the GitLab patch release notice for 18.8.4, which the record links:
- GitLab CE and EE, all versions from 18.2 before 18.6.6
- 18.7 before 18.7.4
- 18.8 before 18.8.4
Fixed releases are 18.6.6, 18.7.4 and 18.8.4. GitLab says the issue was reported through its HackerOne bug bounty program.
How to check if you're exposed
On a self managed instance, read the version as an administrator, in the Admin Area or on the help page. From the server:
sudo gitlab-rake gitlab:env:info
Compare the result with the three fixed versions above. GitLab.com is run by the vendor, so self managed instances are your concern.
- List all self managed GitLab instances, including staging and group specific ones.
- Check whether the Web IDE is available to users on them.
- Review personal and project access tokens, and revoke any you do not recognise.
What to do now
- Upgrade to 18.6.6, 18.7.4 or 18.8.4 or later, depending on your release line.
- Check the GitLab release notice for any extra upgrade steps for your version.
- Review active tokens and revoke old or unneeded ones. The CVSS vector requires user interaction, so remind staff not to follow unexpected links into the Web IDE.
- Review audit logs for unfamiliar token use or repository access from unusual addresses.
- Subscribe to GitLab patch release notices so the next one reaches you quickly.
Self managed GitLab is one of the easier systems to forget. Teams stand up a second instance for a group or a migration, and it falls behind the main one. Check your asset list and your network for GitLab login pages, so you patch every instance and not only the one with an owner.
When you upgrade, follow GitLab's documented upgrade path for your version, because some upgrades need a stop at a particular release first. Take a backup of the instance before you start.
After the upgrade, review the tokens that exist. Personal access tokens, project tokens and deploy tokens are the assets this class of bug targets, so remove old ones, shorten expiry on those you keep and scope each to the least access it needs. Any token that sat in a place a stranger could have reached it is worth rotating, even without evidence of misuse.
Why it matters
The weakness is CWE-346 (origin validation error). The description says the Web IDE did not fully validate something it should have, and that gap could be abused to steal tokens. The CVSS vector marks high attack complexity and user interaction, which keeps the score at 8.0 rather than critical.
The impact is high on confidentiality and integrity, and the scope is changed, since a stolen token acts beyond the Web IDE. The record does not mark this as exploited, and it is not in the CISA KEV list.
Source code hosting is an attractive target because private repositories contain secrets, build configuration and internal design details.
The class of bug is origin validation. A web based editor runs inside the page of your GitLab domain and talks to other components. If the checks on where a message or request comes from are incomplete, a page from somewhere else can take part in the exchange. In this case the record says that can lead to token theft. The vector marks user interaction as required, and the attack complexity as high, so the attacker has work to do. The scope is changed, because a token opens things beyond the editor.
For defenders the lesson is to treat tokens as the real prize. A token is a password with a scope and often no second factor. Short expiry, narrow scope and a habit of removing unused tokens turn a theft into a limited event.
It also helps to turn on notifications from the vendor. GitLab publishes patch releases on a regular rhythm, and security fixes appear in that notice with their versions. Subscribing means the next one reaches your team the day it ships, not the week after.
Try it yourself
Version drift on a self managed server is easy to miss. Continuous monitoring keeps a fix from waiting for the next audit.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to act on GitLab.com?
The notice covers GitLab CE and EE releases. Self managed instances on the affected versions need the upgrade.
Which release fixes the 18.7 line?
18.7.4, per the GitLab patch release notice.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
Also referenced by the CVE record:
Last reviewed: 19 October 2026.
