Live › vulnerability › CVE-2026-114613
Go to dashboardPrior to 1.2.3, the msgpack-python C extension leaks a decoded map value when strict_map_key=True rejects a key, which is the default. Repeated malformed MessagePack input makes process memory grow without bound, causing denial of service in applications that deserialize attacker-controlled data.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that call msgpack unpackb() or the Unpacker streaming API on data an outside party can send, such as API request bodies, message queues or cache entries written by untrusted clients. Services that only deserialize data they produced themselves are much less exposed. The pure-Python fallback did not show the leak in the reported tests.
No product ranges from the sources yet.
python -c "import msgpack; print(msgpack.version)" and compare against 1.2.3python -c "import msgpack._cmsgpack" succeeds when it is installed1.2.3 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
MessagePack is the serializer implementation for Python msgpack.org. Prior to 1.2.3, the msgpack-python C extension (msgpack._cmsgpack) leaks a decoded map value when deserialization rejects a key with strict_map_key=True (the default). Repeated malformed inputs can cause unbounded process memory growth and denial of service in applications that deserialize attacker-controlled MessagePack data. Both unpackb() and the streaming Unpacker API are affected. The pure-Python fallback does not exhibit this leak in the reported tests. This issue is fixed in version 1.2.3.
This page as .md · .json · in your agent: get_signal("CVE-2026-114613")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.