I can reproduce this on recent nightly builds and default installation.

If I access http://foreman.example.com/, the server does NOT set a session cookie, then redirects the request to https://foreman.example.com/. The request to https://foreman.example.com/ sets the _session_id cookie with HttpOnly and no secure flag, then redirects the request to https://foreman.example.com/users/login.

It seems that any subsequent HTTP request, e.g. a user trying to return to the application by visiting http://foreman.example.com/ rather than https:// will result in the session cookie going over the wire under HTTP. The initial access to Foreman doesn't appear to send it over HTTP at any point.

Our older fixes for session fixation problems under CVE-2014-0090 don't really help mitigate this new issue, as the privileged session ID can be leaked over an HTTP request.

In Foreman 1.8, there is an additional "timezone" cookie that is also set without the secure or HttpOnly flags, but only contains a string such as "Europe/London".

In all versions, a _ForemanSelectedhosts cookie can be set by ticking some checkboxes in the UI host list. This contains a JSON array of host IDs that the user has selected. It's set from JavaScript rather than the HTTP request, and does not have the secure flag.

Both extra cookies would have negligible impact from a leak I think, but if the HTTP response could be intercepted and a different value set, it could cause a minor inconvenience for the user.