django -- multiple vulnerabilities

The Django Project reports:

Host header poisoning
Some parts of Django – independent of end-user-written applications
– make use of full URLs, including domain name, which are generated
from the HTTP Host header. Some attacks against this are beyond Django’s
ability to control, and require the web server to be properly configured;
Django’s documentation has for some time contained notes advising users
on such configuration.
Django’s own built-in parsing of the Host header is, however, still
vulnerable, as was reported to us recently. The Host header parsing
in Django 1.3 and Django 1.4 – specifically, django.http.HttpRequest.get_host()
– was incorrectly handling username/password information in the header.
Thus, for example, the following Host header would be accepted by Django when
running on “validsite.com”:
Host: validsite.com:[email protected]
Using this, an attacker can cause parts of Django – particularly the
password-reset mechanism – to generate and display arbitrary URLs to users.
To remedy this, the parsing in HttpRequest.get_host() is being modified; Host
headers which contain potentially dangerous content (such as username/password
pairs) now raise the exception django.core.exceptions.SuspiciousOperation.

Documentation of HttpOnly cookie option
As of Django 1.4, session cookies are always sent with the HttpOnly flag, which
provides some additional protection from cross-site scripting attacks by denying
client-side scripts access to the session cookie.
Though not directly a security issue in Django, it has been reported that the
Django 1.4 documentation incorrectly described this change, by claiming that this
was now the default for all cookies set by the HttpResponse.set_cookie() method.
The Django documentation has been updated to reflect that this only applies to the
session cookie. Users of Django are encouraged to review their use of set_cookie()
to ensure that the HttpOnly flag is being set or unset appropriately.