Summary
stigmem-node: decay sweep expires and counts facts across all tenants (cross-tenant BOLA)
Advisory details
Summary
On a multi-tenant stigmem node, a caller holding a write credential for one tenant can run a decay sweep that acts on every tenant's facts. The candidate-selection queries in lifecycle/decay.py (_select_ttl_candidates, _select_confidence_candidates) carried no tenant_id predicate, and the caller's tenant was not threaded into the sweep or its async worker (run_decay_sweep / _decay_job_worker), reached via POST /v1/decay/sweep.
Impact
A sweep with ttl_seconds=0 expires all tenants' facts — cross-tenant data destruction (integrity and availability). A dry_run sweep returns a global candidate count, acting as a cross-tenant existence/volume oracle (information disclosure).
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 threaded into run_decay_sweep and _decay_job_worker, and AND tenant_id = ? was added to the candidate selectors and the graph-sync. A tenant-B sweep now leaves tenant-A facts untouched, and dry_run counts only the caller's tenant. The check_fact_query_tenant_scope.py CI guard was extended to scan lifecycle/ so this class cannot silently regress.
Workarounds
None other than upgrading to 0.9.0a12. Single-tenant deployments are unaffected.
References
Related vulnerabilities
All Supply chain →- MEDIUMGHSA-hv6h-hc26-q48p
SurrealDB: Field-level SELECT permissions bypassed via graph and reference traversals
- HIGHGHSA-xhv3-q4xx-349r
stistigmem-node: quarantine review surface exposes and mutates other tenants' quarantined facts (cross-tenant BOLA)
- HIGHCVE-2026-26231
Gitea before 1.26.2 has an authorization bypass in its "Allow edits from maintainers" pull-request feature (CVE-2026-26231). The maintainer edit permission was not properly scoped, so a user could push unauthorized commits to any repository they could merely read. In effect, read access to a repo could be turned into write access through a crafted pull request.
- CRITICALSC-GHA-OIDC-MISCONFIG-2021
This class covers overly permissive cloud IAM trust policies that federate with GitHub's OIDC provider (token.actions.githubusercontent.com) but fail to constrain which workload may assume the role. The cloud role validates the OIDC token but checks only the audience claim (for example sts.amazonaws.com) while omitting the token.actions.githubusercontent.com:sub condition, or it uses a broad wildcard such as repo:org/* or a StringLike pattern instead of StringEquals, so any branch, any fork, or even an attacker-owned repository can mint a valid GitHub OIDC token and exchange it for cloud credentials. Because the sub claim encodes repository, branch, tag, and environment, dropping or loosening it removes the only binding between the role and the intended pipeline, yielding full assumption of the trusted role. Tinder Security Labs documented this in their AWS OIDC research, finding multiple real AWS roles assumable from unauthorized repositories due to missing subject validation, with the successful assumptions visible in CloudTrail. GitHub's OIDC support and the configure-aws-credentials path shipped in 2021, making this a long-standing systemic configuration risk.
- HIGHCVE-2026-52801
Gogs has the ability to import local repositories via Mirror Settings
- HIGHCVE-2026-52800
Gogs Vulnerable to CSRF Leading to Organization Owner Takeover