Threat Intelligence Database

stigmem versions before 0.9.0a2 allow unauthenticated access when authentication is disabled on non-loopback deployments. This improper authorization vulnerability enables attackers to perform read, write, and federation operations anonymously if nodes are exposed outside local development environments. The vulnerability has a critical severity with a CVSS score of 9.2.

stigmem-node version 0.9.0a1 has an improper certificate validation vulnerability that allows federation peer key material to be accepted during peer registration without requiring administrator fingerprint approval. This flaw enables an attacker who can intercept or misdirect initial peer registration over the network to register a malicious peer and potentially access or tamper with federation traffic. The issue is fixed in version 0.9.0a2 by introducing a pending approval flow requiring administrator fingerprint verification before accepting peer tokens.

stigmem-node 0.9.0a1 allows plugin signature enforcement to be disabled via a single configuration flag without a second explicit acknowledgment. If that setting is carried into an environment where plugin directories are writable by less-trusted users, unsigned (potentially malicious) plugin code could be loaded and executed, resulting in arbitrary code execution. Fixed in 0.9.0a2, which requires a second explicit acknowledgment to disable signature enforcement.

stigmem-node version 0.9.0a1 contains an SQL injection vulnerability due to improper neutralization of special elements in SQL commands. The vulnerability arises because Postgres schema identifiers are interpolated into SQL strings without proper quoting or validation, allowing operator-controlled schema names to potentially inject SQL. This issue is fixed in version 0.9.0a2 by adding identifier quoting and validation. As a workaround, schema names should only be configured from trusted deployment configurations.

Stigmem before 0.9.0a11 fails to validate the delivery_address parameter when creating webhook subscriptions, allowing authenticated users to specify internal loopback and private network destinations. Attackers can trigger matching fact-change events to cause the Stigmem server to issue server-side HTTP POST requests to internal services, enabling blind SSRF attacks against localhost and private network endpoints.

stigmem versions before 0.9.0a12 contain a broken object level authorization vulnerability in the decay sweep endpoint that allows authenticated attackers with write credentials for one tenant to execute decay operations affecting all tenants. Attackers can submit POST requests to the decay sweep endpoint with ttl_seconds=0 to expire facts across all tenants, or use dry_run to obtain cross-tenant fact counts and existence information.

stigmem-node before 0.9.0a12 contains a broken object level authorization (cross-tenant BOLA) vulnerability in the quarantine review endpoints. On multi-tenant deployments running the opt-in stigmem-plugin-multi-tenant, the list/count queries and _get_quarantined_fact in routes/quarantine.py lacked a tenant_id predicate and the garden lookup was not tenant-scoped, allowing a tenant administrator with only a plain tenant write capability to list, read, and admit or reject quarantined facts belonging to other tenants via the /v1/quarantine endpoints. Default single-tenant deployments are not affected.

stigmem-node before 0.9.0a12 contains a cross-tenant broken object level authorization (BOLA) flaw in the RTBF (right-to-be-forgotten) tombstone mechanism. issue_tombstone defaulted the tenant to "default" instead of the caller's tenant, allowing deletion records to be written to the wrong tenant, and the read-suppression path (_get_tombstone_filter and the tombstone scope cache) lacked a tenant_id predicate, so tombstone suppression was applied tenant-blind across fact queries and provenance reads. As a result, a tenant's deletion could be attributed to the wrong tenant and tombstone suppression could either hide facts belonging to other tenants or fail to hide facts within the correct tenant, undermining data isolation and RTBF guarantees. The issue is exploitable only on multi-tenant deployments running the opt-in stigmem-plugin-multi-tenant; single-tenant deployments are unaffected. Fixed in 0.9.0a12.