Trac was not configured with usernames + passwords directly stored in the database, however, Trac stores “session information” in the database.
The session table looks like this (X’s added for obvious reasons)
sid | authenticated | last_visit
XXXXXX1ccXX5ae | 0 | 15295XXXX
XXXXXX889XXX3e6 | 0 | 15295XXXX
XXXXXX8af7XX9e50 | 0 | 15295XXXX
MrUsername | 1 | 14467XXXX
Those seem like users navigating the site, unauthenticated shows a random id, while authenticated show a username.
That table isn’t too bad, but we have another table named “session_attribute” which has all the sessions and their actions. These are the actions of anonymous users (not so bad), but also the actions of authenticated users. In the example below, a new user had a verification email sent to them to register a new account:
myusername | 1 | email_verification_sent_to | firstname.lastname@example.org
I’m not 100% sure on how far these session tables go back, in theory, sessions should be cleared out, but Trac seems to preserve them indefinitely for some reason.
Direct emails were only sent to those individuals where password hash information was leaked along with emails or usernames since that is a sizeable breach of PII (Personally Identifiable Information) which could be exploited. I’m depending on public notifications for everything else (mostly what was leaked from Trac).
I should take a moment to mention that Trac has a LARGE number of fake spam accounts (and fake spam session data) stored in it. A lot of the data within the session table is completely and absolutely fake that was populated by spammers over years.