<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-23T02:22:05.328245+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-114136</id>
    <title>fkie_cve-2026-114136</title>
    <updated>2026-10-23T02:22:05.347991+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Django REST framework is a toolkit for building Web APIs. From 3.6.4 until 3.18.2, JSONParser.parse in rest_framework/parsers.py uses the client-supplied Content-Type charset value with codecs.getreader, which accepts byte-transform codecs such as bz2_codec rather than only text encodings. A remote unauthenticated client can therefore cause a compressed JSON request body to be expanded after Django has enforced DATA_UPLOAD_MAX_MEMORY_SIZE against only the wire bytes, allowing a very small request to consume substantial per-worker memory. The default parser set is sufficient, and any reachable endpoint that accepts a JSON body is affected. This issue is fixed in version 3.18.2.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-114136"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-3547-9m27-7rxg</id>
    <title>GHSA-3547-9m27-7rxg — Django REST framework: JSONParser applies an attacker-named codec to the request stream</title>
    <updated>2026-10-23T02:22:05.348080+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: djangorestframework</p>
<p>### Summary</p>
<p>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.</p>
<p>### Details</p>
<p>`JSONParser.parse` decodes the request body with the charset the client supplied on the Content-Type
header:</p>
<p>```python
# rest_framework/parsers.py
encoding = parser_context.get('encoding', settings.DEFAULT_CHARSET)
try:
    decoded_stream = codecs.getreader(encoding)(stream)
    parse_constant = json.strict_constant if self.strict else None
    return json.load(decoded_stream, parse_constant=parse_constant)
except ValueError as exc:
    raise ParseError('JSON parse error - %s' % str(exc))
```</p>
<p>Of the roughly 455 codec names `codecs.lookup` resolves on CPython 3.14, about 18 are byte transforms
instead of character sets: `bz2_codec`, `zlib_codec`, `base64_codec`, `hex_codec`, `quopri_codec`,
`uu_codec` and similar. `codecs.getreader` is the only entry point in the `codecs` module that does
not consult `CodecInfo._is_text_encoding`, so it accepts all of them. Sending
`Content-Type: application/json; charset=bz2_codec` wraps the request stream in a bz2 decompressor
before…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-3547-9m27-7rxg"/>
  </entry>
</feed>
