GHSA-4V4H-M2QQ-PPGW
Vulnerability from github – Published: 2026-06-18 15:04 – Updated: 2026-06-18 15:04TL;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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.9.3"
},
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.4.3"
},
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-alpha.1"
},
{
"fixed": "5.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50188"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T15:04:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### TL;DR\n\nThis 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.\n\nBy 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.\n\nA 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.\n\nIn Kirby\u0027s 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.\n\n----\n\n### Introduction\n\nHTTP 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.\n\nFor 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.\n\nSuch vulnerabilities are relevant if untrusted input can reach the header values of an outgoing request \u2013 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.\n\n### Affected components\n\nThe `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.\n\nAs 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.\n\n### Impact\n\nIn affected releases, header values passed to `Remote` were handed to the cURL request library without removing newline characters:\n\nThe `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.\n\nFor example, a single `X-Foo` header value of `\"Bar\\r\\nX-Injected: pwned\"` produced two separate headers in the outgoing request:\n\n```\nX-Foo: Bar\nX-Injected: pwned\n```\n\nThe 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).\n\nThe 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.\n\n### Patches\n\nThe problem has been patched in [Kirby 4.9.4](https://github.com/getkirby/kirby/releases/tag/4.9.4) and [Kirby 5.4.4](https://github.com/getkirby/kirby/releases/tag/5.4.4). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn 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.",
"id": "GHSA-4v4h-m2qq-ppgw",
"modified": "2026-06-18T15:04:47Z",
"published": "2026-06-18T15:04:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/security/advisories/GHSA-4v4h-m2qq-ppgw"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkirby/kirby"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/4.9.4"
},
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/releases/tag/5.4.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Kirby: Request header injection in `Http\\Remote`"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.