yara-x

Version	Released
`1.22.1` patch	Oct 26, 2026
`1.22.0` minor	Oct 20, 2026
`1.21.0` minor	Sep 29, 2026
`1.20.0` minor	Aug 24, 2026
`1.19.0` unknown	Jun 24, 2026
`1.18.0` unknown 1 CVE	Jun 18, 2026
`1.17.0` unknown 1 CVE	May 27, 2026
`1.16.0` unknown 1 CVE	May 06, 2026
`1.15.0` unknown 1 CVE	Apr 13, 2026
`1.14.0` unknown 1 CVE	Mar 06, 2026
`1.13.0` unknown 1 CVE	Feb 06, 2026
`1.12.0` unknown 1 CVE	Jan 26, 2026
`1.11.0` unknown 1 CVE	Jan 09, 2026
`1.10.0` unknown 1 CVE	Nov 20, 2025
`1.9.0` unknown 1 CVE	Nov 03, 2025
`1.8.1` unknown 1 CVE	Oct 07, 2025
`1.8.0` unknown 1 CVE	Oct 06, 2025
`1.7.1` unknown 1 CVE	Sep 19, 2025
`1.7.0` unknown 1 CVE	Sep 17, 2025
`1.6.0` unknown 1 CVE	Sep 05, 2025
`1.5.0` unknown 1 CVE	Aug 08, 2025
`1.4.0` unknown 1 CVE	Jul 10, 2025
`1.3.0` unknown 1 CVE	Jul 02, 2025
`1.2.1` unknown 1 CVE	Jun 18, 2025
`1.2.0` unknown 1 CVE	Jun 18, 2025
`1.1.0` unknown 1 CVE	Jun 13, 2025
`1.0.1` unknown 1 CVE	Jun 06, 2025
`1.0.0` unknown 1 CVE	Jun 04, 2025
`0.15.0` unknown 1 CVE	May 19, 2025
`0.14.0` unknown 1 CVE	Mar 28, 2025
`0.13.0` unknown 1 CVE	Feb 03, 2025
`0.12.0` unknown 1 CVE	Dec 17, 2024
`0.11.1` unknown 1 CVE	Nov 29, 2024
`0.11.0` unknown 1 CVE	Nov 26, 2024
`0.10.0` unknown 1 CVE	Oct 21, 2024
`0.9.0` unknown 1 CVE	Oct 03, 2024
`0.8.0` unknown 1 CVE	Sep 09, 2024
`0.7.0` unknown 1 CVE	Aug 28, 2024
`0.6.0` unknown 1 CVE	Jul 30, 2024
`0.5.0` unknown 1 CVE	Jun 30, 2024
`0.4.0` unknown 1 CVE	May 29, 2024
`0.3.0` unknown 1 CVE	May 17, 2024
`0.2.0` unknown 1 CVE	May 03, 2024
`0.1.1` unknown 1 CVE	Apr 04, 2024
`0.1.0` unknown 1 CVE	Apr 04, 2024

1.22.1 patch

Oct 26, 2026

1.22.0 minor

Oct 20, 2026

1.21.0 minor

Sep 29, 2026

1.20.0 minor

Aug 24, 2026

1.19.0 unknown

Jun 24, 2026

1.18.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 18, 2026

1.17.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 27, 2026

1.16.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 06, 2026

1.15.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Apr 13, 2026

1.14.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Mar 06, 2026

1.13.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Feb 06, 2026

1.12.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jan 26, 2026

1.11.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jan 09, 2026

1.10.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Nov 20, 2025

1.9.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Nov 03, 2025

1.8.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Oct 07, 2025

1.8.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Oct 06, 2025

1.7.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Sep 19, 2025

1.7.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Sep 17, 2025

1.6.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Sep 05, 2025

1.5.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Aug 08, 2025

1.4.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jul 10, 2025

1.3.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jul 02, 2025

1.2.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 18, 2025

1.2.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 18, 2025

1.1.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 13, 2025

1.0.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 06, 2025

1.0.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 04, 2025

0.15.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 19, 2025

0.14.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Mar 28, 2025

0.13.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Feb 03, 2025

0.12.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Dec 17, 2024

0.11.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Nov 29, 2024

0.11.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Nov 26, 2024

0.10.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Oct 21, 2024

0.9.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Oct 03, 2024

0.8.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Sep 09, 2024

0.7.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Aug 28, 2024

0.6.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jul 30, 2024

0.5.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Jun 30, 2024

0.4.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 29, 2024

0.3.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 17, 2024

0.2.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

May 03, 2024

0.1.1 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Apr 04, 2024

0.1.0 unknown

1 CVE

GHSA-2jx3-ff3v-j7jj Sep 24, 2026

yara-x: Unvalidated deserialization in safe `Rules::deserialize` allows memory corruption and UB

Medium

Local Low Low None

The Issue

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

This decoded Rules struct contains internal lookup tables, including sub_patterns: Vec<(PatternId, SubPattern)>, atoms: Vec<SubPatternAtom>, and lit_pool: BStringPool. Subsequent safe operations assume these internal tables satisfy strict structural invariants:

Rules::get_sub_pattern executes unsafe { self.sub_patterns.get_unchecked(sub_pattern_id.0 as usize) }. If untrusted serialized bytes contain an atom referencing an out-of-bounds SubPatternId, calling get_sub_pattern 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.to_str_unchecked() }. If serialized bytes corrupt lit_pool indices or structural data, to_str_unchecked 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.

Zip file with crashing_payload: crashing_payload.zip

We have a payload crashing_payload.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 get_unchecked)

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

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 get_unchecked and to_str_unchecked calls on deserialized data structures with safe bounds checks (.get()) and UTF-8 validation (std::str::from_utf8).

Fixed in


          1.19.0

References

Updated Sep 24, 2026 · Source: OSV.dev

Apr 04, 2024

Activity

Reach

Details