rustsec-2026-0235
Vulnerability from osv_rustsec
Published
2026-05-13 12:00
Modified
2026-08-04 09:27
Summary
Insufficient archive validation can cause out-of-bounds reads in archives containing Rc/Arc
Details

Shared pointer validation keyed already-validated pointees by their address and type, but did not include pointer metadata. For unsized pointees, an archive could therefore contain multiple Rc, Arc, or weak pointers that shared a data address but used different metadata, such as different slice lengths.

Once the first pointer had been validated, later pointers to the same address skipped pointee validation. The safe checked rkyv::access API could consequently return a slice with a forged length, allowing safe indexing to read out of bounds. The same validation bypass was reachable through checked deserialization with rkyv::from_bytes.

Version 0.8.17 includes pointer metadata in shared pointer validation and rejects conflicting metadata. The 0.7 series is also affected but is no longer supported by upstream. Users who process untrusted archives should upgrade to 0.8.17 or later.


{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "memory-exposure"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rkyv",
        "purl": "pkg:cargo/rkyv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.0-pre.2"
            },
            {
              "fixed": "0.8.17"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "Shared pointer validation keyed already-validated pointees by their address and\ntype, but did not include pointer metadata. For unsized pointees, an archive\ncould therefore contain multiple `Rc`, `Arc`, or weak pointers that shared a\ndata address but used different metadata, such as different slice lengths.\n\nOnce the first pointer had been validated, later pointers to the same address\nskipped pointee validation. The safe checked `rkyv::access` API could\nconsequently return a slice with a forged length, allowing safe indexing to\nread out of bounds. The same validation bypass was reachable through checked\ndeserialization with `rkyv::from_bytes`.\n\nVersion 0.8.17 includes pointer metadata in shared pointer validation and\nrejects conflicting metadata. The 0.7 series is also affected but is no\nlonger supported by upstream. Users who process untrusted archives should upgrade\nto 0.8.17 or later.",
  "id": "RUSTSEC-2026-0235",
  "modified": "2026-08-04T09:27:20Z",
  "published": "2026-05-13T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/rkyv"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0235.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/rkyv/rkyv/issues/670"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rkyv/rkyv/commit/3c9d07fbff5949261bef38d00ab160b129bd9d3a"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "Insufficient archive validation can cause out-of-bounds reads in archives containing Rc/Arc"
}



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…