GHSA-x26h-xmv8-gxf7
Fix: eidetic-labs/stigmem#728GHSA-x26h-xmv8-gxf7 is a CWE-639 vulnerability in stigmem-node. O3 Security confirms whether GHSA-x26h-xmv8-gxf7 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
stigmem-node: RTBF tombstones are mis-attributed and suppress reads tenant-blind (cross-tenant BOLA)
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-x26h-xmv8-gxf7.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
stigmem-nodeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
On a multi-tenant stigmem node, RTBF (right-to-be-forgotten) tombstones were mis-scoped two ways. (1) issue_tombstone defaulted the tenant to "default" instead of the caller's tenant, so tombstones could be written to the wrong tenant. (2) The read-suppression path — _get_tombstone_filter (routes/facts/common.py) and the _tombstone_scope_cache (lifecycle/tombstones.py) — had no tenant_id predicate, so tombstone suppression was applied tenant-blind across fact queries and provenance. Reached via /v1/tombstones and the fact query/provenance read paths.
Impact
Cross-tenant integrity of the RTBF mechanism: a tenant's deletion request could be recorded against the wrong tenant, and tombstone suppression could hide — or fail to hide — facts across tenant boundaries, undermining both data-view correctness and RTBF guarantees.
Affected configurations
This is a cross-tenant break. It is exploitable only on deployments running the opt-in stigmem-plugin-multi-tenant (multiple tenants on one node). A default single-tenant node has only tenant="default" — there is no second tenant to cross — so it is not exploitable on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.
Patches
Fixed in 0.9.0a12 (PR #728): identity.tenant_id is passed from issue_tombstone into create_tombstone (no more "default" fallback); AND tenant_id = ? was added to _get_tombstone_filter and get_tombstone_status; the suppression cache is re-keyed to include tenant; and all four read call sites thread the caller's tenant. A tenant-B tombstone now suppresses only tenant-B facts and is invisible to tenant-A reads.
Workarounds
None other than upgrading to 0.9.0a12. Single-tenant deployments are unaffected.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | stigmem-node | all versions | 0.9.0a12 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for stigmem-node. 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 stigmem-node to 0.9.0a12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x26h-xmv8-gxf7 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-x26h-xmv8-gxf7 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-x26h-xmv8-gxf7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x26h-xmv8-gxf7 in your dependencies?
O3 detects GHSA-x26h-xmv8-gxf7 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.