Yes, this is a bug. Specifically, it is a type of session fixation vulnerability. The attack scenario looks like this:
- Person A uses a device (possibly a friend's phone, possibly a machine at an Internet cafe, whatever) to go to the target website W.
- Person A notes down the session token that the site generates for them.
- Person A gets off of that device, and person B (the device owner, or the next patron at the cafe, or whatever) takes over.
- Person B goes to the same site W, and logs in, so the session token is now associated with B's authenticated session.
- Person A uses the session token - which they noted while they had access to the device - to make requests to W in the context of B's authenticated session.
Person A is here able to hijack person B's session, remotely and after the fact.
Depending on whether or not the site changes the session token when a user ends their session, this could be even worse. In that scenario, an arbitrary number of users could all end up being compromised one after another.
It's fine to generate a pre-authentication session. That part isn't a bug, and indeed is useful for mitigating some vulnerabilities (such as login CSRF) as well as improving user experience. However, the session token MUST change every time a session changes from unauthenticated to authenticated, or from one authenticated user to another. It MAY also change any time the session changes from an authenticated session to an unauthenticated one, as a defense-in-depth measure.