BookStack, the open-source self-hosted wiki that organizes documentation into Shelves, Books, Chapters, and Pages, shipped a dedicated security update, version 26.05.4, on August 24, 2026. It’s not a feature release. The update closes four security issues, the most serious of which is a critical remote code execution flaw reachable through the platform’s content import feature.
The headline issue, tracked as CVE-2026-82450, affects instances where import permissions are handed out loosely. An authenticated user holding both the “Import Content” and “Create Books” permissions can upload a specially crafted ZIP file disguised as a book cover image. The file is actually a PHP polyglot: a single file that is simultaneously valid as an image and as executable PHP. That dual identity is enough to slip past BookStack’s validation checks during import, letting the attacker run arbitrary code on the server.
That’s a narrower attack surface than an unauthenticated RCE. Exploiting it requires a logged-in account with two specific permissions, not open access from the public internet. Still, plenty of team wikis hand “Import Content” and “Create Books” to more people than they’d hand server access to, which is probably why this landed as a dedicated security release instead of waiting for the next feature update.
What else v26.05.4 fixes
Three other issues shipped alongside the RCE fix:
- A crafted ZIP file disguised as a book cover could trigger remote code execution (CVE-2026-82450) during import, for accounts holding both “Import Content” and “Create Books” permissions.
- Request endpoints behind BookStack’s built-in drawing tool could be manipulated into cross-site scripting scenarios.
- Endpoints meant for draft pages could be hijacked to edit pages that weren’t drafts, even without edit permission on those pages.
- Draft pages created by other users could surface in certain search result listings, exposing content that was supposed to stay private to its author.
None of these four are dramatic on their own. Together, though, they cross three different trust lines: what an importer can run on the server, what a visitor’s browser can be tricked into executing, and what a permission-restricted user can read or edit that they shouldn’t. That’s a reasonable spread of issues to bundle into one patch cycle.
If you can’t update immediately, there’s a stopgap: pull “Import Content” and “Create Books” away from any account that doesn’t strictly need both. BookStack’s permission system is granular enough to do this per role, and it closes the specific combination CVE-2026-82450 depends on, even before you get to patching. It’s not a substitute for updating, just a way to buy yourself a day or two if your maintenance window doesn’t line up with a Monday-morning CVE.
Who should update, and how urgently
BookStack’s own guidance is direct: update, full stop, but treat it as urgent if untrusted users have general access to your instance, particularly edit access. In that case, the maintainers also suggest checking your image upload folders for files that aren’t actually images. That’s the kind of thing that would be left behind if someone had already tried exploiting the ZIP import flaw.
For a small homelab instance with a handful of known, trusted editors, the risk is lower; you’re presumably not granting “Import Content” and “Create Books” to strangers. But the update is free, it doesn’t appear to break anything, and there’s no good reason to leave a known RCE path open, however narrow the conditions for triggering it. Running the community-maintained linuxserver/bookstack Docker image is the most common setup; pulling the new tag and restarting the container should be enough, though it’s worth checking your own compose file for anything custom.
For more on BookStack’s licensing, its MySQL requirement, and how it compares to Wiki.js and Confluence, see our BookStack overview.
Full details and the changelog are in the official BookStack release announcement and on the GitHub releases page for v26.05.4.