GHSA-hc4m-q9jh-xw4j: Registry Pack Verification Fail-Open Vulnerability in nono-cli

The nono-cli utility is a Rust-based command-line interface designed to manage, install, and execute registry packages ("packs") containing execution profiles and session hooks. To maintain host integrity, nono-cli implements a cryptographic trust architecture to verify packages prior to execution. This process is essential because session hooks run natively on the host operating system, presenting a substantial attack surface.

The security boundary depends on validating each package against local provenance and cryptographic signatures. These controls are evaluated in crates/nono-cli/src/profile_runtime.rs inside the verify_profile_packs function. This function coordinates checks against a global registry lockfile and individual signature files.

In versions up to and including 0.61.2, a design flaw allows packages to execute without cryptographic validation if the security metadata is entirely absent. This issue is categorized under CWE-636: Not Failing Securely ('Failing Open'). An attacker with local access who can tamper with the configuration directory can execute unverified packages.

The root cause of this vulnerability lies in the structural logic of the package verification flow in crates/nono-cli/src/profile_runtime.rs. The code was designed to treat verification states as conditional depending on the presence of local metadata files. Specifically, the system tracked packages using ~/.config/nono/packages/lockfile.json and verified integrity using individual .nono-trust.bundle files.

When executing a profile, verify_profile_packs queried lockfile.json for the package entry. If the package was present but lacked a valid signature, or if the lockfile entry existed but the .nono-trust.bundle was missing, the verification logic correctly generated an error and blocked execution. This partial metadata state successfully failed closed.

However, if both the package entry in lockfile.json and the corresponding .nono-trust.bundle file were missing, the function bypassed all checks. The implementation did not enforce a default-deny policy. Instead, the absence of metadata was interpreted as a signal that verification was not required, resulting in a fail-open condition.

To understand the exact breakdown, we must analyze the vulnerable code path in crates/nono-cli/src/profile_runtime.rs. The implementation used an optional match to extract the package entry from the lockfile.

// Vulnerable implementation of lockfile lookup
let locked = lockfile.packages.get(pack_ref);
if let Some(locked_pkg) = locked {
    for (artifact_name, locked_artifact) in &locked_pkg.artifacts {
        // Perform verification steps...
    }
}

If locked evaluated to None, the entire block was bypassed without returning an error. Similarly, the trust bundle evaluation was conditional.

// Vulnerable implementation of trust bundle check
let bundle_path = install_dir.join(".nono-trust.bundle");
if bundle_path.exists() {
    // Validate signature bundle...
    verify_stored_bundles(&install_dir, &bundle_path, pack_ref, Some(pinned_signer))?;
}

If bundle_path.exists() returned false, the system skipped signature validation. The patch in commit db07375031642f089d549b4f7b9abece87e39f87 corrected this behavior by converting these conditional blocks into strict validation rules.

// Patched lockfile check enforcing mandatory entries
let locked_pkg = lockfile.packages.get(pack_ref).ok_or_else(|| {
    nono::NonoError::PackageVerification {
        package: pack_ref.clone(),
        reason: format!(
            "pack '{}' has no lockfile entry - reinstall with: nono pull {} --force",
            pack_ref, pack_ref
        ),
    }
})?;

The patched implementation treats missing trust bundles as a hard error. Additionally, it resolves potential variant bypasses by strictly verifying the signer_identity and calling verify_stored_bundles unconditionally.

Exploitation of this vulnerability requires local write access to the host configuration directory at ~/.config/nono. This path holds both the global lockfile.json and the individual package files. An attacker targeting a systems environment can leverage this state to execute malicious configurations.

Consider a configuration containing a package named always-further/claude that includes host-executed session hooks. If the package is tampered with, standard execution will fail due to signature mismatch. To bypass this restriction, the attacker deletes the entry for always-further/claude inside ~/.config/nono/packages/lockfile.json and the signature trust bundle at ~/.config/nono/packages/always-further/claude/.nono-trust.bundle.

When the user or a system process loads the profile via nono-cli, the client reads the modified path. Because no metadata is present, the logic skips verification and executes the malicious session hooks natively on the host OS.

The impact of this vulnerability is assessed at Medium severity with a CVSS v3.1 score of 6.6. The attack vector is Local (AV:L), requiring local operating system access or file tampering capabilities to exploit. No network-facing exposure is directly associated with this vector.

The core consequence is the execution of unverified, tampered packages on the host machine. Because nono packages support session hooks running natively without isolation, a local privilege boundary is bypassed. If a low-privilege attacker can write to the user's ~/.config/nono directory, they can execute arbitrary shell commands inside the context of any process invoking nono-cli.

The vulnerability does not directly impact the availability of the system (A:N), but it completely degrades both the confidentiality (C:H) and integrity (I:H) of the host environment. The execution of arbitrary session hooks can lead to credential theft, persistence establishment, or lateral movement within the network.

Remediation requires upgrading the nono-cli utility to version 0.61.3 (which is bundled in the official release v0.62.0). This update enforces signature and lockfile verification unconditionally. Systems running vulnerable versions must be updated to prevent local exploitation vectors.

To recover from situations where legitimate metadata is missing or corrupted, administrators can run the recovery command:

nono pull always-further/claude --force

This command uses the newly implemented ExecuteOptions { allow_unmanaged_identical_write_files: true } logic. This safely regenerates the necessary lockfile entries and .nono-trust.bundle structures without opening security bypasses, provided the local file hashes match the official distribution hashes.