How severe is GHSA-hc4m-q9jh-xw4j?

GHSA-hc4m-q9jh-xw4j has a CVSS score of 6.6/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-hc4m-q9jh-xw4j?

GHSA-hc4m-q9jh-xw4j affects the following packages: nono-cli (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-hc4m-q9jh-xw4j?

Update nono-cli to 0.61.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hc4m-q9jh-xw4j is resolved across your whole dependency graph.

How do I detect GHSA-hc4m-q9jh-xw4j in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nono-cli. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-hc4m-q9jh-xw4j if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-hc4m-q9jh-xw4j?

O3 pinpoints whether GHSA-hc4m-q9jh-xw4j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-hc4m-q9jh-xw4j actively exploited in the wild?

No public exploit code has been indexed for GHSA-hc4m-q9jh-xw4j yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-hc4m-q9jh-xw4j published, and has it been updated?

GHSA-hc4m-q9jh-xw4j was published on July 28, 2026 and was last updated on July 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀 crates.io

GHSA-hc4m-q9jh-xw4j

MEDIUM

GHSA-hc4m-q9jh-xw4j is a medium-severity (CVSS 6.6) vulnerability in nono-cli. O3 Security confirms whether GHSA-hc4m-q9jh-xw4j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

nono-cli'scregistry pack verification can fail open when provenance metadata is absent

Published

Jul 28, 2026

Updated

Jul 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🦀nono-cli

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Registry-installed nono packs are expected to be verified from local provenance metadata before they are used. Two files are relevant:

~/.config/nono/packages/lockfile.json
~/.config/nono/packages/<namespace>/<pack>/.nono-trust.bundle

Testing shows that nono fails closed when a pack has a trust bundle but no lockfile entry. However, if the trust bundle is also absent, the same pack can load successfully. Deleting security metadata should not make a pack easier to run.

Affected behavior

Observed with always-further/claude:

Delete ~/.config/nono/packages/lockfile.json.

Result:

nono: Package verification failed for always-further/claude: pack 'always-further/claude' has a trust bundle but no lockfile entry - reinstall with: nono pull always-further/claude --force

Delete ~/.config/nono/packages/always-further/claude/.nono-trust.bundle.

Result: the profile loads successfully.

Restore .nono-trust.bundle while the lockfile is still absent.

Result:

nono: Package verification failed for always-further/claude: pack 'always-further/claude' has a trust bundle but no lockfile entry - reinstall with: nono pull always-further/claude --force

Impact

If both the lockfile entry and trust bundle are absent, nono may accept an installed registry pack without artifact hash verification or provenance verification.

This is especially important for pack-provided session hooks, because session hooks execute on the host outside the sandbox. A pack that contributes host-executed code should not run unless nono can verify that the code is a locked and trusted pack artifact.

Root cause

verify_profile_packs treats the lockfile entry as optional. Existing code fails when a trust bundle exists without a matching lockfile entry, but when the trust bundle is absent too, there is no equivalent hard failure.

That creates a fail-open state:

lockfile entry missing
trust bundle missing
pack directory still present
profile can load

Recommended fix

For any registry pack selected for execution, require both:

A matching lockfile entry in ~/.config/nono/packages/lockfile.json.
A present and valid .nono-trust.bundle in the installed pack directory.

If either is missing, fail closed with a reinstall instruction, for example:

reinstall with: nono pull <namespace>/<pack> --force

This keeps verification monotonic: removing provenance metadata cannot downgrade a verification failure into a successful launch.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`nono-cli`	all versions	0.61.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nono-cli. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update nono-cli to 0.61.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hc4m-q9jh-xw4j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hc4m-q9jh-xw4j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-hc4m-q9jh-xw4j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary Registry-installed nono packs are expected to be verified from local provenance metadata before they are used. Two files are relevant: - `~/.config/nono/packages/lockfile.json` - `~/.config/nono/packages/<namespace>/<pack>/.nono-trust.bundle` Testing shows that nono fails closed when a pack has a trust bundle but no lockfile entry. However, if the trust bundle is also absent, the same pack can load successfully. Deleting security metadata should not make a pack easier to run. ## Affected behavior Observed with `always-further/claude`: 1. Delete `~/.config/nono/packages/lockfil

O3 Security · Impact-Aware SCA

Is GHSA-hc4m-q9jh-xw4j in your dependencies?

O3 detects GHSA-hc4m-q9jh-xw4j across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works