GHSA-35W3-PJM6-WJ95

Vulnerability from github – Published: 2026-06-19 19:36 – Updated: 2026-06-19 19:36
VLAI
Summary
Oj: Heap Buffer Overflow in Oj.dump Exception Serialization via Large Indent
Details

Summary

Oj.dump in object mode is vulnerable to a heap buffer overflow when serializing Exception objects with a large :indent value. The serializer allocates a buffer sized for the object's attributes but does not account for the indent bytes added on each write. With indent: 5000, the accumulation of 5,000-byte indent strings overflows the 13,150-byte heap allocation, corrupting adjacent heap memory.

Version

  • Software: oj gem
  • Affected: all versions with ext/oj/dump.h
  • Latest tested: 3.17.1 (confirmed present)

Details

ext/oj/dump.h, line 75–77:

static void fill_indent(Out out, int depth) {
    if (0 < out->opts->indent) {
        memset(out->buf + out->cur, ' ', (size_t)(out->opts->indent * depth));

When dumping an Exception object in :object mode, dump_obj_attrs calls fill_indent repeatedly for each attribute. The buffer is pre-allocated based on the serialized content but not the indentation overhead. With indent: 5000 the indent block for a nested object exceeds the remaining buffer space, producing a heap-buffer-overflow of size 5,000 at the end of the allocated region.

ASAN report:

==101656==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x527000022c5e
WRITE of size 5000 at 0x527000022c5e thread T0
    #0 memset
    #1 fill_indent       /ext/oj/dump.h:77
    #2 dump_obj_attrs    /ext/oj/dump_object.c:552
    #3 dump_obj          /ext/oj/dump_object.c:80
    #4 oj_dump_obj_val   /ext/oj/dump_object.c:708
    #5 oj_dump_obj_to_json_using_params  /ext/oj/dump.c:817
    #6 dump_body         /ext/oj/oj.c:1429
    #7 dump              /ext/oj/oj.c:1480
0x527000022c5e is located 0 bytes after 13150-byte region [0x52700001f900, 0x527000022c5e)

Reproduce

require "oj"
obj = Oj.load('{"^o":"RuntimeError"}', mode: :object)
Oj.dump(obj, mode: :object, indent: 5000)

Workarounds

This is at the discretion of the developer and not a public facing option so the workaround is the develop should not use extreme indents and should not offer the option for users to dump Ruby data with unlimited indentation size.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.17.2"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "oj"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.17.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54896"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-122"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:36:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`Oj.dump` in object mode is vulnerable to a heap buffer overflow when serializing Exception objects with a large `:indent` value. The serializer allocates a buffer sized for the object\u0027s attributes but does not account for the indent bytes added on each write. With `indent: 5000`, the accumulation of 5,000-byte indent strings overflows the 13,150-byte heap allocation, corrupting adjacent heap memory.\n\n### Version\n\n- **Software**: oj gem\n- **Affected**: all versions with `ext/oj/dump.h`\n- **Latest tested**: 3.17.1 (confirmed present)\n\n### Details\n\n`ext/oj/dump.h`, line 75\u201377:\n\n```c\nstatic void fill_indent(Out out, int depth) {\n    if (0 \u003c out-\u003eopts-\u003eindent) {\n        memset(out-\u003ebuf + out-\u003ecur, \u0027 \u0027, (size_t)(out-\u003eopts-\u003eindent * depth));\n```\n\nWhen dumping an Exception object in `:object` mode, `dump_obj_attrs` calls `fill_indent` repeatedly for each attribute. The buffer is pre-allocated based on the serialized content but not the indentation overhead. With `indent: 5000` the indent block for a nested object exceeds the remaining buffer space, producing a heap-buffer-overflow of size 5,000 at the end of the allocated region.\n\nASAN report:\n```\n==101656==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x527000022c5e\nWRITE of size 5000 at 0x527000022c5e thread T0\n    #0 memset\n    #1 fill_indent       /ext/oj/dump.h:77\n    #2 dump_obj_attrs    /ext/oj/dump_object.c:552\n    #3 dump_obj          /ext/oj/dump_object.c:80\n    #4 oj_dump_obj_val   /ext/oj/dump_object.c:708\n    #5 oj_dump_obj_to_json_using_params  /ext/oj/dump.c:817\n    #6 dump_body         /ext/oj/oj.c:1429\n    #7 dump              /ext/oj/oj.c:1480\n0x527000022c5e is located 0 bytes after 13150-byte region [0x52700001f900, 0x527000022c5e)\n```\n\n### Reproduce\n\n```ruby\nrequire \"oj\"\nobj = Oj.load(\u0027{\"^o\":\"RuntimeError\"}\u0027, mode: :object)\nOj.dump(obj, mode: :object, indent: 5000)\n```\n\n### Workarounds\n\nThis is at the discretion of the developer and not a public facing option so the workaround is the develop should not use extreme indents and should not offer the option for users to dump Ruby data with unlimited indentation size.",
  "id": "GHSA-35w3-pjm6-wj95",
  "modified": "2026-06-19T19:36:47Z",
  "published": "2026-06-19T19:36:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ohler55/oj/security/advisories/GHSA-35w3-pjm6-wj95"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ohler55/oj"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Oj: Heap Buffer Overflow in Oj.dump Exception Serialization via Large Indent"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…