CVE-2026-71415: Kirby CMS: auth bypass enables chunk-upload DoS

GHSA-67mx-6wf2-92xpHIGH
Published August 31, 2026
CISO Take

Kirby CMS's REST API failed to check upload permissions before accepting chunked file uploads, letting any authenticated user without upload rights fill the server's temporary storage with incomplete file chunks that persist for up to 24 hours. There is no public exploit or scanner template, EPSS data isn't available, and it's not in CISA KEV, so this reads as a low-noise availability bug rather than an actively exploited threat — but with 502 downstream dependents and 67 other CVEs in this package's history, patch velocity matters for anyone running Kirby-based sites with role-restricted panel users. Note this is a general-purpose PHP CMS vulnerability, not an AI/ML-specific flaw; it only becomes relevant to an AI security program if Kirby is used to manage content feeding an AI pipeline (e.g., a headless CMS backing a RAG ingestion job or AI-generated content workflow). Patch to Kirby 5.5.2, where preflight permission checks were added to the chunk processor, and in the meantime monitor temp-directory disk usage and panel accounts with restricted-but-active roles for unusual chunked-upload request volume.

Sources:NVDGitHub Advisory

What is the risk?

Moderate-to-high severity but low urgency: exploitation requires an authenticated account (no anonymous attack surface) and the impact is denial-of-service via disk/storage exhaustion, not data compromise or code execution — the advisory explicitly confirms permission checks on final file destinations (content/site/accounts) were never bypassed. Attack complexity is low (repeated chunked upload requests, no advanced technique required) once an attacker has any panel-accessible account, which raises risk in multi-tenant or agency-managed Kirby deployments where many restricted-role users exist. No KEV listing, no EPSS score, and no known public exploit or Nuclei template lower near-term exploitation likelihood.

How does the attack unfold?

Initial Access
Attacker authenticates with a legitimate but restricted panel account that has REST API access but no file-upload permissions.
Exploitation
Attacker sends chunked upload requests and withholds the final chunk, bypassing the missing permission check on the chunk-storage step.
Impact
Repeated incomplete chunk uploads fill the temporary storage directory, causing a denial-of-service condition that persists up to 24 hours.
AML.T0029

What systems are affected?

PackageEcosystemVulnerable RangePatched
Panelcomposer>= 5.0.0, < 5.5.25.5.2
5.8KOpenSSF 6.5514 dependentsPushed yesterday67% patched~15d to patchFull package profile →

Do you use Panel? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.4%
chance of exploitation in 30 days
Higher than 37% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

1 step
  1. Upgrade to Kirby 5.5.2 or later, where the chunk-upload handler now enforces the same file-permission checks (files.create, files.replace, users.update) before storing chunk data. Until patched, audit panel roles and remove access.panel from any user role that isn't also granted upload permissions, since the bug specifically requires that mismatched permission combination. Monitor the temporary chunk-upload directory for abnormal growth or a high volume of incomplete uploads from a single account as a detection signal, and consider rate-limiting or alerting on repeated chunked-upload requests from restricted-role users.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSAuth BypassAPI

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-71415?

Kirby CMS's REST API failed to check upload permissions before accepting chunked file uploads, letting any authenticated user without upload rights fill the server's temporary storage with incomplete file chunks that persist for up to 24 hours. There is no public exploit or scanner template, EPSS data isn't available, and it's not in CISA KEV, so this reads as a low-noise availability bug rather than an actively exploited threat — but with 502 downstream dependents and 67 other CVEs in this package's history, patch velocity matters for anyone running Kirby-based sites with role-restricted panel users. Note this is a general-purpose PHP CMS vulnerability, not an AI/ML-specific flaw; it only becomes relevant to an AI security program if Kirby is used to manage content feeding an AI pipeline (e.g., a headless CMS backing a RAG ingestion job or AI-generated content workflow). Patch to Kirby 5.5.2, where preflight permission checks were added to the chunk processor, and in the meantime monitor temp-directory disk usage and panel accounts with restricted-but-active roles for unusual chunked-upload request volume.

Is CVE-2026-71415 actively exploited?

No confirmed active exploitation of CVE-2026-71415 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-71415?

Upgrade to Kirby 5.5.2 or later, where the chunk-upload handler now enforces the same file-permission checks (files.create, files.replace, users.update) before storing chunk data. Until patched, audit panel roles and remove access.panel from any user role that isn't also granted upload permissions, since the bug specifically requires that mismatched permission combination. Monitor the temporary chunk-upload directory for abnormal growth or a high volume of incomplete uploads from a single account as a detection signal, and consider rate-limiting or alerting on repeated chunked-upload requests from restricted-role users.

What systems are affected by CVE-2026-71415?

This vulnerability affects the following AI/ML architecture patterns: None — this is a general-purpose CMS vulnerability, not specific to AI/ML pipelines; only indirectly relevant if Kirby serves as a content backend feeding an AI ingestion or RAG workflow.

What is the CVSS score for CVE-2026-71415?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

None — this is a general-purpose CMS vulnerability, not specific to AI/ML pipelines; only indirectly relevant if Kirby serves as a content backend feeding an AI ingestion or RAG workflow

What are the technical details?

Original Advisory

### TL;DR This vulnerability affects all Kirby sites where users of a particular role have access to the REST API (`access.panel` permission is enabled) but no permission to upload any kind of file (`files.create`, `files.replace` and `user/users.update` permissions are all disabled). It was possible to fill up the temporary directory for chunked uploads with unfinished chunks even as a user without any upload permission. **This vulnerability is of high severity for affected sites.** Your Kirby sites are *not* affected if you intend all users of your site to be able to upload files. The vulnerability can only be exploited by authenticated users. It was *not* possible to bypass the actual permission checks for any files that end up in the `content` or `site/accounts` folders. ---- ### Introduction Missing authorization allows authenticated users to perform actions they are not intended to have access to. The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information. ### Affected components Kirby's REST API provides routes to upload files, specifically to create content files, replace existing content files and to create and replace user avatars. Each upload route takes either full file upload requests or chunked upload requests that can be continued in subsequent requests. During a chunked upload, the incomplete state of the uploaded file is stored in a temporary directory until the last chunk completes the file. At this time, the final permission and business logic checks are performed before the complete file is moved to its final destination. ### Impact In affected releases, the chunk upload handler did not check for the user's file upload permissions before storing incomplete chunk data in the temporary directory. This allowed attackers without upload permissions to upload multiple large files in chunks. If the final chunk was never provided, Kirby would keep the incomplete files for 24 hours. This could cause attacker-controlled storage consumption until the temporary files were automatically cleaned up or manually removed, potentially preventing other users from uploading files, or site logic from storing data. ### Patches The problem has been patched in [Kirby 5.5.2](https://github.com/getkirby/kirby/releases/tag/5.5.2). Please update this or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, we have added preflight checks to the upload chunk processor that verify the relevant system permission before storing the chunk data in the temporary directory. ### Credits Thanks to @alcls01111 for responsibly reporting the identified issue.

Exploitation Scenario

An attacker with a low-privilege, authenticated Kirby panel account (access.panel enabled but files.create/files.replace/users.update all disabled) repeatedly initiates chunked file uploads via the REST API and deliberately withholds the final chunk needed to complete each file. Because the chunk processor didn't validate upload permissions before writing to the temp directory, each attempt silently succeeds in consuming disk space. Repeating this with many large files over time exhausts server storage, degrading or blocking legitimate content uploads and site logic that depends on storage availability for up to 24 hours until Kirby's automatic cleanup — or until an admin manually intervenes.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

Timeline

Published
August 31, 2026
Last Modified
September 3, 2026
First Seen
September 1, 2026

Related Vulnerabilities