# Dealing with a hacked user account should not require the console

**URL:** https://meta.discourse.org/t/dealing-with-a-hacked-user-account-should-not-require-the-console/398627
**Category:** Self-hosting
**Created:** [17 במרץ,‏ 2026,‏ 11:50am UTC](https://meta.discourse.org/t/dealing-with-a-hacked-user-account-should-not-require-the-console/398627 "2026-03-17T11:50:06Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![dccmuseum](https://avatars.discourse-cdn.com/v4/letter/d/8e8cbc/32.png) [@dccmuseum](https://meta.discourse.org/u/dccmuseum)
#### Post date: [17 במרץ,‏ 2026,‏ 11:50am UTC](https://meta.discourse.org/t/dealing-with-a-hacked-user-account-should-not-require-the-console/398627/1 "2026-03-17T11:50:06Z")

</div>

Hi all,

one of our users had their account compromised. The workflow to mitigate that was far from ideal.

The rails console was needed for:

- Force changing the e-mail address
- Force changing the password to something random to force a password reset via e-mail
- Killing all active sessions

Furthermore, we found that the e-mail change was only visible in the outbound e-mail logs and nowhere else.

The AI spam-detector caught that spam for new accounts, but wasn’t enabled for this trust level and number of posts. Maybe it would be a good idea to include the option to enable the AI spam-detector for changing countries and/or no post in over a year.

Thanks all for the great software over the years, despite minor flaws like this.

---

_[View the full topic](https://meta.discourse.org/t/dealing-with-a-hacked-user-account-should-not-require-the-console/398627)._
