HTTP status-line control-character injection

[
  {
    "finding_title": "HTTP status-line control-character injection",
    "verdict": "INVALID",
    "reasoning": "The reported vulnerability is a false positive for `formatStatusLine` in `status.go`.\n\n1. **Nature of the 'Vulnerability'**: The report claims that `formatStatusLine` appends `protocol` and `statusText` without validation, allowing CR/LF injection. This is a standard pattern for HTTP libraries where the caller is responsible for ensuring the validity of the reason phrase (statusText) and protocol. `formatStatusLine` is an internal helper (lowercase) used to construct the status line. The inputs `protocol` and `statusText` are passed in as byte slices.\n\n2. **Caller Context**: In `fasthttp`, `formatStatusLine` is called with:\n   - `protocol`: Derived from `HTTPVersion` constants or parsed from valid HTTP headers (which are validated to contain no CR/LF in the version string during parsing).\n   - `statusText`: Either the default status message (from the static `statusMessages` map, which contains safe strings) or a user-provided string via the public API `SetStatusMessage` or by setting `resp.Header.StatusMessage`. \n\n3. **Public API Validation**: The `Response` struct has a method `SetStatusMessage(statusMessage string)`. If an application using fasthttp sets a malicious status message containing CR/LF, that is a **misuse of the library's API** by the application developer. The library's public API `SetStatusMessage` accepts a string. It is the *application's* responsibility not to inject malicious content into the response body/headers if they are directly constructing the response. However, the threat model states: \"Attacker: Code that calls the public API... and above all the data it passes through...\". \n\nWait, the threat model says: \"Attacker: Code that calls the public API... and above all the data it passes through: parsers, decoders, deserializers and protocol handlers receive adversarial payloads that the host application obtained from untrusted sources.\" This implies the attacker controls the *input* to the library (e.g., the bytes of an HTTP request or response being parsed), not necessarily the arguments to `SetStatusMessage` in a server application (which are controlled by the app developer, not the external network attacker). \n\nIf the library is being used to *parse* an HTTP response (e.g., as a client), `formatStatusLine` might be used to *re-serialize* the response? No, `formatStatusLine` is used to *write* the status line. It is used in `Response.Append` or similar serialization methods. \n\nIf an attacker sends a malicious HTTP response to a fasthttp client, the client parses it. The `statusText` would be taken from the raw bytes of the response. If the attacker sends `HTTP/1.1 200 OK\\r\\nX-Header: Evil\\r\\n\\r\\n`, the parser extracts `statusText` as `OK` (up to CRLF). The parser typically ensures that the status line is terminated by CRLF and that the status code is numeric. The `statusText` is then stored in the `Response` object. If the application then re-serializes this response (e.g., via a proxy), `formatStatusLine` would append the stored `statusText`. \n\nHowever, the parser in fasthttp (`parseStatusLine` or similar) typically strips or validates the reason phrase. Even if it didn't, the fact that `formatStatusLine` does *not* sanitize its inputs is not a vulnerability in the *parser* or the *library logic* but a property of the *serializer*. In HTTP, the reason phrase is opaque to the parser. If the original malicious response had CR/LF in the reason phrase, it would have been malformed and likely rejected or truncated by the parser at the CRLF boundary. The reason phrase cannot contain CR/LF because those delimit the line. \n\nTherefore, `statusText` passed to `formatStatusLine` from a parsed response will *never* contain CR/LF because the parser splits on CRLF. If an application *manually* sets a malicious status message, that is the application's responsibility (server-side logic), not a vulnerability in the library's parsing or core logic exploitable by an external network attacker. The threat model focuses on \"data it passes through: parsers, decoders... receive adversarial payloads\". The payload *received* (the network bytes) does not allow injection of CR/LF into the `statusText` variable *after* parsing, because the parsing process defines the boundary. \n\nThus, an external attacker cannot trigger CR/LF injection into `formatStatusLine` via untrusted network input because the parsing process enforces line boundaries. If the library is used as a client, the attacker controls the response bytes, but the reason phrase is extracted up to CRLF. It cannot contain CRLF. \n\nConclusion: The bug is not reachable by an external attacker via untrusted input to cause response splitting, because the input to `formatStatusLine` (specifically `statusText`) is constrained by the parsing of the previous CRLF or is developer-controlled (server side).\n\nCRUX: The `statusText` passed to `formatStatusLine` cannot contain CR/LF characters if it originates from parsed network input, because the HTTP parser splits the status line on CRLF.\nGREP: parseStatusLine",
    "elapsed": 88.3,
    "tokens": 5734,
    "tokens_in": 4574,
    "tokens_out": 1160,
    "cost_usd": 0.00540108,
    "file": "status.go",
    "round": 1,
    "grep_used": true,
    "grep_results": "GREP `parseStatusLine`:\n```\n(no matches in repo)\n```"
  },
  {
    "finding_title": "HTTP status-line control-character injection",
    "verdict": "INVALID",
    "reasoning": "The report claims that `formatStatusLine` is vulnerable to control character injection in the `statusText` (reason phrase) because it does not validate/escape the input. The threat model defines the attacker as code/data passing through parsers/decoders of untrusted payloads. To be valid, an untrusted network payload must result in a `Response` object (or similar) containing a `statusText` with embedded CR/LF characters, which is then serialized by `formatStatusLine`.\n\nI need to verify two things:\n1. Can the parser (`parseStatusLine` or equivalent) produce a `statusText` containing CR or LF?\n2. Are there other public entry points (like `SetStatusMessage`) where an attacker-controlled string (e.g., from a proxy header or request) could be injected?\n\nThe previous reviewer noted that `parseStatusLine` had no matches. Let's look for how the status line is actually parsed in fasthttp. The relevant function is likely `parseStatusLine` or part of `Response.Read` / `Response.parse`.\n\nIn fasthttp, `Response` parsing logic is in `resp.go` or `http.go`. Let's grep for `parseStatusLine` variants or look at how `statusMessage` is set during parsing.\n\nGrep for `statusMessage` in `resp.go` or `http.go` to see how it's assigned during parsing.\n\nAlso, consider `SetStatusMessage`. If an application uses fasthttp as a proxy and forwards a request, does it copy status messages? Or if it parses a response, is the reason phrase extracted safely?\n\nIn standard HTTP parsing (RFC 7230), the reason phrase is the rest of the line after the status code. The line ends at CRLF. Therefore, a valid reason phrase *cannot* contain CR or LF, because those terminate the line. If an attacker sends `HTTP/1.1 200 OK\\r\\nX-Evil: 1`, the parser splits on the first `\\r\\n`. The `statusText` becomes `OK`. The `X-Evil` header is parsed as a header. If the attacker sends `HTTP/1.1 200 OK\\x0d\\x0aX-Evil: 1`, it is the same. The parser does not include the delimiter in the `statusText`.\n\nHowever, what if the parser allows control characters *other* than CR/LF? The report specifically mentions CR/LF for response splitting. Since the parser defines the line boundary at the first CR/LF, `statusText` cannot contain CR/LF from parsed network input.\n\nWhat about `protocol`? The protocol is usually a constant like `HTTP/1.1`. Even if parsed, it's part of the line before the status code.\n\nWhat about the `statusCode`? It's an int. `appendStatusCode` converts it to a string. No injection risk.\n\nThe only risk is if `statusText` is set by the *application* via `SetStatusMessage`. But the threat model says the attacker controls *untrusted input passed through parsers*. If the application takes an untrusted string (e.g., from a request header) and passes it to `SetStatusMessage`, that is a flaw in the *application* logic, not the library's parsing logic. The library's parser (`Read`/`parse`) correctly isolates the reason phrase from the rest of the stream.\n\nLet's verify how `statusMessage` is set in `resp.go`.\n\n\nCRUX: Whether the fasthttp parser can populate `Response.statusMessage` (or similar) with a string containing CR or LF characters from raw network input.\nGREP: func (h *Response) parse",
    "elapsed": 44.1,
    "tokens": 6673,
    "tokens_in": 5858,
    "tokens_out": 815,
    "cost_usd": 0.00490536,
    "file": "status.go",
    "round": 2,
    "grep_used": true,
    "grep_results": "GREP `func (h *Response) parse (simplified to: Response)`:\n```\nheader_timing_test.go:93:func BenchmarkResponseHeaderRead(b *testing.B) {\nheader_timing_test.go:95:\t\tvar h ResponseHeader\nheader_timing_test.go:138:func BenchmarkResponseHeaderWrite(b *testing.B) {\nheader_timing_test.go:140:\t\tvar h ResponseHeader\nheader_timing_test.go:185:func BenchmarkResponseHeaderPeekBytesSpecialHeader(b *testing.B) {\nheader_timing_test.go:187:\t\tvar h ResponseHeader\nheader_timing_test.go:199:func BenchmarkResponseHeaderPeekBytesNonSpecialHeader(b *testing.B) {\nheader_timing_test.go:201:\t\tvar h ResponseHeader\nfasthttpadaptor/adaptor.go:99:\t\t\t\t\tctx.Response.Header.Add(k, v)\nfasthttpadaptor/adaptor.go:104:\t\t\t\t// From net/http.ResponseWriter.Write:\nfasthttpadaptor/adaptor.go:109:\t\t\t\t\tctx.Response.Header.Set(fasthttp.HeaderContentType, http.DetectContentType(w.responseBody[:l]))\nfasthttpadaptor/adaptor.go:113:\t\t\t\tctx.Response.SetBody(w.responseBody)\nfasthttpadaptor/adaptor.go:131:\t\t\t\t\tctx.Response.Header.Add(k, v)\nfasthttpadaptor/adaptor.go:138:\t\t\t\t\tctx.Response.Header.Set(fasthttp.HeaderContentType, http.DetectContentType(w.responseBody[:l]))\nfasthttpadaptor/adaptor.go:199:// Writer implements http.ResponseWriter + http.Flusher + http.Hijacker for the adaptor.\nfasthttpadaptor/adaptor.go:304:\tw.ctx.HijackSetNoResponse(true)\nfasthttpadaptor/adaptor_test.go:46:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:132:\tresp := &ctx.Response\nfasthttpadaptor/adaptor_test.go:171:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:176:\tnetMiddleware := func(_ http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:207:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:209:\t\t\tt.Errorf(\"expected http.ResponseWriter to implement http.Hijacker\")\nfasthttpadaptor/adaptor_test.go:278:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:280:\t\t\tt.Errorf(\"expected http.ResponseWriter to implement http.Flusher\")\nfasthttpadaptor/adaptor_test.go:325:\t\tresp, err := http.ReadResponse(bufio.NewReader(c), nil)\nfasthttpadaptor/adaptor_test.go:361:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:363:\t\t\tt.Errorf(\"expected http.ResponseWriter to implement http.Flusher\")\nfasthttpadaptor/adaptor_test.go:411:\t\tresp, err := http.ReadResponse(bufio.NewReader(c), nil)\nfasthttpadaptor/adaptor_test.go:447:\tnethttpH := func(w http.ResponseWriter, r *http.Request) {\nfasthttpadaptor/adaptor_test.go:449:\t\t\tt.Errorf(\"expected http.ResponseWriter to implement http.Hijacker\")\n```\n\nGREP `parseStatusLine`:\n```\n(no matches in repo)\n```\n\nGREP `statusMessage`:\n```\nstatus.go:8:\tstatusMessageMin = 100\nstatus.go:9:\tstatusMessageMax = 511\nstatus.go:85:\tstatusMessages = []string{\nstatus.go:156:\tif statusCode < statusMessageMin || statusCode > statusMessageMax {\nstatus.go:160:\tif s := statusMessages[statusCode]; s != \"\" {\nheader.go:54:\tstatusMessage   []byte\nheader.go:141:\treturn h.statusMessage\nheader.go:145:func (h *ResponseHeader) SetStatusMessage(statusMessage []byte) {\nheader.go:146:\th.statusMessage = initHeaderValueBytes(h.statusMessage, statusMessage)\nheader.go:985:\th.statusMessage = h.statusMessage[:0]\nheader.go:1054:\tdst.statusMessage = append(dst.statusMessage, h.statusMessage...)\nheader.go:2832:\tstatusMessage := []byte(nil)\nheader.go:2835:\t\tstatusMessage = b[n+1:]\nheader.go:2858:\tif len(statusMessage) > 0 {\nheader.go:2859:\t\th.SetStatusMessage(statusMessage)\nhttp_test.go:1277:\t// set StatusNoContent with statusMessage\n```"
  },
  {
    "finding_title": "HTTP status-line control-character injection",
    "verdict": "INVALID",
    "reasoning": "The reported vulnerability claims that `formatStatusLine` allows control character injection (CR/LF) into the HTTP status line if the `protocol` or `statusText` contains such characters. To be a valid vulnerability under the library threat model, an attacker must be able to control these inputs via untrusted network payloads (e.g., malicious HTTP responses or requests) that pass through the library's parsers.\n\n1. **Parser Behavior**: I need to verify how `statusMessage` is parsed from network input. The grep results for `statusMessage` in `header.go` show the parsing logic around lines 2832-2859. Specifically, `statusMessage = b[n+1:]` where `n` is likely the position of the space after the status code. The parser reads the status line from the buffer. In HTTP, the status line is terminated by CRLF. Standard HTTP parsing (and fasthttp's parser) splits the line at the first CR/LF. Therefore, the `statusMessage` extracted from a raw network buffer will never contain CR or LF characters, as these characters define the end of the line. Any subsequent CR/LF would be part of the headers, not the reason phrase.\n\n2. **Public API**: The public API `SetStatusMessage` accepts a `[]byte` or `string`. If an application developer manually sets a malicious status message, that is a flaw in the application's logic (violating the assumption that status messages are safe), not a vulnerability in the library's parsing of untrusted input. The threat model focuses on parsers receiving adversarial payloads. Since the parser cannot produce a `statusMessage` with embedded CR/LF from raw network input, the `formatStatusLine` function, when fed with parser-generated data, is safe.\n\n3. **Conclusion**: The `statusText` passed to `formatStatusLine` from the parsing path (handling untrusted network input) is structurally guaranteed to not contain CR/LF. The `protocol` is typically a constant or also parsed safely. Thus, an external attacker cannot trigger response splitting or header injection via the parser. The bug is not reachable from untrusted network input.\n\nCRUX: The HTTP parser in fasthttp (specifically the code around `header.go:2832-2859`) extracts the status message from the raw buffer up to the first CRLF terminator, ensuring that `statusMessage` never contains CR or LF characters when derived from network input.\nGREP: statusMessage = b[n+1:]",
    "elapsed": 54.1,
    "tokens": 8264,
    "tokens_in": 7721,
    "tokens_out": 543,
    "cost_usd": 0.00487182,
    "file": "status.go",
    "round": 3,
    "grep_used": true,
    "grep_results": "GREP `statusMessage = b[n+1:] (simplified to: statusMessage)`:\n```\nstatus.go:8:\tstatusMessageMin = 100\nstatus.go:9:\tstatusMessageMax = 511\nstatus.go:85:\tstatusMessages = []string{\nstatus.go:156:\tif statusCode < statusMessageMin || statusCode > statusMessageMax {\nstatus.go:160:\tif s := statusMessages[statusCode]; s != \"\" {\nheader.go:54:\tstatusMessage   []byte\nheader.go:141:\treturn h.statusMessage\nheader.go:145:func (h *ResponseHeader) SetStatusMessage(statusMessage []byte) {\nheader.go:146:\th.statusMessage = initHeaderValueBytes(h.statusMessage, statusMessage)\nheader.go:985:\th.statusMessage = h.statusMessage[:0]\nheader.go:1054:\tdst.statusMessage = append(dst.statusMessage, h.statusMessage...)\nheader.go:2832:\tstatusMessage := []byte(nil)\nheader.go:2835:\t\tstatusMessage = b[n+1:]\nheader.go:2858:\tif len(statusMessage) > 0 {\nheader.go:2859:\t\th.SetStatusMessage(statusMessage)\nhttp_test.go:1277:\t// set StatusNoContent with statusMessage\n```"
  },
  {
    "finding_title": "HTTP status-line control-character injection",
    "verdict": "INVALID",
    "reasoning": "The vulnerability report claims that `formatStatusLine` allows CR/LF injection because it does not sanitize `protocol` or `statusText`. To be a valid vulnerability under the provided threat model, an external attacker must be able to influence these parameters via untrusted input (e.g., a malicious HTTP response passed to a fasthttp client). \n\nI traced the data flow for `statusText`: \n1. When fasthttp parses an HTTP response from the network, it calls `parseResponse` in `http.go`, which processes the status line. \n2. The parsing logic extracts the status message into `h.statusMessage`. \n3. The critical constraint is the definition of an HTTP status line: it is a sequence of bytes terminated by CRLF (`\\r\\n`). The parser reads from the current buffer position up to the first occurrence of CRLF. \n4. Therefore, the substring stored in `statusMessage` is structurally guaranteed to exclude the terminating CRLF sequence and any subsequent lines. An attacker cannot inject a CR or LF *into* the reason phrase itself without terminating the line, which would cause that content to be parsed as headers (where fasthttp applies its own validation/filtering) rather than part of the status line. \n5. `formatStatusLine` is a serializer. It receives `statusText` which, when originating from parsed network input, contains no CR/LF. \n6. The only way `statusText` could contain CR/LF is if the application developer explicitly calls `SetStatusMessage` with such a string. This falls under \"misuse that violates a documented precondition\" or application-level logic error, which is out of scope for a library vulnerability where the attacker is defined as controlling the *untrusted payload* passed through parsers. The library's parser correctly isolates the status line from the rest of the stream, preventing the injection vector described in the report. \n\nThus, the bug is not reachable via untrusted network input because the parsing boundary (CRLF) prevents the attacker from placing control characters inside the `statusText` field that is later serialized.\n\nCRUX: The HTTP status line parser splits on CRLF, so the extracted statusMessage (reason phrase) structurally cannot contain CR or LF characters when derived from network input.\nGREP: statusMessage = b[n+1:]",
    "elapsed": 131.7,
    "tokens": 8122,
    "tokens_in": 7621,
    "tokens_out": 501,
    "cost_usd": 0.004703819999999999,
    "file": "status.go",
    "round": 4,
    "grep_used": true,
    "grep_results": "GREP `statusMessage = b[n+1:] (simplified to: statusMessage)`:\n```\nstatus.go:8:\tstatusMessageMin = 100\nstatus.go:9:\tstatusMessageMax = 511\nstatus.go:85:\tstatusMessages = []string{\nstatus.go:156:\tif statusCode < statusMessageMin || statusCode > statusMessageMax {\nstatus.go:160:\tif s := statusMessages[statusCode]; s != \"\" {\nheader.go:54:\tstatusMessage   []byte\nheader.go:141:\treturn h.statusMessage\nheader.go:145:func (h *ResponseHeader) SetStatusMessage(statusMessage []byte) {\nheader.go:146:\th.statusMessage = initHeaderValueBytes(h.statusMessage, statusMessage)\nheader.go:985:\th.statusMessage = h.statusMessage[:0]\nheader.go:1054:\tdst.statusMessage = append(dst.statusMessage, h.statusMessage...)\nheader.go:2832:\tstatusMessage := []byte(nil)\nheader.go:2835:\t\tstatusMessage = b[n+1:]\nheader.go:2858:\tif len(statusMessage) > 0 {\nheader.go:2859:\t\th.SetStatusMessage(statusMessage)\nhttp_test.go:1277:\t// set StatusNoContent with statusMessage\n```"
  },
  {
    "finding_title": "HTTP status-line control-character injection",
    "verdict": "INVALID",
    "reasoning": "The report claims that `formatStatusLine` is vulnerable to control-character injection (response splitting) if the `protocol` or `statusText` arguments contain CR/LF. To be a valid security vulnerability under the provided threat model, an external attacker must be able to influence these inputs via untrusted network payloads (e.g., a malicious HTTP response passed to a fasthttp client). \n\n1. **Data Flow Analysis**: The `statusText` argument to `formatStatusLine` is typically derived from the parsed HTTP status line. In `header.go`, the function `parseResponse` (or similar parsing logic) extracts the status message. Specifically, at line 2835, `statusMessage = b[n+1:]` assigns the bytes of the reason phrase. \n2. **Parser Boundary**: The HTTP status line is defined by RFC 7230 as `HTTP-version SP status-code SP reason-phrase CRLF`. The parser identifies the end of the status line at the first CRLF sequence (`\\r\\n`). Therefore, the `statusMessage` variable is a slice of the buffer bounded by the start of the line and the first CRLF. \n3. **Control Character Impossibility**: By definition, a CR (`\\r`, 0x0d) or LF (`\\n`, 0x0a) character terminates the status line. Consequently, the extracted `statusMessage` slice can never contain a CR or LF character, as these bytes mark the boundary between the status line and the headers. If an attacker attempts to inject `\\r\\n` into the reason phrase, the parser will treat that as the end of the status line and the beginning of the headers. The injected content will be parsed as headers (where fasthttp has its own validation, though header injection in headers is a different, known but often mitigated or out-of-scope issue in this specific context of *status line* splitting). \n4. **Unreachable Vector**: Since the `statusText` passed to `formatStatusLine` from the parsing path is structurally guaranteed to exclude CR/LF characters, an attacker cannot trigger response splitting via the untrusted network input path. \n5. **Other Inputs**: The `protocol` is also part of the status line (first token) and is similarly bounded by spaces and the CRLF terminator, making it safe from embedded CRLFs from network input. \n\nThus, the alleged vulnerability is not reachable via untrusted network input because the parsing logic enforces the boundary that prevents the injection of control characters into the `statusText` field that is later serialized. Any injection would require the application developer to explicitly call `SetStatusMessage` with malicious content, which falls under misuse of the API or application logic error, not a library vulnerability exploitable by an external attacker via protocol parsing.\n\nCRUX: The HTTP parser splits the status line on the first CRLF sequence, structurally guaranteeing that the extracted `statusMessage` (reason phrase) cannot contain CR or LF characters when derived from raw network input.\nGREP: statusMessage = b[n+1:]",
    "elapsed": 366.2,
    "tokens": 8825,
    "tokens_in": 8164,
    "tokens_out": 661,
    "cost_usd": 0.005411879999999999,
    "file": "status.go",
    "round": 5,
    "grep_used": true,
    "grep_results": "GREP `statusMessage = b[n+1:] (simplified to: statusMessage)`:\n```\nstatus.go:8:\tstatusMessageMin = 100\nstatus.go:9:\tstatusMessageMax = 511\nstatus.go:85:\tstatusMessages = []string{\nstatus.go:156:\tif statusCode < statusMessageMin || statusCode > statusMessageMax {\nstatus.go:160:\tif s := statusMessages[statusCode]; s != \"\" {\nheader.go:54:\tstatusMessage   []byte\nheader.go:141:\treturn h.statusMessage\nheader.go:145:func (h *ResponseHeader) SetStatusMessage(statusMessage []byte) {\nheader.go:146:\th.statusMessage = initHeaderValueBytes(h.statusMessage, statusMessage)\nheader.go:985:\th.statusMessage = h.statusMessage[:0]\nheader.go:1054:\tdst.statusMessage = append(dst.statusMessage, h.statusMessage...)\nheader.go:2832:\tstatusMessage := []byte(nil)\nheader.go:2835:\t\tstatusMessage = b[n+1:]\nheader.go:2858:\tif len(statusMessage) > 0 {\nheader.go:2859:\t\th.SetStatusMessage(statusMessage)\nhttp_test.go:1277:\t// set StatusNoContent with statusMessage\n```"
  }
]