Django REST framework is a toolkit for building Web APIs. Prior to 3.18.2, DefaultContentNegotiation.get_accept_list in rest_framework/negotiation.py accepts an unbounded number and aggregate size of Accept tokens, while select_renderer in that file repeatedly invokes _MediaType parsing from rest_framework/utils/mediatypes.py for each attacker-controlled token, every renderer, and forced 406 renegotiation. A remote unauthenticated client can send many distinct media types containing large quoted parameter values with numerous semicolons, causing Django's parameter parser and DRF's repeated parsing structure to consume disproportionate CPU. Requests to any reachable endpoint can pin synchronous workers for prolonged periods, and concurrent requests can make the service unavailable until the requests stop. This issue is fixed in version 3.18.2.

The version of FreeBSD installed on the remote host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the b0395fb0-d45c-11f1-985e-901b0edee044 advisory.

    Bruno Alla reports:
    An unauthenticated attacker can defeat Django's             DATA_UPLOAD_MAX_MEMORY_SIZE limit and force a worker process to allocate             arbitrary memory, by naming a compression codec in the Content-Type charset             parameter. A 108-byte request body produces a 50,331,648-character value inside             the view, an amplification factor of 466,033, and grows process peak RSS by             about 97 MiB. No application configuration is required beyond DRF's default             parser set; the endpoint only has to accept a JSON body.
    Deleting an authentication token through TokenProxy silently             deletes nothing. The call raises no exception and reports success, the database             row survives, and the token keeps authenticating. Any application, admin             integration or operational script that revokes credentials by calling             .delete() on a TokenProxy instance believes it has revoked a token that is             still live.
    DRF's content negotiation parses each Accept token several times per             request and never limits the number of tokens or their total size. Each parse             ends up in Django's parse_header_parameters, which takes quadratic time when a             quoted parameter value is packed with semicolons. On my machine a single GET             with a 780KB Accept header made of 96 such tokens kept one gunicorn worker busy             for 18.87 seconds (Django 6.1, djangorestframework 3.18.0, gunicorn 26.0.0,             Python 3.13, Docker on macOS). The header is syntactically valid, fits inside             gunicorn's default header limits, and needs no authentication. Two concurrent             requests, which is one per sync worker, made a default two worker deployment             stop answering for my whole 40 second test window. It recovered half a second             after I stopped sending.

Tenable has extracted the preceding description block directly from the FreeBSD security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Django REST framework is a toolkit for building Web APIs. Prior to 3.18.2,     DefaultContentNegotiation.get_accept_list in rest_framework/negotiation.py accepts an unbounded number and     aggregate size of Accept tokens, while select_renderer in that file repeatedly invokes _MediaType parsing     from rest_framework/utils/mediatypes.py for each attacker-controlled token, every renderer, and forced 406     renegotiation. A remote unauthenticated client can send many distinct media types containing large quoted     parameter values with numerous semicolons, causing Django's parameter parser and DRF's repeated parsing     structure to consume disproportionate CPU. Requests to any reachable endpoint can pin synchronous workers     for prolonged periods, and concurrent requests can make the service unavailable until the requests stop.
    This issue is fixed in version 3.18.2. (CVE-2026-114138)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Django REST framework is a toolkit for building Web APIs. Prior to 3.18.2,
    DefaultContentNegotiation.get_accept_list in rest_framework/negotiation.py accepts an unbounded number and
    aggregate size of Accept tokens, while select_renderer in that file repeatedly invokes _MediaType parsing
    from rest_framework/utils/mediatypes.py for each attacker-controlled token, every renderer, and forced 406
    renegotiation. A remote unauthenticated client can send many distinct media types containing large quoted
    parameter values with numerous semicolons, causing Django's parameter parser and DRF's repeated parsing
    structure to consume disproportionate CPU. Requests to any reachable endpoint can pin synchronous workers
    for prolonged periods, and concurrent requests can make the service unavailable until the requests stop.
    This issue is fixed in version 3.18.2. (CVE-2026-114138)

ID	Name	Product	Family	Type	Severity
374539	FreeBSD : py-djangorestframework -- Multiple vulnerabilities (b0395fb0-d45c-11f1-985e-901b0edee044)	Nessus	FreeBSD Local Security Checks	Local	high
370986	Linux Distros Unpatched Vulnerability : CVE-2026-114138	Nessus	Misc.	Local	high
476830	SCA: security update for djangorestframework (GHSA-33wh-fxxf-88vv)	Tenable Cloud Security	SCA Checks	Local	high
476830	SCA: security update for djangorestframework (GHSA-33wh-fxxf-88vv)	Tenable Self-Hosted Container Security	SCA Checks	Local	high

Detections

Analytics

CVE-2026-114138

high

Tenable Plugins

high

high

high

high