Describe the bug
Drogon appears vulnerable to HTTP response header injection / response splitting in its generic response-header handling path, similar to CVE-2026-21428.
If application-controlled input is passed to HttpResponse::addHeader(), Drogon stores the supplied header value as-is and later serializes it into the raw HTTP response as:
without rejecting embedded CR/LF bytes.
In the reproduced case, a user-controlled query parameter is reflected into:
resp->addHeader("X-Echo", value.value());
A malicious value such as safe%0d%0aInjected:%20yes causes Drogon to emit a second response header line (Injected: yes) instead of keeping the input within a single header value.
To Reproduce
Steps to reproduce the behavior:
- Build and run Drogon from the latest tested source
- Add a simple handler that reflects a query parameter into a response header, for example:
app().registerHandler("/echo_header",
[](const drogon::HttpRequestPtr &req,
std::function<void(const drogon::HttpResponsePtr &)> &&callback) {
auto resp = drogon::HttpResponse::newHttpResponse();
auto value = req->getOptionalParameter<std::string>("value");
if (value) {
resp->addHeader("X-Echo", value.value());
}
resp->setBody("ok");
callback(resp);
});
- Send a request
- Observe that the response header block contains an injected second header line, for example:
HTTP/1.1 200 OK
content-length: 2
connection: close
content-type: text/html; charset=utf-8
server: drogon/1.9.12
x-echo: safe
Injected: yes
date: ...
Expected behavior
Drogon should reject or sanitize CR/LF bytes in application-controlled response header values before storing or serializing them.
A value passed to addHeader() should remain a single header field value and must not be able to create additional raw HTTP response header lines.
Desktop (please complete the following information):
- OS: Ubuntu 24.04
- Browser: N/A
- Version: N/A
Smartphone (please complete the following information):
- Device: N/A
- OS: N/A
- Browser N/A
- Version N/A
Additional context
This appears similar to CVE-2026-21428 because the affected path is the generic response-header setter path, not a Content-Type-specific path.
Relevant Drogon code paths:
lib/src/HttpResponseImpl.h: addHeader(std::string field, const std::string &value) stores the supplied value without filtering CR/LF bytes.
lib/src/HttpResponseImpl.cc: the response serialization path appends header-name, ": ", header-value, and "\r\n" directly into the outgoing buffer.
Please check the related information and fix the code.
And let me know if there is anything you need when you proceed with the patch.
Describe the bug
Drogon appears vulnerable to HTTP response header injection / response splitting in its generic response-header handling path, similar to CVE-2026-21428.
If application-controlled input is passed to
HttpResponse::addHeader(), Drogon stores the supplied header value as-is and later serializes it into the raw HTTP response as:without rejecting embedded CR/LF bytes.
In the reproduced case, a user-controlled query parameter is reflected into:
A malicious value such as safe%0d%0aInjected:%20yes causes Drogon to emit a second response header line (Injected: yes) instead of keeping the input within a single header value.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Drogon should reject or sanitize CR/LF bytes in application-controlled response header values before storing or serializing them.
A value passed to addHeader() should remain a single header field value and must not be able to create additional raw HTTP response header lines.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
This appears similar to CVE-2026-21428 because the affected path is the generic response-header setter path, not a Content-Type-specific path.
Relevant Drogon code paths:
lib/src/HttpResponseImpl.h: addHeader(std::string field, const std::string &value) stores the supplied value without filtering CR/LF bytes.
lib/src/HttpResponseImpl.cc: the response serialization path appends header-name, ": ", header-value, and "\r\n" directly into the outgoing buffer.
Please check the related information and fix the code.
And let me know if there is anything you need when you proceed with the patch.