YARA-X: VirusTotal's Rust rewrite of the pattern matching tool malware analysts live in

A rewrite with an explicit succession plan

YARA-X is a re-incarnation of YARA, a pattern matching tool designed with malware researchers in mind. The new incarnation intends to be faster, safer, and more user-friendly than its predecessor, and the ultimate goal is replacing YARA as the default pattern matching tool for malware researchers.

What makes this more than a hobby port is the third FAQ entry, which describes the division of labour between the two projects. YARA is still being maintained, and future releases will include bug fixes and minor features. However, you should not expect new large features or modules, and all efforts to enhance YARA, including the addition of new modules, will now focus on YARA-X.

So the plan is explicit and it is a two-stage handover. The old tool stays alive and stable, the new tool gets everything new, and the ecosystem is expected to move across. That is a much healthier position than a rewrite that leaves users with a choice and no guidance, and it means a team can adopt YARA-X gradually rather than in one migration.

The state claim is also specific, and it is the sort of claim worth reading closely. YARA-X is already mature and stable, and at VirusTotal the team has been running it in production for a long time, scanning billions of files with tens of thousands of rules, and addressing discrepancies and bugs. That is a battle-testing claim rather than a quality adjective, and it comes with the honest corollary that the bugs found in production have been fixed.

The licence is BSD-3-Clause, the primary language is Rust, the default branch is `main`, and the documentation site is at virustotal.github.io/yara-x. The last push was on 2026-10-15 and the newest release is v1.21.0 from 2026-09-29, with v1.20.0 in August 2026 and v1.19.0 in June 2026, so the release cadence is roughly monthly.

The rule model is YARA's, and the example is the whole syntax

With YARA-X you can create descriptions of malware families, or whatever you want to describe, based on textual or binary patterns. Each description, which is a rule, consists of a set of patterns and a boolean expression which determine its logic.

rule silent_banker : banker {
    meta:
        description = "This is just an example"
        threat_level = 3
        in_the_wild = true

    strings:
        $a = {6A 40 68 00 30 00 00 6A 14 8D 91}
        $b = {8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9}
        $c = "UVODFRYSIHLNWPEJXQZAKCBGMT"

    condition:
        $a or $b or $c
}

The rule above tells YARA-X that any file containing one of the three patterns must be reported as `silent_banker`. The structure is the familiar YARA one: a `meta` block for descriptive fields, a `strings` block, and a `condition` block. The `meta` values here are illustrative, with a description, a threat level, and an in the wild flag, and the colon after the rule name declares a tag, `banker`.

The strings block shows the two pattern kinds. `$a` and `$b` are hex byte sequences written in braces, which is how you match a compiled code fragment. `$c` is a plain text string. Each is prefixed with a dollar sign and a short identifier, and those identifiers are what the condition refers to, so the condition `$a or $b or $c` is a boolean expression over the patterns.

The documentation points out that more complex and powerful rules can be created with wildcards, case-insensitive strings, regular expressions, special operators, and other features explained in the documentation, and the section is titled the anatomy of a rule. So the syntax is deliberately familiar, and the effort for a user coming from YARA is learning the differences rather than learning a language.

Those differences have their own page, the differences with YARA at the rule level, and there is a separate comparison page for the more general question of how YARA-X compares to YARA. The presence of both is a good sign, because a rewrite that claims full compatibility has usually not checked.

Ten crates, and a binding for every language a scanner might use

The Cargo workspace is where the scope of the project becomes clear, and it has ten members.

`lib` is the core library, `parser` is the rule parser, `macros` holds the proc macros, and `fmt` is the formatter, which is a tool in its own right since formatting a rule file is a separate concern from scanning with it. `proto` holds the protocol definitions, and `capi` is the C API, which is what keeps YARA's C consumers able to move across.

Then the language bindings. There is `py` for Python, `js-wasm` for JavaScript, and `cli` for the command line; the Go bindings live in `go/`, outside the workspace. And `ls` is the language server, which is the one worth a second look, because a language server for a rule language means an editor can complete rule syntax, report errors as you type, and jump to definitions, which is the difference between writing rules in a plain text file and writing them in an editor that understands them.

The dependency list explains the implementation choices in a way the summary does not. `daachorse` is the Aho-Corasick library, which is the multiple pattern matching engine that makes scanning fast, and `memchr` is the byte search library underneath it. `nom` at 8.0.0 is the parser combinator library, and `regex` with `regex-automata` handles the regular expression features. `bitvec` and `bitflags` are the bit manipulation primitives, and `rayon` is the data parallelism library, which is how the scanning work is spread across cores.

The rest is a long tail of format support. `encoding_rs` and `codepage` for text encodings, `psl` for the public suffix list, `ihex` for Intel hex, `der-parser` for ASN.1, `crc32fast`, `md2`, `md-5`, `digest`, and the elliptic curve crates `p256` and `p384` with `dsa` and `ecdsa`, which is what a rule language needs in order to hash a file or verify a signature as part of a condition.

The rust-version is 1.95.0, and there is a comment in the manifest noting that when the rust-version is updated the MSRV in the GitHub Actions test workflow must be updated too, which is the small bookkeeping detail that a real project records.

The examples directory has one entry, `custom-module/`, and it is excluded from the workspace, because it is a separate project demonstrating how to write a module rather than part of the library itself.

The scanning engine is Aho-Corasick plus Rayon

The dependency list explains the performance claim in a way the summary does not, and the two crates that matter are `daachorse` at 5.0.0 and `rayon` at 1.12.0.

`daachorse` is an Aho-Corasick implementation, and Aho-Corasick is the algorithm that makes a multi-pattern scan fast. A naive scan of a file against N patterns is N passes over the data. Aho-Corasick builds a single automaton from all the patterns and walks the file once, reporting every pattern that matches at each position. When a rule set has tens of thousands of patterns, which is the scale the production claim describes, the difference between N passes and one pass is the difference between a scan that finishes and a scan that does not.

`rayon` is the data parallelism library, and it is what spreads that work across cores. The Rust standard library has threads but no work-stealing scheduler, and a scanner wants the latter, because rule sets are uneven and a naive split leaves cores idle.

Underneath both is `memchr` at 2.8.3, the byte search library, which is the primitive that the automaton is built on, and `bitvec` and `bitflags` for the bit manipulation that lets the automaton track which patterns have matched as it goes.

The parser side is separate and equally deliberate. `nom` at 8.0.0 is the parser combinator library, and `regex` with `regex-automata` at 0.4.18 handles the regular expression features of the rule language, including the case-insensitive and wildcard forms. A rule language that supports regular expressions needs a regular expression engine, and building one is not a sensible thing for a scanner project to do, so it uses one that is maintained and fast.

The rest of the dependency list is a broad format surface, and it tells you what a rule can be written against. `encoding_rs` and `codepage` for text encodings, `ihex` for Intel hex, `der-parser` for ASN.1 structures, `psl` for the public suffix list, `bstr` for byte strings, and a set of cryptographic crates, `md2`, `md-5`, `digest`, `p256`, `p384`, `dsa`, and `ecdsa`, so that a rule can hash a file or check a signature as part of its condition.

That is a good way to see the design of the project. The rule language is YARA's, the parsing and matching are Rust's ecosystem, and the deployment targets are many.

A workspace with a playground and a language server

The repository layout is wider than a typical Rust library, and the extra directories are the interesting part.

There is `capi/`, `cli/`, `lib/`, `ls/`, `macros/`, `parser/`, `proto/`, `py/`, `js-wasm/`, and `fmt/` as workspace members, with a separate `go/` directory for the Go bindings, and then `docs/`, `site/`, `playground/`, and `examples/` alongside them. The `playground/` directory is worth noting, because a rule language with a browser playground is inviting people to write rules without installing anything, which is a good way to grow an ecosystem.

There is also a `profile.json` at the root, which is the shape of a performance profile, and a `codecov.yml` for coverage reporting, with the coverage badge pointing at the same service. The `rustfmt.toml` is the formatter configuration, and the `.cargo/` directory holds Cargo configuration, which is where a project puts its build flags and aliases.

The `AUTHORS`, `CONTRIBUTORS`, and `CONTRIBUTING.md` files are the standard governance set, and the contributing notes call out the Google Contributor License Agreement requirement specifically, along with code style conventions and how to submit pull requests.

The CI badge in the README points at a workflow named tests, and the coverage badge at the main branch. The `rustfmt.toml` at the root plus the `fmt` workspace member together mean that formatting is a first-class part of the tool rather than something you do in an editor.

The `.gemini/` directory at the root is worth a brief mention, because it indicates that the project has configuration for at least one coding assistant, which in a project of this size is a sign of how the work is expected to be done now.

Editorial conclusion

YARA-X fits an analyst or a scanning service that wants YARA's rule model with a faster engine, a safer implementation, and bindings beyond the C one, and who is willing to read the rule-level differences before porting an existing rule set. It is the wrong choice if you depend on YARA's module ecosystem, since the original project states that new modules will now focus on YARA-X. Check three things before you adopt it: that the rules you already have behave the same, since there is a dedicated differences page, that your Rust toolchain is 1.95.0 or newer, and that you understand the licensing, since YARA-X is BSD-3-Clause while the rules you write are yours to own.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. VirusTotal/yara-x on GitHub