Out-of-memory when reading a HTTP response with large Content-Length

http.client.HTTPResponse.read() (without argument) consumes the amount of memory specified by the value of the Content-Lenght header in the response before starting receiving the data from the socket. Normally, if the server does not send enough data, the client gets IncompleteRead error, but if Content-Lenght is too large, it can consume a large amount of memory and CPU time and cause swapping. Therefore, a maleficent server can cause a DOS attack on client by sending a small response.

Linked PRs

gh-119451: Fix a potential denial of service in http.client (GH-119454)

pythongh-119451: Fix a potential denial of service in http.client (py…

[3.14] gh-119451: Fix a potential denial of service in http.client (G…

The CVE assigned is CVE-2025-13836

[3.13] gh-119451: Fix a potential denial of service in http.client (G…

pythongh-119451: Fix a potential denial of service in http.client (py…

lang/python314: security update to 3.14.2

[3.12] gh-119451: Fix a potential denial of service in http.client (G…

I know those versions are no longer supported, but AFAICT, releases older than 3.10.0a1 are not vulnerable. It seems that this vulnerability is the result of this performance improvement: 152f0b8

It would be great if somebody could confirm this and reflect that fact in vulnerability databases.

They are vulnerable. bytearray(amt) allocates a large buffer and fills it with zeros before reading even started.

Thanks for the quick response. What you've said is true but amt is the amount of data requested by the user/client, not the amount of data in content-length header coming from server.

The following code is from 3.9.25:

    def read(self, amt=None):
        if self.fp is None:
            return b""

        if self._method == "HEAD":
            self._close_conn()
            return b""

        if amt is not None:
            # Amount is given, implement using readinto
            b = bytearray(amt)
            n = self.readinto(b)
            return memoryview(b)[:n].tobytes()
        else:
            # Amount is not given (unbounded read) so we must check self.length
            # and self.chunked

            if self.chunked:
                return self._readall_chunked()

            if self.length is None:
                s = self.fp.read()
            else:
                try:
                    s = self._safe_read(self.length)
                except IncompleteRead:
                    self._close_conn()
                    raise
                self.length = 0
            self._close_conn()        # we read everything
            return s

If user requests a huge amount of data, bytearray(amt) allocates memory for them. But this vulnerability is about an unreasonable huge number in content-length response headers coming from server.
If amt is not specified and self.length coming from content-length header is, read function calls _safe_read and that reads the response chunk by chunk with a limit:

    def _safe_read(self, amt):
        """Read the number of bytes requested, compensating for partial reads.

        Normally, we have a blocking socket, but a read() can be interrupted
        by a signal (resulting in a partial read).

        Note that we cannot distinguish between EOF and an interrupt when zero
        bytes have been read. IncompleteRead() will be raised in this
        situation.

        This function should be used when <amt> bytes "should" be present for
        reading. If the bytes are truly not available (due to EOF), then the
        IncompleteRead exception can be used to detect the problem.
        """
        s = []
        while amt > 0:
            chunk = self.fp.read(min(amt, MAXAMOUNT))
            if not chunk:
                raise IncompleteRead(b''.join(s), amt)
            s.append(chunk)
            amt -= len(chunk)
        return b"".join(s)

Am I wrong here?

You are right, but the _safe_read() code was changed not in 152f0b8 (bpo-41002), but in d6bf6f2 (bpo-36050). This is 3.8.0a4.

Hmm, it seems to be more complex. AFAICT, 3.6 is not vulnerable, 3.8 is vulnerable, 3.9 is not, and 3.10+ are vulnerable again.

It may have been missed, but NIST have set a base score of 9.1 and flagged as a Critical vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2025-13836

00472: CVE-2025-13836

[3.10] gh-119451: Fix a potential denial of service in http.client (G…

[3.11] gh-119451: Fix a potential denial of service in http.client (G…

00472: CVE-2025-13836

CVE-2025-13836 python/cpython#119451

lang/python314: security update to 3.14.2

[H p] Fix: OutOfMemory error in mirror Lambda function (#7730)

[H R] Fix: OutOfMemory error in mirror Lambda function (#7730)

[CVE-2025-13836] Fix a potential denial of service in http.client

CVE-2025-13836 python/cpython#119451

[3.10] pythongh-119451: Fix a potential denial of service in http.cli…

Navigation Menu

Repository navigation

Out-of-memory when reading a HTTP response with large Content-Length #119451

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Out-of-memory when reading a HTTP response with large Content-Length #119451

Description

Linked PRs

Activity

z00z00z00 commented on Dec 3, 2025

frenzymadness commented on Jan 13, 2026

serhiy-storchaka commented on Jan 13, 2026

frenzymadness commented on Jan 13, 2026

serhiy-storchaka commented on Jan 13, 2026

frenzymadness commented on Jan 14, 2026

antdking commented on Jan 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions