It is not a bug, as such. The report is somewhat confused and slightly misleading.
WordPress does not use "sessions" and so it is not actually vulnerable to "session replay" attacks. In this sense, the report is incorrect.
Instead, the cookie sent to WordPress users has all the necessary information to identify and authenticate that user. So, it is potentially vulnerable to a different kind of attack known as a "cookie hijacking" attack.
The concern is that if somebody manages to steal your cookies, then they can login as you, for a little while. WordPress mitigates this risk in several ways.
First, the cookies contain a timeout as part of their content. They are only valid for the original time they were issued, and cannot be used indefinitely.
Second, the cookies used for administrative tasks are different than the cookies used for the "front end" of the site. Simply viewing your site and having the front-end cookie stolen is not enough to gain access to your site.
Fourth, if running over SSL, the SSL flag is set for cookies, meaning that they will only be delivered over encrypted connections.
In general, cookie hijacking is not a major concern. Other exploits are more common (with the most common being somebody simply finding out your password).
See, to successfully perform cookie hijacking, the attacker must be able to a) intercept your traffic and then b) use it within the limited time period that the cookie is valid (2 days by default). If this is a major concern for your situation, then using the "Admin over SSL" feature of WordPress will cause the admin cookies (the ones that let you do things) to be always encrypted. Additionally, changing the password of a user invalidates all their old cookies immediately, so that can be used to close any holes the instant an intrusion via this method is suspected.
More information about Admin over SSL can be found here:
WordPress is constantly looking for ways to improve security, and it is possible that as new attacks become known in the future, the core code will change to address these forms of attacks.
This particular issue, along with similar aspects, is being discussed publicly in this ticket: