Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Stigmem allows an authenticated user to create a webhook subscription with a user-controlled deliveryaddress. That value is stored and later used directly by the subscription delivery worker as the destination of a server-side HTTP POST request. The codebase already contains an outbound SSRF guard, assertsafeurl(), which blocks loopback, private, link-local, and metadata-style destinations. However, the subscription webhook delivery path does not appear to apply this guard either when the subscription is created or immediately before delivery. As a result, an authenticated user can configure a webhook destination such as http://127.0.0.1:9999/ssrf, trigger a matching fact-change event, and cause the Stigmem server to issue a server-side HTTP request to an internal loopback address. Details Relevant files: text HIT: POST /ssrf user-agent: python-httpx/0.28.1 x-stigmem-event-id: ... Kindly check this out: EideticCVEReport.pdf
Recommended action: Upgrade to 0.9.0a11 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 (selectttlcandidates, selectconfidencecandidates) carried no tenantid predicate, and the caller's tenant was not threaded into the sweep or its async worker (rundecaysweep / decayjobworker), reached via POST /v1/decay/sweep. Impact A sweep with ttlseconds=0 expires all tenants' facts — cross-tenant data destruction (integrity and availability). A dryrun 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…
Recommended action: Upgrade to 0.9.0a12 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On a multi-tenant stigmem node, a tenant administrator could list, read, and admit or reject quarantined facts belonging to other tenants. The list/count queries and getquarantinedfact in routes/quarantine.py lacked an f.tenantid = identity.tenantid predicate, and the garden lookup was not tenant-scoped — reached via the /v1/quarantine list and admit/reject endpoints. Impact Cross-tenant confidentiality (reading another tenant's quarantined content) and cross-tenant integrity (moderating — admitting or rejecting — another tenant's facts), gated only by a plain tenant write capability rather than a node-level admin authority. 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…
Recommended action: Upgrade to 0.9.0a12 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On a multi-tenant stigmem node, RTBF (right-to-be-forgotten) tombstones were mis-scoped two ways. (1) issuetombstone 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 — gettombstonefilter (routes/facts/common.py) and the tombstonescopecache (lifecycle/tombstones.py) — had no tenantid 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…
Recommended action: Upgrade to 0.9.0a12 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Federation peer registration accepted peer key material during registration without a separate administrator approval step based on an out-of-band fingerprint check. Impacted deployments are nodes that accept federation peer registration across a network where initial registration could be intercepted or misdirected. Patches Patched in 0.9.0a2. Peer registration now uses a pending approval flow, and peer tokens are not accepted until an administrator approves the peer using the expected fingerprint. Workarounds Before upgrading, restrict peer registration endpoints to trusted administrative networks and verify peer public-key fingerprints out of band before allowing federation traffic. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog:…
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A single configuration flag could disable plugin signature enforcement. If an operator unintentionally carried that setting into an environment where plugin paths are writable by less-trusted users, unsigned plugin code could be loaded. Patches Patched in 0.9.0a2. Disabling plugin signature enforcement now requires a second explicit acknowledgment value. Workarounds Before upgrading, keep plugin signing required in all shared or production environments and ensure plugin directories are not writable by untrusted users. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35 - Security policy and posture: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/SECURITY.md
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Stigmem nodes with federation enabled could be configured to run without mTLS outside loopback-only local development. In affected deployments, federation traffic may traverse the network without the intended transport protection. Impacted users are operators who enabled federation and explicitly disabled mTLS while binding the node to a non-loopback URL. Patches Patched in 0.9.0a2. The node now refuses this configuration unless insecure federation is limited to loopback-only local development. Workarounds Before upgrading, operators should enable mTLS for federation or ensure federation endpoints are bound only to loopback/private test environments and are not reachable by untrusted networks. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog:…
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Postgres backend schema identifiers were interpolated into SQL strings. In the reviewed code path the schema value is operator-controlled, but the pattern was unsafe if future call sites allowed tenant or request-controlled schema names. Impacted users are operators using the Postgres backend in affected versions. Patches Patched in 0.9.0a2. Schema identifier handling now uses defensive identifier quoting and validation-oriented regression coverage. Workarounds Before upgrading, only configure Postgres schema names from trusted deployment configuration and do not derive schema names from request, tenant, header, or user input. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35 - Security…
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A mismatch in federation peer-token timestamp handling could cause valid peer tokens to be treated as expired. Impacted deployments are Stigmem nodes using federation peer authentication paths from affected versions. The primary impact is availability and reliability of authenticated federation flows. Patches Patched in 0.9.0a2. Federation peer-token timestamp handling now uses the canonical millisecond-based validation path and is covered by regression tests. Workarounds Before upgrading, avoid mixed peer-token minting paths and restrict federation use to tightly controlled peers. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35 - Security policy and posture:…
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Stigmem nodes configured with authentication disabled could grant the anonymous identity broad read/write/federation capabilities if exposed outside a loopback-only local development environment. Impacted users are operators who intentionally disabled authentication while binding the node to a non-loopback URL. Patches Patched in 0.9.0a2. The node now refuses unauthenticated operation outside loopback-only local development. Workarounds Before upgrading, keep authentication enabled for all non-local deployments and do not expose nodes with authentication disabled to untrusted networks. Upgrade Upgrade to the patched release: If developers install through the Stigmem meta-package instead, they should use the matching extra for their deployments, for example: Resources - Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2 - Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35 - Security policy and posture:…
Recommended action: Upgrade to 0.9.0a2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.