Loading vulnerability…
Improper Authorization in GitLab GraphQL token scope
An improper authorization vulnerability in GitLab CE/EE allows an authenticated user operating through an OAuth application with the read_api scope to perform unauthorized write actions against private projects. Affected versions are all releases from 16.0 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. Due to insufficient authorization enforcement in GraphQL token scope handling, the application could permit creation of issues and addition of comments to issues in private projects even though the token scope should have been limited to read-only API access.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows unauthorized modification of content in private projects by creating issues and posting issue comments despite the OAuth application being limited to the read_api scope. This breaks expected access-control boundaries and can enable unauthorized interaction with private project workflows, project noise generation, and integrity impacts on issue tracking data.
If you can’t patch tonight, do this now.
If immediate patching is not possible, restrict or review OAuth applications granted the read_api scope, especially where they can be used by authenticated users against private projects. Limit issuance and use of OAuth tokens to trusted applications and users, monitor for unexpected issue creation or commenting activity in private projects, and reduce exposure by tightening application authorization policies until patched versions can be deployed. These are temporary risk-reduction measures and do not replace upgrading.
Patch, then assume compromise.
Upgrade GitLab CE/EE to a fixed release: 18.9.7 or later in the 18.9 series, 18.10.6 or later in the 18.10 series, or 18.11.3 or later in the 18.11 series. Cloud-hosted GitLab platforms were already patched. Self-managed administrators should apply the vendor security updates using standard upgrade procedures appropriate to their deployment model.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
2 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.