fix(security): move to yara-x 1.7 and sevenz-rust2, take memf-windows 0.5

[h4x0r]

fix(security): move to yara-x 1.7 and sevenz-rust2, take memf-windows 0.5

Picks up the memf-* crates published today and applies the same migration made
in memory-forensic. Clears the wasmtime and sevenz-rust exposure from this
workspace.

yara-x "0.12" -> "~1.7" (wasmtime 26.0.1 -> 36.0.13)
sevenz-rust "0.6" -> sevenz-rust2 "0.21"
memf-windows "0.4" -> "0.5" (0.5.0 requires yara-x ~1.7)

sevenz-rust is gone from the graph entirely: 0 entries in the lock. It has no
safe upgrade (RUSTSEC-2026-0246, plus the path-traversal arbitrary-file-write),
so the 7z path moves to the maintained fork. decompress_file_with_extract_fn
survives under the same name there, so the call site changes only in its crate
path.

The tilde on yara-x is load-bearing. 1.8+ moves to wasmtime 43.x and NO 43.x
release is patched for GHSA-hgjw-h833-99q9 or its five siblings — the fixed
ranges are 24.0.12, 36.0.13, 46.0.2+ and 47.0.3+. Only the 1.7 line resolves
wasmtime ^36.0.2, reaching the patched 36.0.13. Upgrading to the newest yara-x
looks safer and silently reinstates all six.

The three yara-x companion crates are pinned to 1.7.1 in the lock. yara-x
declares them ^1.7.1, which permits 1.19, and 1.19's yara-x-proto REMOVED a
field 1.7.1's build.rs uses (ModuleOptions.rust_module). Without the pins this
does not compile. Third repo to need them, so treat it as a property of using
yara-x ~1.7 rather than an incident.

memf-strings also had to be updated explicitly: it sat at 0.2.1, which requires
yara-x ^0.12, and a lockfile refresh alone leaves existing entries where they
are. Until it moved, this workspace resolved BOTH yara-x majors and kept
wasmtime 26.0.1 alongside 36.0.13 — the fix would have appeared applied while
the vulnerable stack still built.

Lock churn is deliberately minimal: 65 version lines. A blanket cargo update
moved 312 and pulled browser-forensic-core 0.3.1 alongside 0.2.0, breaking
issen-browser on an unrelated API change. That is reverted; only the packages
the changed requirements force have moved.

NOT FIXED, and not fixable here: lru 0.16.4 remains in the graph via
mft 0.7.0, which requires lru ^0.16.1. That is mft's newest release
(2025-12-23), so RUSTSEC-2026-0253 cannot be cleared from this repo by any
version bump. It needs an upstream fix, a fork, or an argued ignore — a
decision, not an omission.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	yara-x-proto@​0.12.0 ⏵ 1.7.1
	yara-x@​0.12.0 ⏵ 1.7.1	+5
	zip@​5.1.1
	memf-core@​0.2.4 ⏵ 0.2.6
	memf-correlate@​0.3.0 ⏵ 0.3.1
	memf-linux@​0.3.1 ⏵ 0.3.3
	memf-strings@​0.2.1 ⏵ 0.2.3
	memf-symbols@​0.2.3 ⏵ 0.2.4
	memf-windows@​0.4.0 ⏵ 0.5.0
	yara-x-macros@​0.12.0 ⏵ 1.7.1
	yara-x-parser@​0.12.0 ⏵ 1.7.1

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: cargo lzma-rust2 is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: ? → cargo/zip@5.1.1 → cargo/lzma-rust2@0.13.0 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore cargo/lzma-rust2@0.13.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report