Tornado's October 2026 Security Update Explained: Keep the Event Loop Free

Every user of that process waits. The Tornado security update, version 6.6.0, fixes two bugs where crafted requests kept Tornado busy and stopped it from serving anyone else.

Tornado runs your app on one event loop. The loop is a single worker that switches between connections very quickly. That design handles thousands of open connections cheaply, but it has one rule: no single task may hold the loop for long.

Picture a common setup. A small team serves a live sales dashboard from two Tornado processes. A few hundred browser tabs keep WebSocket connections open all day; a WebSocket is a connection that stays open so the server can push new numbers. The setup is made up, but the risk is the one the advisories describe.

If one request keeps a process busy parsing, every tab on that process stops updating. The advisory says one body made of tiny chunks could hold a process for close to a minute. No password and no special page are needed, because the slow part runs before your own code.

Eight terms come up again and again. Each one is short to explain.

It is Tornado 6.6.0, published on PyPI on 21 October 2026, plus three GitHub advisories published the next day. Every Tornado version before 6.6 is listed as affected, and there is no 6.5.x patch release.

The release notes do not have a separate security section. The fixes sit under the module headings, such as tornado.http1connection and tornado.web, next to normal bug fixes and deprecations.

Because Tornado does its HTTP parsing on the same loop that serves every other connection. While the loop is inside the parser, it cannot read another socket, send a WebSocket message or run a timer.

Think of a single cashier at a busy shop counter. The cashier is the event loop, each customer is a connection, and checking a bill is parsing. If one customer hands over a bill that takes ten minutes to check, everyone behind waits. Where the picture breaks: a long bill takes time in step with its length, but folded headers grew much faster than their size.

Running more processes helps, because each has its own loop. It does not remove the problem: an attacker can send one slow request per process.

Anyone running a Tornado HTTP server older than 6.6 is affected by the header bug, because header parsing runs before any handler. The chunked-body bug needs a handler that reads the body, which most POST and PUT handlers do.

The chunked-body bug also affects Tornado's built-in HTTP client, which your code uses to fetch other sites. The advisory says SimpleAsyncHTTPClient, the default one, is affected when it reads a response from a malicious server.

Many people run Tornado without knowing it. On PyPI, jupyter-server, notebook and jupyterlab all list tornado 6.2.0 or newer as a dependency, and bokeh does too on normal platforms. Those minimums allow 6.6 but do not require it.

• A Jupyter server you open to a network is a Tornado server, so it needs the upgrade like any other.
• A Jupyter server bound to localhost on your own laptop is far less exposed, because strangers cannot reach it.
• An app behind a reverse proxy that buffers bodies and rejects folded headers keeps both slow inputs away from Tornado, per the advisory workarounds. Tornado itself is still unfixed.
• The open redirect only matters if your routes use RedirectHandler with a capture at the start of the target or in the host.

Upgrade to Tornado 6.6 or newer and check that the upgrade really happened. Then test for the behaviour changes listed later, in the section on what else changes in Tornado 6.6.

1. 1

   Check your Python version

   Run python --version. Tornado 6.6 needs Python 3.11 or newer. On 3.10 or older, plan the Python upgrade first.

2. 2

   Check your Tornado version

   Run python -c "import tornado; print(tornado.version)". Anything below 6.6 is affected by all three advisories.

3. 3

   Upgrade and pin

   Run pip install --upgrade "tornado>=6.6" and update the pin in your requirements or lock file. Putting the minimum in the pin makes pip fail loudly instead of quietly staying on 6.5.10.

4. 4

   Verify in the running environment

   Run the version check again inside the real container or virtual environment, not just on your laptop.

5. 5

   Check RedirectHandler routes

   Search your code for RedirectHandler. Make sure every target starts with a fixed prefix ending in a slash, before any captured value.

6. 6

   Run your tests

   Pay attention to streaming upload handlers, WebSocket origin checks and code that uses timeout=0 on Tornado queues. If you installed Tornado with conda, upgrade it with conda.

The Python check matters because pip skips any release that needs a newer Python. We asked pip which Tornado wheel it would pick for each Python version on 31 October 2026.

Much more. Each folded line was glued onto the end of the previous header value, so many short continuation lines made the work grow much faster than the input. The advisory calls it quadratic, written O(n squared): ten times more lines can mean about a hundred times more work.

The header size limit caps the damage. At the default limit, the advisory says each malicious request blocks the loop for tens of milliseconds, so it takes a stream of requests to hurt. If max_header_size was raised, one 1 MB request can block for several seconds.

This bug is a close cousin of CVE-2025-67725. That earlier fix covered many repeated headers with the same name, but not one header continued across many folded lines.

What the fix changed

Tornado 6.6 removed line folding completely. A header line that starts with a space or tab is now rejected. We parsed the same harmless folded header on both versions to see the change.

from tornado.httputil import HTTPHeaders, HTTPInputError

raw = "X-Note: first part\r\n  second part\r\nHost: localhost\r\n"
try:
    h = HTTPHeaders.parse(raw)
    print("accepted, X-Note =", repr(h["X-Note"]))
except HTTPInputError as e:
    print("rejected:", e)

RFC 9112, the current HTTP/1.1 standard, says senders must not generate folded headers, so mainstream clients should never trip this. A very old client or a hand-written script that relies on folding will now get an error instead of a joined value.

If you cannot upgrade yet, the section on waiting lists the advisory workarounds for this bug and the next one.

Tornado 6.5 processed every chunk that had already arrived in one go, without pausing for other connections. A body of millions of 1-byte chunks could hold the loop for close to a minute, according to the advisory.

Memory was a second problem. A handler without streaming kept each chunk as a separate Python object, which the advisory says used about 20 times as much memory as the bytes received.

What the fix changed

Tornado 6.6 now pauses to let other tasks run while it reads any body, joins small chunks before handing them over, and stores non-streaming bodies more compactly. Pausing only shares the loop; it does not make the attacker's request free. The request still uses CPU, and max_body_size caps how much.

The source shows how often it pauses. In tornado/http1connection.py, a counter adds the bytes read, plus 1,024 for every chunk header. When it reaches 262,144 (256 KiB), Tornado yields once with asyncio.sleep(0).

Streaming handlers no longer see chunk boundaries

This is the change most likely to surprise working code. A streaming handler is one marked with @stream_request_body. Tornado hands it the body in pieces through a method called data_received, instead of waiting for the whole body.

In 6.5, data_received was called once per HTTP chunk. In 6.6, small chunks that have already arrived are joined first, up to the 64 KiB chunk_size, so the split depends on network timing.

We sent the same request to both versions: a chunked body of 10 chunks, each 5 bytes, to a handler that records every data_received call.

If your code treated each call as one message, it will now see several messages glued together. Put your own message framing inside the body, such as newline-separated JSON, instead of relying on HTTP chunks.

RedirectHandler builds the target URL by putting parts of the request path into a template. If a captured part lands at the very start of the path, a request can turn the target into a link to another host.

A target that starts with two slashes, such as //example.com/destination, is a protocol-relative URL. The browser keeps the current scheme and goes to example.com, not to your site.

We ran a tiny local app with two rules on both versions. The first rule has the risky shape from the advisory; the second has a fixed prefix.

from tornado.web import Application, RedirectHandler

app = Application([
    # risky: the capture can become the start of the target path
    (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}),
    # safe shape: a fixed prefix ending in / comes before the capture
    (r"/old/(.*)", RedirectHandler, {"url": "/new/{0}"}),
])

In 6.6, RedirectHandler formats the template twice: once with the real values, and once with a plain slash in each slot. If the scheme or the host part differ, it returns 400; the host part includes any user name and port. A template can no longer put a captured value there on purpose.

Tornado 6.6 is a feature release, not a small patch, so it also removes old features and changes some defaults. These are the changes most likely to break working code, from the release notes.

The notes also list security hardening without its own advisory. WebSocket message receiving now yields to the loop, unanswered pings no longer grow memory without limit, and set_cookie max_age can no longer inject cookie attributes.

Zero timeouts now mean no waiting

Tornado queue and lock timeouts are deadlines, not seconds: an absolute loop time or a timedelta. In older versions, timeout=0 was treated like no timeout at all. In 6.6 it returns or raises straight away.

We ran Queue().get(timeout=0) on an empty queue, with a one-second outer limit.

The release notes list the lock methods, such as Event.wait, under the same change. In our run, Event().wait(timeout=0) already raised TimeoutError at once on 6.5.10, because Event checks for None while the others checked for a true value. Test the exact calls your code makes.

A new cross-origin protection setting

Tornado 6.6 adds a cross_origin_protection application setting that guards against cross-site requests. The notes say it is expected to become the default in Tornado 6.7, so it is worth trying now in a test environment.

Reduce the impact with the workarounds the advisories list, and set a date for the real upgrade. Size limits only shorten each stall. A proxy that rejects folded headers and buffers bodies keeps both attacks away from Tornado, but Tornado itself stays unfixed.

The default max_body_size falls back to the stream's buffer limit of 104,857,600 bytes, which is 100 MiB. The advisory says a body near that size could block a process for close to a minute. Set a lower max_body_size on the HTTPServer.

Per-handler limits need care. Header limits exist only on the server, because headers are parsed before routing. A handler can lower its body limit with self.request.connection.set_max_body_size() in prepare(), but only with @stream_request_body; other handlers have already read the body.

Check the installed version in the environment that serves traffic, then confirm one behaviour change. Expect these exact outputs.

python --version
# expect: Python 3.11.x or newer

python -c "import tornado; print(tornado.version)"
# expect: 6.6 (or a later version)

python -c "from tornado.httputil import HTTPHeaders as H; H.parse('A: b\r\n  c\r\n')"
# expect on 6.6: HTTPInputError: header line cannot start with whitespace, folding not supported

On 6.5.10 the last command prints nothing, because the folded header is accepted. Note that tornado.version prints 6.6, not 6.6.0. In scripts, compare tornado.version_info, which is (6, 6, 0, 0), instead of the string.

For containers, run the same commands with docker exec inside each running image. A laptop check only proves your laptop is fixed.

Use it as an example of why event-loop servers need limits on every piece of untrusted work, not only on your own handlers.

1. 1

   Name the model

   Tornado serves many connections from one event loop per process, so any long task blocks every connection on that process.

2. 2

   Name the inputs

   HTTP headers and request bodies are parsed before application code, so they are reachable without authentication.

3. 3

   Show the failure

   Folded headers cost quadratic CPU, and millions of tiny chunks were parsed without a pause. One chunked request could stall everyone for close to a minute.

4. 4

   Describe the fix

   Remove the risky feature, yield to the loop after a fixed amount of work, and join small chunks to cut overhead.

5. 5

   Add defence in depth

   Put a buffering reverse proxy in front, set header and body limits on the server, and run several processes.

6. 6

   Close with the redirect lesson

   Never let request data choose the host of a redirect; check the scheme and host after filling the template.