Loading vulnerability…
Arbitrary file write as root in pwnlift upload handler
CVE-2026-56815 affects pwnlift, a .NET/Blazor file upload server, before commit d7a95449d9ee1ea09ec1529286685f6187afbbed. The vulnerable code is in the upload handler in Components/Pages/Home.razor. In privileged deployments, the handler constructs upload destinations from Directory.GetCurrentDirectory() and writes uploaded files without safely canonicalizing paths, sanitizing filenames, or robustly preventing symlink traversal. The advisory describes two related exploitation paths: direct symlink following, where the Uploads path is replaced with a symlink to a privileged location, and a TOCTOU race that bypasses an initial incomplete fix by alternating Uploads between a real directory and a symlink. The initial fix relied on a ReparsePoint check and a flawed StartsWith-based containment check, which could be bypassed because simple prefix matching does not safely enforce directory containment. Successful exploitation allows the elevated process to write attacker-controlled files to unintended root-owned locations.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
The primary impact is arbitrary file write with root privileges when pwnlift is run in a privileged deployment. This can lead to modification or creation of sensitive system files and configuration under attacker control. The advisory specifically notes that writing into /etc/sudoers.d/ could be used to obtain full passwordless sudo, making full local privilege escalation a realistic consequence. Depending on the chosen target path, exploitation could also enable persistence, tampering with application or system configuration, and broader compromise of the host.
If you can’t patch tonight, do this now.
Until the fixed version is deployed, avoid running pwnlift with elevated privileges, especially as root via sudo. Remove privileged sudo-based deployment patterns where possible. Restrict access to the upload handler to trusted users only, and harden filesystem permissions so lower-privileged users cannot replace or manipulate the application working directory or Uploads path. As an operational mitigation, ensure the service runs from a fixed, trusted application directory rather than a caller-controlled current working directory.
Patch, then assume compromise.
Upgrade or patch pwnlift to a version containing commit d7a95449d9ee1ea09ec1529286685f6187afbbed or later. The advisory recommends replacing Directory.GetCurrentDirectory() with AppContext.BaseDirectory, enforcing path containment with Path.GetRelativePath rather than StartsWith prefix checks, and retaining symlink/ReparsePoint checks as defense in depth. Ensure the application directory and Uploads directory are root-owned and not writable by lower-privileged users. If Uploads already exists as a symlink, remove it and recreate it as a real directory before applying ownership and permission hardening.
No public exploits tracked yet. Mallory keeps watching.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.