GitLab GraphQL Code Injection — CVE-2026-19478

CVE-2026-19478 (CVSS 3.1: 9.4 Critical, CWE-94 — Improper Control of Generation of Code) is an unauthenticated code-injection flaw in the GraphQL layer of self-managed GitLab Community and Enterprise Edition. GitLab shipped an out-of-band critical patch release on 2026-08-17 (versions 19.2.4, 19.1.6, 19.0.8, 18.11.11) after a HackerOne researcher (hiimguardian) reported that a GraphQL directive could be abused, without any credentials, user interaction, or unusual configuration, to remotely modify or delete public projects and user data.

Secondary reporting (WatchTowr, corroborated across multiple press outlets) names the abused mechanism as the @gl_introduced GraphQL directive and describes an attacker's practical reach as broader than the vendor advisory's own wording suggests: deleting entire repositories, forging merge records to make it look as though a fix landed when it did not, and banning or removing project maintainers — all via a single unauthenticated HTTP request. WatchTowr researcher Jake Knott stated the firm reproduced the flaw "within minutes" of disclosure using only the advisory and the patch diff, and its honeypot network caught real-world exploitation attempts within days.

The CVSS 3.1 vector — AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H — is the load-bearing technical fact for scoping this pack: Confidentiality is rated Low, Integrity and Availability are rated High. This is a data-integrity and data-destruction vulnerability at the application/repository layer, not a documented remote-code-execution or webshell primitive. No source reviewed for this pack claims OS-level RCE as part of CVE-2026-19478 itself. Any process/network/persistence hunt content in this pack (Section 8, Q2–Q6) targets a secondary, hypothetical follow-on chain — e.g. an attacker who tampers with a public project's CI/CD configuration or merges malicious code that later executes on a build runner — and is explicitly labelled as inferred, not vendor-asserted.

Defender priority: The exploitation string @gl_introduced in an inbound GraphQL request is the single most direct, lowest-false-positive signal for this CVE, but it lives in application/web logs, not default Falcon EDR sensor telemetry — the endpoint sensor does not capture inbound HTTP request bodies to a self-hosted web application. If you have not ingested GitLab, reverse-proxy, or WAF logs into Falcon Next-Gen SIEM (or another log platform), your first control is patching to 19.2.4 / 19.1.6 / 19.0.8 / 18.11.11 and restricting unauthenticated access to /api/graphql at the network edge — not a detection query.

Eight sources were fetched and snapshotted verbatim to GitLab-CVE-2026-19478-Hunt-sources/. Every fact and indicator shipped in this pack traces to one of those snapshots.

Research notes and deliberate exclusions

• The @gl_introduced directive name is a T2/WatchTowr-attributed technical detail, not verbatim text in the T1 GitLab advisory as fetched. GitLab's own patch-release notes describe "a GraphQL directive" without naming it. The name is corroborated consistently across three independent T2 outlets reporting WatchTowr's findings, so it is carried forward at high confidence, but the distinction is preserved rather than presented as vendor-confirmed language.
• No file hashes, C2 domains, or IPv4 indicators are shipped in this pack. This CVE is a logic/data-integrity flaw exploited via crafted HTTP requests against application logic, not malware with attacker-controlled infrastructure. Section 4 and Section 10 reflect that honestly rather than manufacturing atomic IOCs to fill a table.
• CISA KEV status is an explicit gap, not a claim. Multiple secondary aggregators reference KEV activity in the same week, and one search-engine summary conflated this CVE with an unrelated "Ray" framework KEV entry — that conflation was discarded, not carried into this brief. Two direct fetch attempts against cisa.gov (the alert page and the KEV catalog page) both returned HTTP 403. Any KEV-specific claim in this pack is marked as unverified; validate directly against cisa.gov/known-exploited-vulnerabilities-catalog before citing KEV status in a customer-facing document.
• No RCE is asserted for CVE-2026-19478 itself. The CVSS vector (C:L/I:H/A:H) and every fetched source describe data modification, deletion, and account-access removal — not code execution on the underlying host. Section 8's process/network/persistence queries (Q2–Q6) are explicitly framed as hunting a hypothetical secondary chain, per the task brief for this pack.
• No exploit code was fetched, reproduced, or included. WatchTowr's reproduction and public PoC availability are referenced descriptively only.

Hunt hypotheses (ordered by fidelity)

Attack chain

CVE-2026-19478 is a logic/data-integrity vulnerability, not malware with attacker-controlled infrastructure. No file hashes, C2 domains, or IPv4 addresses have been published by any source reviewed for this pack. The table below reflects that honestly — see Section 10 for the corresponding Behavioral Signatures and Named-Vulnerability quick-copy blocks.

The actual exploitation and its highest-value evidence live in GitLab's own logs, not in EDR telemetry. Run these in parallel with, and ahead of, the CQL hunts in Section 8.

• GitLab Rails/API access log (/var/log/gitlab/gitlab-rails/api_json.log on an omnibus install, or your ingested equivalent) — grep or SIEM-search for @gl_introduced in requests to /api/graphql, especially from source IPs with no prior authenticated session.
• GitLab Audit Events (Admin Area > Monitoring > Audit Events, or Audit Event Streaming on Premium/Ultimate) — filter for project deletion, project visibility/data changes, merge-request state changes, and member-removal events around and after the disclosure window (2026-08-17 onward), especially any attributed to an unexpected or anonymous actor.
• Reverse-proxy / nginx access logs — POST requests to /api/graphql with no corresponding authenticated session cookie or bearer token.
• WAF / CDN logs — request-body inspection for @gl_introduced, if body logging is enabled.
• Backup integrity checks — confirm your most recent known-good backup predates any suspected tampering window before relying on it for recovery.
• Git reflog / object store review — orphaned commits, unexpected force-pushes, or merge commits inconsistent with your normal review workflow are consistent with forged merge records.
• Software/version inventory — reconcile every self-managed GitLab instance against the patched version list (19.2.4 / 19.1.6 / 19.0.8 / 18.11.11); see Playbook 1 for a scripted check.

No query in this pack is a clean Block-mode Custom IOA candidate. Q1 is the highest-confidence detection but it is a log query (Falcon Next-Gen SIEM Scheduled Search), not sensor-based behavior — Custom IOAs are endpoint-sensor rules and do not apply to ingested HTTP logs. Q2 and Q3 have workable confidence but medium FP from legitimate GitLab internals; Q4–Q6 carry high FP or low confidence and are investigate-only.

Alert email package — Q1 (primary detection)

Scheduled Search name: DETECT — GitLab GraphQL @gl_introduced Directive Abuse (CVE-2026-19478)

Description: Fires when the literal GraphQL directive string @gl_introduced appears in ingested GitLab, reverse-proxy, or WAF HTTP logs — the primary indicator of a probe or active exploitation attempt against the unauthenticated CVE-2026-19478 code-injection flaw.

Alert email subject: [CRITICAL] Detection: GitLab CVE-2026-19478 — GraphQL directive abuse (@gl_introduced) observed

Alert email body:
------------------------------------------------------------
A request containing the GraphQL directive string "@gl_introduced" was
observed against /api/graphql on {{ host }} from source {{ src_ip }} at
{{ @timestamp }}.

This string is the primary exploitation indicator for CVE-2026-19478, a
CVSS 9.4 unauthenticated code-injection flaw in GitLab's GraphQL layer
(CWE-94). Successful exploitation can modify or delete public projects,
forge merge records, and remove project maintainers WITHOUT any
credentials or user interaction.

IMMEDIATE ACTIONS:
  1. Confirm the target GitLab instance's patch level. If it is NOT on
     19.2.4 / 19.1.6 / 19.0.8 / 18.11.11 (or later), treat this as an
     active incident, not a hunt lead.
  2. Restrict unauthenticated access to /api/graphql at the reverse
     proxy / WAF immediately (Playbook 2) if patching cannot happen
     within the hour.
  3. Pull GitLab Audit Events for the affected instance covering the
     alert window +/- 24h; look for project deletion, data-visibility
     changes, merge-request state changes, and maintainer removal.
  4. Do NOT assume "no visible damage" means no compromise -- integrity
     tampering (forged merge records) is designed to look clean.

ESCALATION: Platform/Infra on-call -> Security IR lead if step 1 confirms
an unpatched, internet-facing instance with a real hit.
------------------------------------------------------------

Triage checklist

1. Confirm the alerting request actually targeted /api/graphql and not an unrelated field that happens to contain the string.
2. Check the target GitLab instance's version against the patched list (Playbook 1).
3. Identify the source IP — is it a known vulnerability scanner or your own patch-validation tooling? If so, close as benign and add to the Q1 TUNING exclusion.
4. If the source is unknown/external, pull GitLab Audit Events for the same window and instance.
5. Check for project deletions, visibility changes, merge-request state changes, or maintainer removals in that window.
6. If any of the above are found, escalate to Security IR — this is a confirmed exploitation attempt with observable impact, not a probe.
7. Preserve the raw log lines and any GitLab audit-event export before further remediation (evidence for Section 14, Phase 1).
8. Regardless of confirmed impact, patch and restrict /api/graphql immediately if not already done.

Pivot queries

Host-scoped: re-run Q2 and Q3 scoped to the same ComputerName as the alerting GitLab instance, over the 24 hours following the Q1 hit, to check for the hypothetical secondary local-execution chain.

Environment-wide: run Q1 across all ingested GitLab instances for the last 30 days (extend the console time picker) to check for earlier, previously undetected probing that predates this alert.

IOC blocklist entries: not applicable — this CVE has no published atomic indicators to block (see Section 4).

Hunt package — Q2 (investigate-only, lighter)

Q2's medium FP means it should not alert unattended. Run it manually against any host that also produced a Q1 hit, or periodically as a hygiene sweep. Pivot: correlate any hit against Q3 (same host/window) — a webshell-style file write alongside an unexpected shell child materially raises confidence over either signal alone.

# CVE-2026-19478 is a logic/data-integrity flaw in GitLab's GraphQL layer, not
# malware with attacker-controlled infrastructure. No file hashes, C2 domains, or
# IPv4 addresses have been published by any source reviewed for this pack --
# shipping fabricated atomic IOCs here would fail this pack's own provenance gate.
#
# Track the vulnerability instead by:
#   CVE ID:            CVE-2026-19478 (companion: CVE-2026-19650)
#   CVSS 3.1:           9.4 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H)
#   CWE:                CWE-94 Improper Control of Generation of Code (Code Injection)
#   Exploitation string: @gl_introduced (GraphQL directive -- see Behavioral Signatures block)
#
# If your own incident response later recovers attacker infrastructure (source
# IPs, follow-on payload hashes, etc.) from a CONFIRMED compromise, add rows here
# in standard type,value,action,severity,expiration,description,tags form and
# re-run check_ioc_provenance.py against a newly saved source snapshot.

# CVE-2026-19478 behavioral signatures (no atomic IOC form)
# Exploitation indicator
GraphQL directive string in request body/URI: @gl_introduced
Target endpoint: POST /api/graphql
Requires: NO authentication, NO user interaction (per GitLab advisory + NVD)
# Impact behaviors to hunt in GitLab Audit Events (Section 7)
Public project data modified or deleted without a corresponding authenticated
  admin/maintainer session
Merge request marked merged/closed with no matching reviewer action
  ("forged merge record" pattern per WatchTowr)
Project maintainer removed or banned with no corresponding admin action
# Secondary/hypothetical chain (inferred, not vendor-asserted)
GitLab app-server process (ruby/puma/unicorn/sidekiq/gitlab-rails/gitlab-workhorse)
  spawning bash/dash/zsh/python/perl/nc/ncat/socat
New executable or script written under /opt/gitlab/, /var/opt/gitlab/, or /home/git/
  by a GitLab app-server process

Primary CVE:     CVE-2026-19478 -- CVSS 3.1 9.4 Critical -- CWE-94
Companion CVE:   CVE-2026-19650 -- CVSS 3.1 7.1 High -- CSRF in GraphQL multiplex
                 query handler (requires user interaction)
Vulnerable:      GitLab CE/EE 18.2 < 18.11.11, 19.0 < 19.0.8,
                 19.1 < 19.1.6, 19.2 < 19.2.4
Patched:         GitLab CE/EE 19.2.4, 19.1.6, 19.0.8, 18.11.11
                 (released 2026-08-17, out-of-band critical patch release)
Not affected:    GitLab.com, GitLab Dedicated (auto-patched)
Reporter:        hiimguardian (HackerOne bug bounty)
Researcher:      WatchTowr (Jake Knott) -- reproduction + honeypot exploitation
Exploited by:    Unknown/unattributed opportunistic scanning observed by WatchTowr
                 honeypot network within days of disclosure

# Version and exposure audit -- run against every self-managed GitLab instance
[ ] Confirm version is 19.2.4 / 19.1.6 / 19.0.8 / 18.11.11 or later (Playbook 1)
[ ] If not yet patched: restrict unauthenticated access to /api/graphql NOW (Playbook 2)
[ ] Inventory which projects on this instance are set to Public visibility (Playbook 3)
[ ] Confirm GitLab Audit Events (or equivalent log export) are being retained/ingested
[ ] Verify last-known-good backup predates 2026-08-17 (pre-disclosure) for comparison
[ ] Confirm whether this instance is GitLab.com / Dedicated (no action) or self-managed (action required)

Import note: this pack ships no rows for Falcon IOC Management by design (see the CSV block above). The importable content here is procedural (patch/version state and audit checklist), not atomic threat infrastructure.

Gate 1 — Telemetry ready

• Q1 requires log ingestion that most tenants do not have by default. Before treating a zero-hit Q1 result as "clean," confirm GitLab/reverse-proxy/WAF logs are actually flowing into Falcon NG-SIEM (or wherever Q1 runs) — a zero-hit result against an empty log source is not a clean bill of health, it's a blind spot.
• Confirm ProcessRollup2/SyntheticProcessRollup2 and NewExecutableWritten/ELFFileWritten are populated for your GitLab application-server hosts specifically (not just Windows fleet defaults — these are typically Linux hosts).
• Confirm ScheduledTaskRegistered/CreateService coverage on your CI/CD runner fleet before relying on Q6.

Gate 2 — Benign baseline

• Run Q2, Q3, Q4, and Q5 over 7 days with no exclusions and record hit counts before promoting any to Monitor mode. Expect Q4 and Q5 to be noisy — that noise is the baseline you tune against, not a false alarm to dismiss.
• Q1 should return zero in a clean environment absent scanning activity; a non-zero baseline needs individual triage (Section 9 triage checklist), not blanket suppression.

Gate 3 — Positive tests

• In a non-production log source, submit a benign test event containing the literal string @gl_introduced and confirm Q1 fires end-to-end (ingestion → search → alert).
• On a lab GitLab host, manually spawn a shell from a process named like one of the Q2 parent patterns (e.g. a test script invoked as ruby) and confirm Q2 fires; clean up afterward.

Gate 4 — Promotion criteria

• Q1 promotes to an active Scheduled Search alert only after Gate 1 (telemetry confirmed present) and Gate 3 (positive test fired) both pass.
• Q2/Q3 promote from Monitor to Alert only after 7+ days at a stable, explained baseline (Gate 2) with your GitLab-internal exclusions applied.
• Do not promote Q4, Q5, or Q6 to alerting in this release — they remain investigate-only pending environment-specific tuning.

1 — Version verification (shell)

# Check current GitLab version on an omnibus install
sudo gitlab-rake gitlab:env:info 2>/dev/null | grep -A2 "GitLab information"

# Alternative -- read the version manifest directly
cat /opt/gitlab/version-manifest.txt | grep -i gitlab-ce

# PASS if version is 19.2.4 / 19.1.6 / 19.0.8 / 18.11.11 or later.
# FAIL (patch immediately) if version is in any of:
#   18.2 - 18.11.10, 19.0 - 19.0.7, 19.1 - 19.1.5, 19.2 - 19.2.3

Prerequisites: SSH/admin access to the GitLab omnibus host. Reboot required: no (read-only check). Rollback: none required — this is a read-only verification step.

2 — Restrict /api/graphql at the reverse proxy (nginx, temporary compensating control)

# /etc/nginx/conf.d/gitlab-graphql-restrict.conf
# Place inside (or alongside) the existing GitLab server block, then reload.
location /api/graphql {
    # Restrict to known internal/CI ranges only -- adjust to your environment.
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    deny all;
}

sudo nginx -t && sudo nginx -s reload

Prerequisites: nginx (or equivalent reverse proxy) terminating in front of GitLab; admin access to edit its config. Reboot required: no. Rollback: remove the location /api/graphql block from the config file, then run sudo nginx -t && sudo nginx -s reload again.

3 — Public-project visibility audit (GitLab Rails console, read-only)

# Run from: sudo gitlab-rails console
Project.where(visibility_level: Gitlab::VisibilityLevel::PUBLIC).pluck(:id, :path_with_namespace)

Prerequisites: admin access to gitlab-rails console on the omnibus host. Reboot required: no. Rollback: none required — this is a read-only query; no state is changed. Changing a project's visibility afterward is a separate, deliberate admin action taken outside this playbook.

4 — Temporary WAF virtual-patch rule for @gl_introduced (ModSecurity example)

# /etc/modsecurity.d/gitlab-cve-2026-19478-virtual-patch.conf
SecRule REQUEST_URI "@streq /api/graphql" \
    "chain,id:1000019478,phase:2,deny,log,msg:'Blocked possible CVE-2026-19478 GraphQL directive abuse'"
    SecRule REQUEST_BODY "@contains @gl_introduced" "t:none"

sudo apachectl configtest && sudo systemctl reload apache2
# or, for an nginx+ModSecurity install:
sudo nginx -t && sudo nginx -s reload

Prerequisites: ModSecurity (or an equivalent WAF engine) in the request path in front of GitLab, with request-body inspection enabled. Reboot required: no (WAF config reload only). Rollback: remove or disable rule id 1000019478 and reload the WAF engine. This is explicitly a temporary compensating control — retire it once every instance is confirmed on a patched version (Playbook 1).

This pack's most important honesty point is here: the CVE's actual documented impact (T1565.001 / T1485 / T1531) has zero Falcon EDR coverage, because it is an application-layer data-integrity attack, not an endpoint compromise. Detection depends entirely on GitLab's own audit logging (Section 7) and, for the @gl_introduced string specifically, on ingesting web/proxy/WAF logs into a SIEM (Q1). The endpoint-telemetry queries (Q2–Q6) hunt a hypothetical secondary chain and should not be mistaken for coverage of the CVE itself. Clear Gate 1 in Section 11 — especially the log-ingestion prerequisite — before treating a zero-hit Q1 result as a clean bill of health.

Provenance: the fetched text of all eight sources is saved alongside this pack in GitLab-CVE-2026-19478-Hunt-sources/. This pack ships no atomic file/network IOCs, so the provenance gate (check_ioc_provenance.py) has nothing to trace and passes vacuously — every factual claim in this pack is nonetheless attributable to one of the eight numbered sources above.

Unresolved gap: CISA Known Exploited Vulnerabilities (KEV) catalog status for CVE-2026-19478 could not be independently confirmed — cisa.gov returned HTTP 403 to automated fetch on both the alert page and the KEV catalog page. Validate directly at cisa.gov/known-exploited-vulnerabilities-catalog before making a KEV-status claim in a customer-facing report.