The vulnerability is a cross‑site scripting flaw that permits attacker‑controlled URLs to bypass URL filtering in four Kirby renderers that produce `<a href>` links. The flaw resides in the URL methods for KirbyTags and image blocks, which fail to filter malicious URL schemes such as `javascript://`, `vbscript://`, `data://`, `livescript://`, `mocha://`, and `jar://`. Notably, the `(link: …)` KirbyTag, the `link` parameter of the `(image: …)` tag when it does not resolve to a known file or `self`, the `link` field of the built‑in image block, and the HTML importer for the `blocks` field all accept these problematic URLs, bypassing the earlier deactivation of plain `javascript:` URLs. Based on the description, it is inferred that an authenticated editor who can add or edit content can embed such URLs, resulting in arbitrary script execution in all site visitors’ browsers, potentially exposing credentials, defacing content, or exfiltrating data. This weakness is CWE‑79, and the issue has been addressed in releases 4.9.1 and 5.4.1.

Vulnerable installations of the Kirby content management system that use the link KirbyTag, the link parameter of the image KirbyTag when it does not resolve to a file or self, the link field of the image block, and the HTML importer for the blocks field are affected. The issue applies to all releases prior to 4.9.1 on the Kirby 4 series and prior to 5.4.1 on the Kirby 5 series, including any front‑end pages that render editor‑supplied content.

The CVSS score is 8.4, indicating a high‑severity problem. The EPSS score is less than 1 %, pointing to a very low probability of exploitation as of the current data. Kirby is not listed in CISA KEV. Based on the description, it is inferred that attackers can exploit the flaw by inserting crafted URLs into editor‑supplied content such as pages, posts, or blocks; no specialized environment is required, and the vulnerability is reachable from the public‑facing front‑end of the site. Once a user visits a page containing the malicious link, the script executes in the victim's browser, enabling the attacker to run arbitrary code with the victim's permissions.