v0.15.27

InnerWarden 0.15.27

Fixed

• memfd_create fileless-execution false positives on legitimate tools (prod 7-day audit). The kernel:memfd_fileless detector fired 17 High incidents in a week on benign memfd users: fwupdmgr (firmware updater), systemd's (sd-executor), and tokio-rt-worker (a generic Rust async-runtime thread name: InnerWarden's own agent and any other Rust service). The first two are added to the curated comm allowlist, but the Rust-runtime case is fixed the non-forgeable way, not by allowlisting a generic thread name (which any Rust payload could wear): a new third FP layer clears a memfd only when the creating process's kernel-captured exe path (details.exe_path, the execve filename) lives under a package-managed system directory (path_trust::is_trusted_system_path, the single source of truth now shared with host_drift). Anti-evasion preserved: a payload running from /tmp, with a deleted backing file ((deleted)), or memfd-backed exec is explicitly NOT trusted and still promotes, and the fexecve-from-memfd follow-up stays in the recommended checks. New tests pin the FP fixes AND the evasion cases (untrusted/deleted/memfd: exe paths still fire), plus a cross-test that host_drift and kernel_promote agree on what "trusted" means.
• Cloud-range safelist could free-pass an AbuseIPDB-confirmed attacker (Context Gate blind spot). The 7-day audit found the Warden classifier ignore-ing IPs marked safelist=Google Cloud, abuseipdb=100: a cloud-range safelist was burying a community-confirmed attacker, exactly the free pass an attacker buys by renting cloud. The deterministic Context Gate now reads the existing ip_reputation (AbuseIPDB) and, escalate-only (identical shape to the DShield signal), refuses to passively close (dismiss/ignore) an incident whose IP scores >= 90/100, and blocks the provenance-driven benign-dismiss for such IPs. It can only ever raise a weak passive close to a surface (Monitor / RequestConfirmation), never relax an enforcement verdict, so a noisy shared-cloud IP at this score is at worst Monitored, never auto-blocked. The high floor avoids flooding the operator on borderline scores. New tests pin: confirmed-attacker passive close is surfaced, an enforcement verdict is left intact, a below-floor score is unchanged, the provenance self-dismiss is refused for a confirmed attacker, and the no-reputation path is unchanged.
• innerwarden upgrade now arch-smoke-tests a new binary before swapping it in. sha256 + signature prove the downloaded bytes are authentic but NOT that they execute on this host's CPU; installing an x86_64 build on the aarch64 prod box took it down on 2026-06-10. The upgrader now stages each verified binary into the install directory (a package-trusted path, so the host's own host_drift detector does not flag the check the way a /tmp exec would, which is what produced the self-inflicted Critical host_drift incidents seen in the audit during the manual aarch64 deploy ritual) and runs --version. It hard-fails and keeps the existing binary only when the binary cannot execute (spawn failure / killed by signal, the wrong-CPU-arch / corruption case); a clean non-zero exit or a cosmetic version-string mismatch is a soft warning that proceeds, so upgrades never break on anything but a genuinely non-runnable asset. This retires the manual "file + ./bin --version in /tmp before swap" procedure by doing it in-product. The smoke-test verdict logic is a pure, fully unit-tested function.

---

Install / upgrade (Linux, toolchain-free, signed binaries)

curl -fsSL https://innerwarden.com/install | sudo bash
# already installed:  sudo innerwarden upgrade --yes

Every binary below is signed (Ed25519 + Sigstore bundle). Docs: https://github.com/InnerWarden/innerwarden/wiki · Site: https://www.innerwarden.com

What's Changed

• fix: prod-audit fixes (memfd FP, AbuseIPDB cloud-safelist blind spot, upgrade arch smoke-test) by @maiconburn in #1117
• release: 0.15.27 by @maiconburn in #1118

Full Changelog: v0.15.26...v0.15.27