[013a]

This issue is incredibly strange and severe.

One thing I did notice, though: The timestamps on the Twitter DMs, which were used as evidence to assert that they're unresponsive in DMs, cover a time period of 90 minutes. The language the twitter client is set to is also not english (maybe French? the original discovery was made by someone who lives in France. I don't know), which introduces the possibility that it wasn't even daytime in the US when those were sent.

I'm all for publicly announcing these things (in a responsible way) and forcing a quicker response from the company, and its also likely that Troy tried to reach out on his own, but I just think that screenshot is a bad example of a company not responding to DMs. If it had been 48 hours to a week, then I'd be in the concerned camp.

[Arcuru]

The Twitter DMs are timestamped on September 23. Troy sent his public tweet on October 1.

[caperfee]

There is additional information in the post indicating that there was no adequate response to the original report even after 5 days:

The person who forwarded this vulnerability ... provided full details ... on September 24. ... after 5 days of waiting and not receiving a response, contacted me. He also shared a screenshot of his attempt to reach Grindr via Twitter DM

[thaumasiotes]

> This issue is incredibly strange and severe.

Severe, yes. It doesn't seem that strange.

You could have a flow like:

Reset page receives email address and passes it to some backend functionality. The backend checks whether the email address corresponds to an account on the site. It does, so the backend generates a reset token and emails it to the address on the affected account.

All of that is supposed to happen. What's also happening is that the reset token is being returned to the reset page, where the person requesting the reset can see it. This is very bad, but it seems likely to have come from some sort of automatic connect-your-frontend-pages-to-backend-services framework solution.