Predictable reset tokens enable Chamilo account takeover

TL;DR — Chamilo LMS password resets can be forged because reset tokens are derived from sha1(email) with no expiration, enabling unauthenticated account takeover when an attacker knows a victim’s email.

What happened

Chamilo LMS is a web-based learning management system (LMS) used to deliver and manage courses. CVE-2026-33707 describes a critical weakness in Chamilo’s default password recovery flow where password reset tokens are generated deterministically as sha1(email) with no random component, no expiration, and no rate limiting, allowing an attacker who knows a user’s email to compute the reset token and change the victim’s password without authentication.

Per the GitHub Security Advisory referenced by the CVE record, the affected logic is in main/inc/lib/login.lib.php, and the reset URL format is lostPassword.php?reset={SHA1_OF_EMAIL}&id={USER_ID}. The advisory also notes this vulnerable path is active by default when the user_reset_password setting is 'false' (the default in main/install/data.sql).

This is a high-impact failure mode because password reset endpoints are internet-facing in many deployments and are frequently the easiest route to full account takeover. Deterministic, non-expiring reset tokens are especially dangerous because they can remain exploitable indefinitely and can be chained with any email disclosure / user enumeration weakness.

Who is impacted

• Deployments running Chamilo LMS versions marked as affected in the CVE record: chamilo/chamilo-lms < 1.11.38 or >= 2.0.0-alpha.1, < 2.0.0-RC.3.
• Any instance using the default password reset mechanism described in the advisory (token derived from sha1(email)), particularly where user emails are guessable or discoverable.
• Environments where compromised student/teacher/admin accounts are high-impact (grade data, user PII, course content, integrations, API tokens).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Patched versions 1.11.38, 2.0-RC.3"

• Inventory Chamilo instances and confirm deployed versions against the affected ranges listed in the CVE record.
• Validate which password reset path is active in your deployment (the linked advisory calls out a legacy/default reset path controlled by the user_reset_password setting).
• Treat this as a credential-compromise risk:
  • Review logs/telemetry around password reset requests and unexpected password changes.
  • If suspicious activity is found, rotate credentials and invalidate active sessions/tokens accessible to compromised accounts (where operationally feasible).