GHSA-6GQW-JQV7-V88M: Multi-Tenant Isolation Bypass in stigmem-node via Missing SQL Tenant Predicates

The application stigmem-node supports multi-tenant deployments via the stigmem-plugin-multi-tenant plugin. This plugin implements logical data separation by assigning a tenant_id to each record in a shared relational database. Multi-tenant isolation models rely on database queries systematically filtering records according to the authenticated caller's tenant identifier.

Three subsystems within the core codebase fail to apply the required tenant_id restrictions: decay sweeps (lifecycle/decay.py), quarantine moderation (routes/quarantine.py), and Right-to-Be-Forgotten (RTBF) tombstones (lifecycle/tombstones.py). This structural omission exposes an attack surface where any caller with write access to a single tenant can read, modify, or erase data across all other tenant partitions.

The vulnerability is classified under CWE-863 (Incorrect Authorization) and CWE-284 (Improper Access Control). The security impact represents a complete compromise of tenant integrity and availability, as a low-privileged tenant user can trigger global data expiration and control moderation flows belonging to other organizations on the same node.

The root cause of this vulnerability lies in the shared-schema multi-tenancy implementation used by stigmem-node. All tenant data resides within the same SQLite tables, utilizing a tenant_id column to distinguish between records owned by different tenants. To maintain strict isolation boundaries, every data manipulation and selection query must execute with a static or dynamic predicate specifying tenant_id = ?.

In the vulnerable version of stigmem-node, the decay sweep worker fetches expired facts by querying the database using timestamp values without appending a tenant_id check. Because the SQL statements query the global facts table without isolation constraints, candidate selection matches facts from every tenant in the system. When the background job executes, it applies expiration overrides globally.

Similarly, the quarantine moderation route resolves fact lookups by targeting only the fact_id, ignoring the caller's active tenant identifier. Lastly, the RTBF system retrieves active tombstones based strictly on entity URIs. This omission permits tombstones registered by Tenant B to be parsed and applied during Tenant A's read path, enabling unauthorized, cross-tenant data suppression.

In node/src/stigmem_node/lifecycle/decay.py, the candidate-selection SQL queries were executed without a tenant_id constraint, leading to a global table scan.

# BEFORE PATCH (Vulnerable)
def _select_ttl_candidates(
    conn: Any, effective_ttl: int, scope: str | None, now_dt: datetime
) -> list[str]:
    cutoff = (now_dt - timedelta(seconds=effective_ttl)).isoformat()
    sql = (
        "SELECT f.id FROM facts f "
        "LEFT JOIN fact_validity_overrides fvo ON fvo.fact_id = f.id "
        "WHERE f.timestamp <= ? "
        "AND COALESCE(fvo.valid_until, f.valid_until) IS NULL "
        "AND NOT (entity LIKE 'stigmem:%' AND entity NOT LIKE 'stigmem://%') "
        "AND NOT (relation LIKE 'stigmem:%' AND relation NOT LIKE 'stigmem://%')"
    )
    params: list[Any] = [cutoff]

The patched code introduces a strict tenant_id parameter to the function signatures, appends AND f.tenant_id = ? to the SQL query, and binds the caller's active tenant identifier to the query parameters.

# AFTER PATCH (Fixed)
def _select_ttl_candidates(
    conn: Any, effective_ttl: int, scope: str | None, now_dt: datetime, tenant_id: str
) -> list[str]:
    cutoff = (now_dt - timedelta(seconds=effective_ttl)).isoformat()
    sql = (
        "SELECT f.id FROM facts f "
        "LEFT JOIN fact_validity_overrides fvo ON fvo.fact_id = f.id "
        "WHERE f.timestamp <= ? "
        "AND f.tenant_id = ? "  # Added tenant-scoping predicate
        "AND COALESCE(fvo.valid_until, f.valid_until) IS NULL "
        "AND NOT (entity LIKE 'stigmem:%' AND entity NOT LIKE 'stigmem://%') "
        "AND NOT (relation LIKE 'stigmem:%' AND relation NOT LIKE 'stigmem://%')"
    )
    params: list[Any] = [cutoff, tenant_id]

This same modification pattern was applied to _select_confidence_candidates in decay.py, _get_quarantined_fact in routes/quarantine.py, and _get_tombstone_filter in routes/facts/common.py. The remediation effectively binds all database filters to the verified session of the active caller, preventing cross-tenant leakage at the SQL layer. This fix is structurally complete, though long-term security depends on developers maintaining these predicates in future SQL queries.

An attacker can exploit this vulnerability with standard, low-privileged write credentials for an authorized tenant (e.g., Tenant B). The objective is to retrieve metadata and destroy active records within Tenant A (commonly running on the default workspace).

First, the attacker uses the decay sweep endpoint to execute a reconnaissance query. By sending an HTTP POST request to /v1/decay/sweep with the parameter dry_run set to true, the attacker forces the system to perform a global database scan. Because the SQL query lacks isolation predicates, the response returns the count of all facts stored across the entire multi-tenant server, confirming the volume of Tenant A's data.

POST /v1/decay/sweep HTTP/1.1
Host: vulnerable-node.stigmem.internal
Authorization: Bearer <Tenant-B-Write-Token>
Content-Type: application/json
 
{
  "ttl_seconds": 0,
  "dry_run": true
}

Second, the attacker weaponizes the sweep by repeating the request with dry_run set to false. The application backend fetches all records older than zero seconds across all tenants, and writes an override setting valid_until to now() for each matched fact ID. Consequently, Tenant A's active database contents are immediately flagged as expired and purged from active queries, executing a cross-tenant denial of service.

The successful exploitation of GHSA-6GQW-JQV7-V88M leads to a high-impact breach of data integrity and availability, alongside low-impact confidentiality exposure. The CVSS v4.0 score is rated at 7.2 with the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N.

The high rating for Integrity (VI:H) stems from the attacker's capability to modify other tenants' data states. By abusing the missing tenant filter in the quarantine route, a malicious tenant administrator can unilaterally approve or reject quarantined data belonging to other organizations, disrupting the ingestion workflows.

The high rating for Availability (VA:H) is driven by the potential for permanent or temporary data destruction via the decay sweep. An attacker can set arbitrary expiration constraints globally, forcing data to disappear from legitimate user queries. Confidentiality exposure remains low (VC:L) because raw data records are not fully dumped through the sweep endpoints, though record counts are directly leaked.

To remediate GHSA-6GQW-JQV7-V88M, systems administrators must upgrade the stigmem-node package to version 0.9.0a12 or newer. This version enforces standard tenant-parameter binding on all dynamic database selections. Organizations using the package in a single-tenant layout are not actively exposed but should upgrade to maintain robust code hygiene.

If upgrading immediately is not possible, administrators should disable the multi-tenant plugin by updating the configuration file or environment variables to set STIGMEM_MULTI_TENANT_ENABLED="false". Disabling multi-tenancy restricts the application context to a single default namespace, nullifying cross-tenant traversal vectors.

Web Application Firewalls (WAF) can be configured to block ad-hoc POST requests to /v1/decay/sweep and /v1/quarantine endpoints originating from untrusted tenants. Additionally, monitoring logs should flag any invocation of decay sweeps that occur outside scheduled maintenance windows or are initiated by non-administrative users.