In February 2024, a security report surfaced regarding an HTML injection vulnerability in the Edit Content Layout module of Kirby CMS version 4.1.. Registered as CVE-2024-26482, this vulnerability allowed users to inject certain HTML tags into content fields. However, the Kirby CMS team disputed the risk, arguing the system's existing sanitization prevents script-based attacks.

This post offers an exclusive look into this vulnerability: how it works, proof-of-concept code, vendor response, security impact, and developer guidance. If you work on Kirby-based sites or third-party plugins, it’s relevant to understand the nuance between *allowed* and *dangerous* HTML.

What Is Kirby CMS?

Kirby CMS is a popular flat-file Content Management System (CMS) written in PHP. It is used by developers and content creators to build customizable, markdown-friendly websites. A key feature is its “panel” interface, which lets non-technical users create, edit, and format web content.

Vulnerability Summary: CVE-2024-26482

Module Affected: Edit Content Layout
Product Version: Kirby CMS 4.1.
Vulnerability Type: HTML Injection (NOT XSS!)
Threat Level: Low (Per Vendor)
Reported By: Original CVE Record

How It Happens

* In the Edit Content Layout admin panel, user-supplied input is rendered as HTML on published pages.
* Some HTML formatting, like <h1> headings, are intentionally allowed.
* Security researchers found that you could also insert less-safe tags, which might cause layout or minor security issues if not filtered.
* But — and this is key — Kirby has backend filtering preventing scripts (&lt;script&gt;) from ever being executed. So you can’t do classic Cross-Site Scripting (XSS).

Imagine a user tries to save this in the content field

<h1>Welcome!</h1>
<img src=x onerror="alert('XSS attempt!')">

The <h1> is rendered (allowed).

- The <img> is allowed, but the onerror attribute (JavaScript) is stripped by Kirby’s backend sanitizer.

Kirby’s actual content sanitization

// Pseudocode representing Kirby's backend protection
$allowed_tags = '<h1><b><i><u><p><a><ul><ol><li><img>';
$sanitized = strip_tags($user_input, $allowed_tags);

Kirby only lets through defined harmless tags.

`html

Hacked

The script tag is not executed (and probably removed).

You can test with other HTML elements, but anything potentially dangerous is sanitized.

Vendor Response

Kirby’s team responded to the report (paraphrased):

> “We permit some HTML for formatting (like H1, strong, etc.). However, we sanitize everything server-side so malicious scripts or event handlers are never executed.”

This means the vulnerability, while technically “HTML injection,” does not escalate into XSS or site takeover.

Risks

- An attacker might affect page layout by injecting allowed HTML (like big headers), but cannot inject JavaScript.
- If your output context is fragile, layout manipulation might annoy users, but this is the intent in many CMS setups for editors.

No urgent need to update — Kirby’s sanitizer is reliable here.

- Review which tags are allowed in your Kirby configuration and restrict further if you want only pure text (e.g., for comments or guest input).

References

- Official CVE Record (NVD)
- Kirby CMS Homepage
- GitHub Kirby Issue Tracker
- Kirby Sanitization Discussion

Conclusion

CVE-2024-26482 highlights the nuanced difference between allowing content creators to use rich formatting and protecting a website against *actual* attacks. While Kirby CMS 4.1. does allow some HTML injection, it robustly sanitizes anything dangerous — so no real-world XSS is possible here.

Advice:
- Regularly check which HTML tags are permitted on your site, especially if you change default settings.
- Trust Kirby’s built-in protection, but if your use-case is sensitive (like user comments), consider even stricter filtering.


*If you’ve found novel issues or need help securing Kirby-powered sites, drop a message or visit the Kirby forums.*

Timeline

Published on: 02/22/2024 05:15:09 UTC
Last modified on: 08/29/2024 20:36:26 UTC