Skip to content

GHSA-4v4h-m2qq-ppgw CVE-2026-50188

Kirby: Request header injection in `Http\Remote`

Medium Packagist
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.44%
Chance of exploitation in the next 30 days. Higher than 38.53% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')
Fix
4.9.4
Upgrade getkirby/cms to this version or later

Description

TL;DR

This vulnerability affects Kirby sites and plugins that use the Kirby\Http\Remote class (including Remote::request(), Remote::get(), Remote::post(), and similar helpers) to send outgoing HTTP requests and that pass untrusted, user-controlled data into the headers option of such a request.

By including newline characters in the value of the header, it was possible to inject a separate, independent header that was not intended to be set.

A successful attack requires that an application or plugin forwards attacker-influenced input into a request header value. Sites that only send static, developer-defined headers are not affected. The attack does not target Panel users or site visitors directly; it targets the remote service that Kirby connects to.

In Kirby's default configuration, the Remote class is not exposed to untrusted input, so a default installation is not affected. The vulnerability becomes relevant for custom code, plugins, or integrations that build request headers from user input.


Introduction

HTTP header injection (also known as CRLF injection) is a type of vulnerability that allows an attacker to insert additional, attacker-controlled HTTP headers into a request or response. HTTP headers are separated by carriage-return and line-feed characters (\r\n). If untrusted data containing these characters is placed into a header value without sanitization, an attacker can terminate the intended header early and append headers of their own.

For outgoing requests, this means an attacker who controls part of a header value can add or override headers that the application did not intend to send. Depending on the remote service, this can be used to override security-relevant headers (such as Authorization, Host, or Cookie), to smuggle requests, or to poison caches on the upstream system.

Such vulnerabilities are relevant if untrusted input can reach the header values of an outgoing request – for example, a user-configurable API token, a forwarded tracking identifier, or any other value that originates from a request, form field, or content file.

Affected components

The Kirby\Http\Remote class is used throughout Kirby and by plugins to perform outgoing HTTP requests. Its headers option allows callers to define the headers sent with the request.

As the vulnerability is in the way Remote assembles these headers, it affects all code paths that send a Remote request whose header values contain untrusted data. The Kirby core itself has not passed untrusted data in that way, but plugins or custom code might have used the class in such a way.

Impact

In affected releases, header values passed to Remote were handed to the cURL request library without removing newline characters:

The headers option accepted arbitrary strings as header values and forwarded them to the underlying cURL request unchanged. A value containing \r\n was written verbatim to the socket and therefore split into several header lines on the wire.

For example, a single X-Foo header value of "Bar\r\nX-Injected: pwned" produced two separate headers in the outgoing request:

X-Foo: Bar
X-Injected: pwned

The receiving server parsed X-Injected: pwned as its own header. In the same way, an attacker could override a header that the application set earlier in the same request (for example, replacing a legitimate Authorization header).

The vulnerability allows attackers to inject or override HTTP headers in outgoing requests, provided the affected application or plugin includes attacker-controlled data in a header value.

Patches

The problem has been patched in Kirby 4.9.4 and Kirby 5.4.4. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we now strip carriage-return and line-feed characters from header values before they are passed to the underlying request, preventing additional headers from being injected.

Affected versions

Packagist

PackageVulnerableFixed in
getkirby/cms
< 4.9.4
4.9.4
getkirby/cms
>= 5.0.0-alpha.1, < 5.4.4
5.4.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

getkirby/cms Packagist → 4.9.4

composer
composer require getkirby/cms:^4.9.4

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N

Attack vector
Network
Attack complexity
High
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
High
Availability (subsequent systems)
None

Weakness

CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')

The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.

How to prevent it
  • Implementation: Construct HTTP headers very carefully, avoiding the use of non-validated input data.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. If an input does not strictly conform to specifications, reject it or transform it into something that conforms. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Implementation: Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.

How to prevent it
  • Implementation: Avoid using CRLF as a special sequence.
  • Implementation: Appropriately filter or quote CRLF sequences in user-controlled input.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-9vx2-j98c-p72w
Kirby: Access to image files and limited access to JSON files outside of the site root via path traversal in the media handling
High Also affects getkirby/cms
GHSA-6j4c-mgqr-qv76
Kirby: Access to image files outside of the site root via path traversal in the media handling
Medium Also affects getkirby/cms
GHSA-67mx-6wf2-92xp
Kirby: File upload permissions are not checked during processing of chunk data
High Also affects getkirby/cms
GHSA-rf2p-vh74-7vvh
Kirby: System path exposure from error messages in the REST API
Medium Also affects getkirby/cms
GHSA-r3w8-2c5r-h9j9
Kirby: `pages.access` permission is not checked in the `site/find` REST API route
High Also affects getkirby/cms
GHSA-89cp-7p28-jffg
Kirby: Access to files of top-level drafts is not protected by permissions
Medium Also affects getkirby/cms
GHSA-whxw-24jc-cwmv
Kirby: External Initialization of the Panel on reverse proxy setups with the `Forwarded` header
Critical Also affects getkirby/cms
GHSA-wr9h-4r83-f4v6
Kirby: Cross-site scripting (XSS) from incomplete HTML/XML sanitization in `Dom::sanitize()`
High Also affects getkirby/cms
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor