Payload CMS CVE-2026-105865

Requires (1) Payload configured with LOCAL filesystem upload storage (a collection with upload.staticDir on local disk, not a remote/cloud storage adapter), and (2) an authenticated account holding update or delete permission on that upload-enabled collection. The attacker supplies a crafted stored filename - a relative traversal path, a generated size filename (e.g. sizes.thumbnail.filename), or a path reaching through a symlink - that resolves outside the configured upload directory during file cleanup. Limiting factors: authentication plus upload-management authorization are mandatory (PR:L), so this is not remotely exploitable by anonymous users; deployments that use cloud/object storage adapters, or that restrict upload management to trusted operators, are not or only marginally exposed.

This is a genuine but conditionally-gated integrity/availability flaw rather than a drive-by critical. The provided CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H → 8.1 High) tells a consistent story with the description: network-reachable via Payload's API, low complexity, but requiring an authenticated account (PR:L) that holds upload update/delete permissions. Note C:N - this is NOT an information-disclosure bug; the impact is file deletion outside the upload directory, i.e. data loss (I:H) and service disruption (A:H). No EPSS score, KEV listing, or public POC was provided in the input, so the raw 8.1 overstates real-world urgency for most deployments: exploitation presupposes an attacker already has a privileged upload-management account, and the description explicitly notes 'deployments that restrict upload management to trusted users are less exposed.' The fix commit (adding an isPathWithin containment check) and its test suite are confirmed, but no exploitation-probability or in-the-wild signal is present. Net: prioritize patching for multi-tenant or public-signup Payload instances using local file storage, where low-trust users can hold upload rights; single-operator or cloud-storage deployments are substantially lower risk. No conflicting signals detected, but absence of EPSS/KEV means urgency is inferred, not measured.

On a Payload CMS instance using local (filesystem) upload storage, an authenticated user with permission to update or delete uploads submits a document whose stored filename (or a generated image-size filename) contains path-traversal sequences or references a symlinked path. When Payload runs its file-cleanup routine on update/delete, it resolves and deletes a target outside the configured upload directory, destroying arbitrary server files and disrupting service. No public exploit code was identified at time of analysis, though the fix commit and test cases publicly illustrate the vulnerable behavior.