Genesis-Memory Package Suspicious Subprocess Chain
genesis-memory is a PyPI package pitched as a 'cognitive memory system' for AI coding agents. No malicious code or exploit has actually been found in it — this is a precautionary watch, not confirmation of a compromise. The rule flags cases where a process linked to genesis-memory spawns a shell, network tool, or interpreter in the same session.
How the attack works
A supply-chain concern was raised about genesis-memory, an AI-agent memory package, but no malicious payload has been confirmed. To give defenders visibility rather than false confidence, the detection looks for the string 'genesis-memory' (or 'genesis_memory') appearing in a process's own ancestry, then checks whether that same session spawns a shell, network, or interpreter subprocess. Both conditions must occur within the same process lineage — a genesis-memory reference in one unrelated session and a subprocess in another do not count. This narrows the alert beyond a generic 'any process spawned a shell' signal, but it still only reports, it does not block anything.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- f2b8b8b0-9c1e-4a2d-8f3a-6c1d2e8a4b7c
- Severity
- Medium
Why it matters
If genesis-memory or a similar package turns out to carry malicious code, this is one way early execution activity might surface — but on its own it does not prove compromise, and legitimate builds, CI pipelines, and installer scripts can trigger it too.
What you can do
- →Treat alerts as leads for manual review, not confirmed incidents — investigate the specific process lineage before acting.
- →Check whether the subprocess activity matches expected build or install behavior (e.g., setup.py invoking a build tool) versus something unexpected like outbound network calls or shell access.
- →Inventory where genesis-memory is used in your environment and pin/review its version and postinstall scripts.
- →Watch for updates or confirmed reports about genesis-memory before treating any single alert as evidence of compromise.
Known benign look-alikes
- Legitimate CI/CD pipelines installing genesis-memory that invoke build tooling (e.g. setup.py shelling out to a build wrapper) as part of a normal wheel build
- Corporate package-mirror proxies that shell out to curl/wget to fetch genesis-memory or its dependencies from an internal artifact cache during a routine pip install
- A bundled postinstall script shipped with genesis-memory that prints or references the package's own name while performing benign setup work
- Any unrelated curl/bash/python subprocess that happens to run in the same shell session as a genesis-memory install with no causal link to it