cargo package report

Is yara-x safe?

1 known vulnerability, worst severity MODERATE.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so cargo packages are not covered.


      cvss
      0.0
      medium

      severity band, no base score published

      epss
      not scored

      chance of exploitation in 30 days

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — GHSA-2jx3-ff3v-j7jj, the advisory selected below

      // 1 advisories

      GHSA-2jx3-ff3v-j7jj

      MODERATE

      > [!NOTE] > This finding was identified during an agentic unsafe Rust code review performed by Gemini AI, followed by human review and verification.

      // the issue

      The crate exports a public safe API Rules::deserialize accepting any generic byte sequence B: AsRef. It restores compiled rule structures directly from raw bytes using bincode::serde::decodefromslice.

      This decoded Rules struct contains internal lookup tables, including subpatterns: Vec, atoms: Vec, and litpool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

      • Rules::getsubpattern executes unsafe { self.subpatterns.getunchecked(subpatternid.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling getsubpattern during scanning triggers an out-of-bounds memory read (Undefined Behavior).

      https://github.com/VirusTotal/yara-x/blob/5bd1f35db783679c90a3ea1a66bd15fe4e55bef1/lib/src/compiler/rules.rs#L355-L360

      • Metadata::next() extracts string metadata via unsafe { s.tostrunchecked() }. If serialized bytes corrupt litpool indices or structural data, tostrunchecked constructs a &str pointing to invalid UTF-8 bytes (Undefined Behavior).

      https://github.com/VirusTotal/yara-x/blob/5bd1f35db783679c90a3ea1a66bd15fe4e55bef1/lib/src/models.rs#L204-L210

      Because passing malformed or untrusted data to Rules::deserialize induces Undefined Behavior in subsequent safe calls (Scanner::new, Scanner::scan) without any unsafe blocks in caller code, this API is unsound.

      Minimal Reproduction (Miri / Native Crash)

      Zip file with crashingpayload: crashingpayload.zip

      We have a payload crashingpayload.bin where only a single byte in the structural metadata tail is mutated (changing a SubPatternId from 1 to 248 while keeping the WebAssembly bytecode completely untouched and valid).

      Below is the self-contained verification script which compiles and runs against the official unmodified yara-x v1.17.0 crate:

      use yara_x::{Rules, Scanner};
      
      fn main() {
          // Embed the crashing payload generated by the fuzzer at compile time.
          let serialized = include_bytes!("crashing_payload.bin");
          println!("Loaded embedded crashing payload, length: {}", serialized.len());
      
          // Deserialize. On unmodified library, this succeeds because the WASM and headers
          // are pristine and structural corruption isn't validated.
          if let Ok(deserialized) = Rules::deserialize(serialized) {
              println!("Deserialization succeeded! Running scanner...");
              let mut scanner = Scanner::new(&deserialized);
              
              // Run the standard scan, which will execute the WASM and trigger the out-of-bounds read!
              let _ = scanner.scan(b"lorem ipsum dolor sit amet");
              println!("Scanner finished.");
          } else {
              println!("Deserialization failed!");
          }
      }
      // 1. miri trace

      NOTE: This needs to be run with 1.17.0. I haven't tested this against other versions.

      Unfortunately I was able to get a miri trace, but I'm not able to reproduce it right now because of lockfile changes. If you're trying this out be sure to use MIRIFLAGS="-Zmiri-disable-stacked-borrows"

      // 2. segfault / panics

      When run natively (without Miri or any sanitizers) on a standard Linux platform, the process immediately segfaults:

      $ cargo run --bin verify
      Loaded embedded crashing payload, length: 11777
      Deserialization succeeded! Running scanner...
      Segmentation fault (core dumped)

      And with a newer compiler (which appears to have debug assertions in getunchecked)

      Deserialization succeeded! Running scanner...
      
      thread 'main' (997442) panicked at lib/src/compiler/rules.rs:404:36:
      unsafe precondition(s) violated: slice::get_unchecked requires that the index is within the slice
      
      This indicates a bug in the program. This Undefined Behavior check is optional, and cannot be relied on for safety.
      note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

      Suggested Fix

      To uphold Rust soundness guarantees, either mark Rules::deserialize as pub unsafe fn deserialize with a formal /// # Safety contract documenting that callers are responsible for verifying the authenticity and structural integrity of the input bytes (e.g. via cryptographic signatures), or replace all internal getunchecked and tostrunchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::fromutf8).

      ---


      Checked 2026-09-25 at 16:46 UTC. The most recent advisory here was published 2026-09-24. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.
      Is yara-x safe? cargo package security report | CyberXYZ