diff --git a/docs/releases/1.1.4.txt b/docs/releases/1.1.4.txt
new file mode 100644
index 0000000000..dbe91fb3e4
--- /dev/null
+++ b/docs/releases/1.1.4.txt
@@ -0,0 +1,78 @@
+==========================
+Django 1.1.4 release notes
+==========================
+
+Welcome to Django 1.1.4!
+
+This is the fourth "bugfix" release in the Django 1.1 series,
+improving the stability and performance of the Django 1.1 codebase.
+
+With one exception, Django 1.1.4 maintains backwards compatibility
+with Django 1.1.3, but contain a number of fixes and other
+improvements. Django 1.1.4 is a recommended upgrade for any
+development or deployment currently using or targeting Django 1.1.
+
+For full details on the new features, backwards incompatibilities, and
+deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`.
+
+Backwards-incompatible changes in 1.1.4
+=======================================
+
+CSRF exception for AJAX requests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Django includes a CSRF-protection mechanism, which makes use of a
+token inserted into outgoing forms. Middleware then checks for the
+token's presence on form submission, and validates it.
+
+Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
+requests, on the following basis:
+
+    * Many AJAX toolkits add an X-Requested-With header when using
+      XMLHttpRequest.
+
+    * Browsers have strict same-origin policies regarding
+      XMLHttpRequest.
+
+    * In the context of a browser, the only way that a custom header
+      of this nature can be added is with XMLHttpRequest.
+
+Therefore, for ease of use, we did not apply CSRF checks to requests
+that appeared to be AJAX on the basis of the X-Requested-With header.
+The Ruby on Rails web framework had a similar exemption.
+
+Recently, engineers at Google made members of the Ruby on Rails
+development team aware of a combination of browser plugins and
+redirects which can allow an attacker to provide custom HTTP headers
+on a request to any website. This can allow a forged request to appear
+to be an AJAX request, thereby defeating CSRF protection which trusts
+the same-origin nature of AJAX requests.
+
+Michael Koziarski of the Rails team brought this to our attention, and
+we were able to produce a proof-of-concept demonstrating the same
+vulnerability in Django's CSRF handling.
+
+To remedy this, Django will now apply full CSRF validation to all
+requests, regardless of apparent AJAX origin. This is technically
+backwards-incompatible, but the security risks have been judged to
+outweigh the compatibility concerns in this case.
+
+Additionally, Django will now accept the CSRF token in the custom HTTP
+header X-CSRFTOKEN, as well as in the form submission itself, for ease
+of use with popular JavaScript toolkits which allow insertion of
+custom headers into all AJAX requests.
+
+The following example using the jQuery JavaScript toolkit demonstrates
+this; the call to jQuery's ajaxSetup will cause all AJAX requests to
+send back the CSRF token in the custom X-CSRFTOKEN header::
+
+    $.ajaxSetup({
+        beforeSend: function(xhr, settings) {
+            if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
+                // Only send the token to relative URLs i.e. locally.
+                xhr.setRequestHeader("X-CSRFToken",
+                                     $("#csrfmiddlewaretoken").val());
+            }
+        }
+    });
+
diff --git a/docs/releases/index.txt b/docs/releases/index.txt
index b974a03c7a..a5d37edf14 100644
--- a/docs/releases/index.txt
+++ b/docs/releases/index.txt
@@ -21,6 +21,7 @@ Final releases
 .. toctree::
    :maxdepth: 1
 
+   1.1.4
    1.1.2
    1.1