What happened
A critical GitLab vulnerability patched on August 17 is now being exploited in the wild. CVE-2026-19478, scored 9.4 out of 10, is a code injection flaw in GitLab's GraphQL API that lets an unauthenticated attacker modify or delete publicly accessible projects with a single HTTP request — no credentials and no user interaction. Researchers at watchTowr said they reproduced the bug within minutes of its disclosure and have since observed exploitation attempts against their honeypot systems. Attackers can delete entire repositories, ban project maintainers, and — most concerning for software supply chains — forge merge records so that a malicious change appears to have been reviewed and approved by someone the team trusts. The flaw affects self-managed GitLab Community and Enterprise Edition servers from version 18.2 through 19.2; fixes shipped in 19.2.4, 19.1.6, 19.0.8, and 18.11.11. GitLab.com and GitLab Dedicated were patched by GitLab and need no customer action.
Why it matters for your business
Many small firms and agencies run a self-hosted GitLab because it is inexpensive and private — and self-hosted means nobody patches it for you. The gap between patch release and active exploitation was measured in days here, which is now typical; a quarterly maintenance schedule cannot protect internet-facing software. The forged-merge-record capability matters even if you only consume software: it is a mechanism for slipping malicious code into projects that look properly reviewed, the kind of upstream tampering that eventually lands in someone's product.
What to do about it
- If you self-host GitLab, update to a fixed version immediately.
- If you cannot patch today, restrict unauthenticated access to the /api/graphql endpoint as a stopgap.
- Check web logs for requests containing @gl_introduced, an indicator researchers have tied to exploitation attempts.