CVE-2026-19478
CVSS 9.4 CRITICAL: gitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.11.11, 19.0 before 19.0.8…
Vulnerabilities & Exploits · Web App Attack
GitLab said on August 17 that it had fixed CVE-2026-19478 in Community Edition and Enterprise Edition, and WatchTowr says it saw the first in-the-wild exploitation attempts within about two days of disclosure. The bug affects self-managed GitLab 18.11.11, 19.0.8, 19.1.6, and 19.2.4.
The flaw sits in GraphQL: a normal-looking unauthenticated request can be accepted as a project action, letting an attacker modify or delete public project state, rewrite repositories, or forge merge records. That makes this more than a service issue; tampered history can look like ordinary GitLab activity, so logs may not tell you that the record itself has been poisoned.
For teams that use GitLab as a source of truth for public code or release pipelines, the exposure does not end when the patch lands. If an instance was hit, repository state, merge history, and downstream release provenance may all need separate trust checks because the attacker can alter the evidence, not just the app.
9 sources · Aug 24
CVSS 9.4 CRITICAL: gitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.11.11, 19.0 before 19.0.8…
The Hacker News
⚡ Weekly Recap: AI-Powered PLC Attacks, GitLab Attacks, Stripe Key Leaks and More
originalThe Hacker News
GitLab CVE-2026-19478 Comes Under Active Exploitation Within Days of Disclosure
GitLab CVE-2026-19478 is under active exploitation, with unauthenticated attacks able to modify or delete public projects under certain conditions.
originalSecurityWeek
Critical GitLab Flaw Exploited Shortly After Disclosure
CVE-2026-19478 can be exploited without authentication to modify or delete public projects and user data.
originalPart of the PlainSec briefing for 2026-08-19
Every edition of this story: GitLab Exploitation Turns Repo History Into a Target