That was actually the part where they partially mitigated the vulnerability with. So before it was more insecure. The green one is the &quot;fix&quot; :)<p>The constant time comparison is pretty irrelevant here. Check <a href="https:&#x2F;&#x2F;github.com&#x2F;haiwen&#x2F;seahub&#x2F;commit&#x2F;7cdb70368aa7acbf05461e22e83278b00c2036c8#diff-31b2676ed825badbf63e5be98fb54c25R68" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;haiwen&#x2F;seahub&#x2F;commit&#x2F;7cdb70368aa7acbf0546...</a>, basically a valid password reset token in default Django requires an attacker to know:<p>- Primary Key of the user (User ID)<p>- Hashed version of the user password<p>- Timestamp of the last login (1 second accuracy)<p>- Number of days since 2001-1-1 converted to base 36<p>- The configured SECRET_KEY<p>Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.<p>However, Seafile has removed the hashed password out of their version of &quot;tokens.py&quot;. This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (<a href="https:&#x2F;&#x2F;github.com&#x2F;haiwen&#x2F;seahub&#x2F;blob&#x2F;b6f8935c0f355cc70145f9c2706cc99512e39ac2&#x2F;tools&#x2F;secret_key_generator.py" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;haiwen&#x2F;seahub&#x2F;blob&#x2F;b6f8935c0f355cc70145f9...</a>)<p>Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (<a href="https:&#x2F;&#x2F;seacloud.cc&#x2F;group&#x2F;3&#x2F;wiki&#x2F;whats-new-in-the-next-version-4-3&#x2F;" rel="nofollow">https:&#x2F;&#x2F;seacloud.cc&#x2F;group&#x2F;3&#x2F;wiki&#x2F;whats-new-in-the-next-versi...</a>) but that&#x27;s not really a good way to spread awareness…