Gitlab password reset bug leaves more than 5.3K servers up for grabs

Original Article ↗ Hacker News Discussion ↗

A critical GitLab vulnerability (CVE-2023-7028) allowed attackers to trigger password reset emails to both a victim’s address and their own by abusing how the Rails-based application handled multiple email parameters, potentially exposing thousands of self-hosted servers. Commenters use the case to highlight longstanding pitfalls in email-based password recovery, type-unsafe web frameworks, and rushed feature development, while emphasizing mitigations such as strict backend validation, VPN-only access, SSO, and mandatory 2FA.

Exploit mechanics and root cause

  • Core bug: the password reset endpoint accepted multiple email parameters (an array).
  • GitLab looked up a user by one email but then sent reset codes to all supplied addresses, including attacker-controlled ones.
  • Example payload: user[email][][email protected]&user[email][][email protected].
  • Fix: send reset instructions using the email stored on the user record, not the user-supplied value, and fetch addresses from the “recoverable” object itself.
  • The feature “RecoverableByAnyEmail” (originally meant for any/any verified email) is seen as conceptually dangerous, and its naming drew criticism.

Password reset and account identifier design

  • Many see email-based reset flows as “terrifying” and a long-standing bug magnet, especially around “associate secondary email” features.
  • Recommended design: treat account ID and email as distinct; use account ID internally and only derive email from the database, never from request parameters.
  • Some suggest usernames or requiring both username and email for recovery; others note usability trade-offs and user dislike of more friction.
  • Email aliases (+tag) can help obscure real identifiers but can create UX and collision issues when services canonicalize addresses differently than mail providers.

Email as a weak security channel

  • Email is criticized as insecure: easy to forward or leak tokens, partial and inconsistent sender validation, no default end-to-end encryption, ambiguous canonicalization, and heavy dependency on the security of one inbox.
  • If an email account or its domain is hijacked or re-registered, many linked services become trivially compromisable.
  • Some want the option to require multiple factors for reset (e.g., email + SMS), but report this is rarely supported.

GitLab’s security and engineering quality

  • Views diverge:
    • One side argues critical bugs are inevitable even with strong security teams, and GitLab’s openness makes issues more visible.
    • Others see repeated high-impact CVEs, rushed feature delivery, painful upgrades, and long-standing CI/UX bugs as signs of weak engineering culture or under-resourcing.

Language/framework and design debates

  • Several blame Rails/Ruby’s flexible parameter handling (arrays vs scalars) and “clever” abstractions.
  • Others counter that similar logic bugs occur in statically typed stacks (Java/C#) and that no mainstream ecosystem has a clean security record.
  • Stronger typing and safer APIs (e.g., Django’s getlist, typed query builders) are cited as ways to turn some logic errors into compile-time failures.

Operational mitigations and deployment practices

  • Many argue GitLab should not be directly exposed to the public internet; instead, place it behind VPN/SSO, use 2FA, and integrate with corporate identity (e.g., AD).
  • Some report that 2FA and limited external exposure mitigated this incident for them.
  • Others note that automated, frequent GitLab updates (e.g., via containers and tools like Watchtower) can reduce the attack window, and question why so many instances remain outdated.