{"id":"CVE-2026-72854","aliases":["AZL-97458","AZL-97512","AZL-97515","DEBIAN-CVE-2026-72854","EUVD-2026-63537","GHSA-p5jw-mm77-f8jp","MGASA-2026-0533","SUSE-SU-2026:23630-1","UBUNTU-CVE-2026-72854","openSUSE-SU-2026:11672-1","openSUSE-SU-2026:21768-1"],"status":"published","title":"msgpack-c Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized Reservation","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","severity":{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00157,"percentile":0.04881,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-190","CWE-787"],"published":"2026-08-20T18:19:24Z","modified":"2026-11-05T05:40:51Z","fixes":[{"ecosystem":"Debian:14","package":"msgpack-c","fixed_in":["7.0.2-1"],"sources":["osv"]},{"ecosystem":"Mageia:10","package":"msgpack","fixed_in":["6.1.0-2.1.mga10"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"msgpack-c","fixed_in":["7.0.2-160000.1.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"msgpack-c","fixed_in":["7.0.2-160000.1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"msgpack-c","fixed_in":["7.0.2-2.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 16.0","package":"msgpack-c","fixed_in":["7.0.2-160000.1.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:3","package":"fluent-bit","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.1.10-8"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"lttng-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.13.11-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"msgpack","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.3.0-1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.0.0-3","6.0.0-1","6.0.0-2","6.0.0-3","6.0.0-4","6.0.0-5","6.0.1-1","6.0.1-2","6.0.1-3","6.1.0-1","6.1.0-2","7.0.1-1","7.0.2-1"]},{"source":"osv","ecosystem":"Debian:13","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.0.1-3","6.1.0-1","6.1.0-2","7.0.1-1","7.0.2-1"]},{"source":"osv","ecosystem":"Debian:14","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.2-1"}]}],"versions":["6.0.1-3","6.1.0-1","6.1.0-2","7.0.1-1"]},{"source":"osv","ecosystem":"Mageia:10","package":"msgpack","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.0-2.1.mga10"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.2-160000.1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.2-160000.1.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.1.5-1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.0.1-3"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.3.0-4"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.0.0-3","4.0.0-3build1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.1.0-2","7.0.1-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.0.1-3","6.1.0-2"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.2-2.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"msgpack-c","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.2-160000.1.1"}]}]}],"products":[{"vendor":"msgpack","product":"msgpack-c"}],"references":[{"url":"https://github.com/msgpack/msgpack-c/issues/1181","tags":["issue-tracking","exploit","report"]},{"url":"https://github.com/msgpack/msgpack-c/blob/c-7.0.1/src/unpack.c#L429-L502","tags":["technical-description","article"]},{"url":"https://github.com/msgpack/msgpack-c/blob/c-7.0.1/include/msgpack/unpack.h#L219-L223","tags":["technical-description","article"]},{"url":"https://github.com/msgpack/msgpack-c/blob/c-7.0.1/example/lib_buffer_unpack.c","tags":["technical-description","article"]},{"url":"https://github.com/msgpack/msgpack-c","tags":["product","package"]},{"url":"https://www.vulncheck.com/advisories/msgpack-c-integer-overflow-in-msgpack-unpacker-expand-buffer-causes-a-false-success-undersized-reservation","tags":["third-party-advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72854","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-p5jw-mm77-f8jp"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72854.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-72854","tags":["advisory"]},{"url":"https://advisories.mageia.org/MGASA-2026-0533.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=36268","tags":["report"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/BFF3NBEPXVQG2XOYDOERS7TLEDPUIP5O/","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623630-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1275911","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-72854","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-72854","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-72854","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-72854","title":"msgpack-c Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized Reservation","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T18:19:24.266Z","modified":"2026-09-24T14:19:03.146Z","cvss":[{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"},{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T14:19:51.663093Z"}],"euvd":[{"id":"EUVD-2026-63537","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T18:19:24Z","modified":"2026-09-24T14:19:03Z","cvss":[{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T17:27:58.186745Z"}],"ghsa":[{"id":"GHSA-p5jw-mm77-f8jp","title":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public...","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T21:31:28Z","modified":"2026-08-20T21:31:36Z","cvss":[{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"},{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"medium"}],"cwes":["CWE-190"],"updated_at":"2026-11-02T15:10:48.274578Z"}],"nvd":[{"id":"CVE-2026-72854","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:01.04Z","modified":"2026-10-18T20:10:00.11Z","cvss":[{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"},{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"medium","assessor":"primary"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T14:12:40.302911Z"}],"osv":[{"id":"CVE-2026-72854","title":"msgpack-c Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized Reservation","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T18:19:24.266Z","modified":"2026-10-28T02:30:54.369121032Z","cvss":[{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T15:45:15.88521Z"},{"id":"DEBIAN-CVE-2026-72854","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:01.04Z","modified":"2026-10-23T17:47:30.462805176Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"medium"}],"updated_at":"2026-11-02T15:46:02.499355Z"},{"id":"UBUNTU-CVE-2026-72854","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:00Z","modified":"2026-10-17T13:00:53.0475974Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"medium"},{"version":"4.0","score":5.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:57:08.628462Z"},{"id":"AZL-97458","title":"CVE-2026-72854 affecting package fluent-bit 3.1.10-8","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:01Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:26.280152Z"},{"id":"AZL-97512","title":"CVE-2026-72854 affecting package lttng-tools 2.13.11-1","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:01Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:26.280152Z"},{"id":"AZL-97515","title":"CVE-2026-72854 affecting package msgpack 3.3.0-1","description":"msgpack_unpacker_expand_buffer in src/unpack.c, reached through the public msgpack_unpacker_reserve_buffer API, computes its new buffer size using an unchecked size_t addition of the requested size and the amount already used. The doubling loop guards its own multiplication against overflow, but the addition in the loop condition is unguarded, so a request near SIZE_MAX wraps: the loop condition is already satisfied, the allocation is performed at the small pre-wrap size, and the function returns true. The caller is told the requested capacity was reserved when it was not, so a subsequent write of the requested length overflows the heap buffer. The library's own example/lib_buffer_unpack.c demonstrates the reserve-then-write pattern, and its defensive assert comparing capacity against the request is compiled out under NDEBUG. msgpack-c's own decode entry points do not derive the reservation size from untrusted input, so reaching this requires an integration that passes an attacker-influenced length to the reservation API, such as a length-prefixed streaming transport.","status":"published","published":"2026-08-20T19:17:01Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:26.280152Z"},{"id":"MGASA-2026-0533","title":"Updated msgpack package fixes a security vulnerability","description":"Integer Overflow in msgpack_unpacker_expand_buffer Causes a\nFalse-Success Undersized Reservation. (CVE-2026-72854)\n","status":"published","published":"2026-10-23T05:45:46Z","modified":"2026-10-23T06:01:12.69127586Z","updated_at":"2026-11-02T15:49:43.795591Z"},{"id":"openSUSE-SU-2026:11672-1","title":"libmsgpack-c2-7.0.2-2.1 on GA media","description":"These are all security issues fixed in the libmsgpack-c2-7.0.2-2.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-09-02T00:00:00Z","modified":"2026-09-03T10:00:08.668887094Z","updated_at":"2026-11-02T16:58:39.516824Z"},{"id":"openSUSE-SU-2026:21768-1","title":"Security update for msgpack-c","description":"This update for msgpack-c fixes the following issue:\n\nUpdate to release 7.0.2:\n\n- CVE-2026-72854: Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized\n  Reservation (bsc#1275911).\n","status":"published","published":"2026-09-06T16:46:14Z","modified":"2026-09-09T18:23:14.674479247Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23630-1","title":"Security update for msgpack-c","description":"This update for msgpack-c fixes the following issue:\n\nUpdate to release 7.0.2:\n\n- CVE-2026-72854: Integer Overflow in msgpack_unpacker_expand_buffer Causes a False-Success Undersized\n  Reservation (bsc#1275911).\n","status":"published","published":"2026-09-06T16:45:50Z","modified":"2026-09-29T18:23:10.288701341Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}