CVE-2026-0723 - GitLab 2FA device response bypass

GitLab CE/EE shipped an authentication-services flaw where a forged device response could bypass two-factor authentication when the attacker already knew the victim’s credential ID. The issue is tracked as an unchecked-return-value weakness and affects self-managed GitLab installations in the 18.6, 18.7, and 18.8 release trains before the January 2026 patch releases.

For a repository, this is usually not a library bump. The owned surface is often a GitLab deployment definition: Omnibus package pins, Docker image tags, Helm chart values, Terraform modules, Ansible roles, Kubernetes manifests, backup/restore runbooks, or source-install instructions. If the repository maintains a GitLab fork or custom authentication integration, the code review must also verify that WebAuthn/device-response validation checks every return value before accepting an MFA challenge.

When to use it

  • A repository controls self-managed GitLab CE/EE deployment artifacts, package pins, image tags, Helm values, Terraform/Ansible modules, source refs, or upgrade runbooks.
  • Controlled deployments may resolve GitLab 18.6.x, 18.7.x, or 18.8.x before the patched releases.
  • The repository carries a GitLab fork, SSO adapter, reverse proxy, plugin, or custom MFA/WebAuthn authentication service.
  • You need a bounded PR or triage note that upgrades GitLab and documents MFA log review and operator follow-up without exposing credential IDs.

Inputs

  • Docker/Compose/Helm/K8s/Terraform/Ansible/Chef/Puppet artifacts, Omnibus package pins, source-install refs, image digests, SBOMs, generated reports, backup/rollback docs, and runbooks.
  • Resolved GitLab versions, deployment topology, migration requirements, custom MFA code, auth/audit log ownership, session/MFA reset policy, and external instance owners.
  • Available manifest render, Helm/Terraform/Ansible validation, image resolution, custom auth tests, staging smoke tests, SBOM, and security scans.

Affected versions

Product Vulnerable versions Fixed versions
GitLab CE/EE 18.6 18.6.0 through versions before 18.6.4 18.6.4+
GitLab CE/EE 18.7 18.7.0 through versions before 18.7.2 18.7.2+
GitLab CE/EE 18.8 18.8.0 through versions before 18.8.2 18.8.2+

GitLab.com was already patched by GitLab. GitLab Dedicated customers do not need to apply repository-side deployment changes for this CVE unless they also operate separate self-managed instances.

Indicator-of-exposure

  • The repository deploys self-managed GitLab CE/EE using Omnibus packages, Docker images, Helm charts, source installs, AMIs, VM images, Terraform, Ansible, Chef, Puppet, Kubernetes manifests, or Compose files.
  • A controlled deployment resolves GitLab 18.6.x <18.6.4, 18.7.x <18.7.2, or 18.8.x <18.8.2.
  • Runbooks or automation pin gitlab/gitlab-ce, gitlab/gitlab-ee, gitlab/gitlab-runner adjunct images, package repository snapshots, or upgrade channels without enforcing the patched GitLab application version.
  • The instance permits 2FA, WebAuthn, passkeys, or device-based MFA for users whose credential IDs may be discoverable through logs, backups, support exports, database reads, browser compromise, or previous incidents.
  • The repository carries a GitLab fork, plugin, reverse proxy, SSO adapter, or custom authentication service that validates MFA device responses.

Quick checks:

rg -n "gitlab/gitlab-(ce|ee)|gitlab-ce|gitlab-ee|gitlab[_-]?version|18\\.(6|7|8)\\.|global\\.gitlabVersion|gitlab\\.rb|GITLAB_OMNIBUS_CONFIG|webservice:|sidekiq:" .
rg -n "webauthn|two.?factor|2fa|mfa|credential.?id|device.?response|authenticat" app config lib ee spec qa . 2>/dev/null

Windows:

rg -n "gitlab/gitlab-(ce|ee)|gitlab-ce|gitlab-ee|gitlab[_-]?version|18\\.(6|7|8)\\.|global\\.gitlabVersion|gitlab\\.rb|GITLAB_OMNIBUS_CONFIG|webservice:|sidekiq:" .
rg -n "webauthn|two.?factor|2fa|mfa|credential.?id|device.?response|authenticat" app config lib ee spec qa .

Do not attempt to bypass 2FA, forge device responses, extract credential IDs, query production databases for MFA secrets, or print authentication log payloads while triaging.

Remediation strategy

  • Upgrade every repository-controlled self-managed GitLab deployment to a patched supported version: 18.8.2+, 18.7.2+, 18.6.4+, or a later supported release train.
  • Refresh Docker image tags, Helm chart values, Omnibus package pins, package repository snapshots, Terraform/Ansible variables, source-install refs, image digests, SBOMs, generated dependency reports, and runbooks.
  • Preserve GitLab’s documented upgrade path. Check whether the selected patch release includes database migrations, post-deploy migrations, or downtime requirements for single-node instances.
  • If this repository owns a GitLab fork or custom MFA code, fix the unchecked return-value path and add tests proving forged, malformed, failed, unknown, and mismatched device responses cannot satisfy MFA.
  • Review sign-in, 2FA, WebAuthn, admin, and audit logs for suspicious activity during the vulnerable window without exposing user identifiers unnecessarily.
  • Assign operator follow-up for forced sign-out, MFA re-registration, or credential reset only when logs, incident evidence, or credential-ID exposure justifies it.

The prompt

You are remediating CVE-2026-0723, a high-severity GitLab CE/EE
authentication-services issue where an attacker with knowledge of a victim
credential ID can bypass two-factor authentication by submitting forged device
responses. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades every repository-controlled
  self-managed GitLab deployment, refreshes generated artifacts and runbooks,
  adds safe version or authentication regression checks, and documents operator
  follow-up, or
- TRIAGE.md if this repository does not control an affected self-managed
  GitLab deployment, image, package pin, source install, fork, or MFA
  authentication surface.

## Rules

- Scope only CVE-2026-0723 and directly related GitLab CE/EE deployment or MFA
  authentication-service changes.
- Treat credential IDs, MFA device data, WebAuthn/passkey material,
  authentication logs, session tokens, cookies, admin accounts, user emails,
  database rows, backup exports, and incident evidence as sensitive.
- Do not attempt 2FA bypass, forge device responses, scrape credential IDs,
  query production databases, disable MFA, weaken SSO, or print auth logs.
- Do not remove authentication, audit logging, backups, migrations, or tests to
  make the upgrade simpler.
- Do not auto-merge.

## Steps

1. Inventory every repository-controlled GitLab surface: Dockerfiles, Compose
   files, Helm values, Kubernetes manifests, Terraform, Ansible/Chef/Puppet,
   Omnibus package pins, VM or AMI bake scripts, source-install refs, SBOMs,
   generated dependency reports, upgrade docs, and runbooks.
2. Determine every resolved GitLab CE/EE application version. A target is
   vulnerable if it resolves to `18.6.x <18.6.4`, `18.7.x <18.7.2`, or
   `18.8.x <18.8.2`.
3. If the repository only uses GitLab.com, GitLab Dedicated, or an externally
   owned self-managed instance, stop with `TRIAGE.md` naming checked files,
   the external owner if known, and the required fixed versions.
4. Upgrade controlled deployments to `18.8.2+`, `18.7.2+`, `18.6.4+`, or a
   later supported GitLab release. Prefer the latest compatible supported patch
   release for the pinned train.
5. Refresh image digests, lockfiles, generated manifests, package repository
   snapshots, SBOMs, dependency/security reports, environment docs, backup and
   rollback instructions, and upgrade runbooks.
6. Preserve required GitLab migration handling:
   - note whether the instance is single-node or multi-node;
   - account for database and post-deploy migrations;
   - keep backup and rollback instructions explicit;
   - do not skip documented intermediate upgrade requirements.
7. If this repository owns a GitLab fork or custom authentication integration,
   inspect MFA/WebAuthn/device-response validation code for unchecked return
   values. Add fail-closed checks before any MFA challenge is accepted.
8. Add safe regression coverage where practical:
   - deployment manifests resolve a patched GitLab version;
   - images use patched tags or digests;
   - custom MFA validation rejects forged, malformed, failed, unknown, and
     mismatched device responses;
   - errors and logs do not expose credential IDs, MFA material, or auth
     tokens.
9. Add a PR body section named `CVE-2026-0723 operator actions` that states:
   - GitLab versions before and after;
   - which deployment surfaces were patched or triaged;
   - whether the instance is single-node or multi-node;
   - migration, backup, and rollback notes;
   - whether auth/audit logs should be reviewed for the vulnerable window;
   - whether forced sign-out, MFA re-registration, or credential resets need a
     human owner;
   - which validation commands passed.
10. Run available validation: manifest rendering, Helm template checks,
    Terraform/Ansible validation, container image resolution, GitLab upgrade
    dry-run or staging smoke test, custom auth unit tests, SBOM refresh,
    dependency/security scans, and version checks against the deployed artifact.
11. Use PR title:
    `fix(sec): remediate CVE-2026-0723 in GitLab deployment`.

## Stop conditions

- No affected self-managed GitLab deployment, image, package pin, source
  install, fork, or MFA authentication surface is controlled by this
  repository.
- The affected GitLab instance is owned by another team, GitLab.com, or GitLab
  Dedicated; document the owner and required fixed version in `TRIAGE.md`.
- The upgrade requires a broader GitLab release-train migration, database
  migration decision, downtime window, or backup/restore approval outside this
  repository's authority.
- Verification would require bypassing MFA, using real credential IDs, reading
  production auth logs, querying production databases, or exposing user data.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled deployment artifact resolves GitLab CE/EE 18.6.x <18.6.4, 18.7.x <18.7.2, or 18.8.x <18.8.2.
  • Image tags, digests, Helm values, package pins, source refs, SBOMs, generated reports, and runbooks agree on the patched GitLab version.
  • Upgrade notes preserve database migration, post-deploy migration, backup, and rollback requirements.
  • Any owned MFA validation code fails closed on forged or failed device responses and has regression tests.
  • Operator notes identify whether auth logs, active sessions, MFA devices, or credential exposure require human follow-up.

Output contract

  • Reviewer-ready PR upgrading controlled self-managed GitLab deployments to a patched supported version with aligned images, manifests, package pins, generated artifacts, SBOMs, and runbooks.
  • Upgrade notes preserving migration, post-deploy migration, backup, rollback, single-node/multi-node, and downtime requirements.
  • Safe version or MFA validation checks that avoid printing credential IDs, MFA material, auth tokens, user emails, or production auth logs.
  • TRIAGE.md when the affected instance, GitLab fork, deployment artifact, or operator follow-up is owned outside this repository.

Watch for

  • Updating a Helm value while Terraform, image digests, or an Omnibus package mirror still deploys a vulnerable GitLab version.
  • Treating GitLab Runner upgrades as the fix when the vulnerable surface is the GitLab application authentication service.
  • Skipping migration and backup notes for single-node self-managed instances.
  • Logging credential IDs or MFA device data while investigating the vulnerable window.
  • Disabling MFA or SSO temporarily without a documented, approved containment decision.

References