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
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When using the default tenant array field access, an authenticated user could assign themselves to other tenants. You are affected if: - You are using @payloadcms/plugin-multi-tenant If you configure the tenants arrayFieldAccess.create/update functions, a secured replacement membership field, you are not affected by this specific default behavior. Patches Users should upgrade Payload packages to = 3.90.0 or = 4.0.0-canary.34. Workarounds Configure tenants arrayFieldAccess.create and tenants arrayFieldAccess.update so only trusted users authorized for all tenants can modify memberships.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user limited to one tenant could create a record in another tenant. This requires the multi-tenant plugin with at least one tenant-enabled collection. Reads and direct edits to an existing target-tenant document were not bypassed. You are affected if: - You are using @payloadcms/plugin-multi-tenant Patches Users should upgrade Payload packages to = 3.90.0 or = 4.0.0-canary.34. Workarounds You can add access control with accessResultOverride on the multi-tenant collection config to ensure a user has access to the tenant before creating.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.