Question about Zed's usability

[Matheus Macêdo]

Hello everyone, I have a question about Zed Attack Proxy.

I completed a PortSwigger lab on the Server-Side Vulnerabilities module, specifically on File Upload - WebShell, and the lab instructions were for Burp Suite. Using Zed Attack Proxy did not produce the same results. The instructions called for using the parameter alteration function on the file extension containing the malicious script, thus bypassing the limited security barrier and making the webshell file be accepted as a valid file. However, Zed Attack Proxy does not allow the file to be sent after resending the request with the malicious script altering its extension in the POST request metadata to upload it. In this context, I needed to change the file extension before sending it and I couldn't understand why the interception, resending, and request editing functions of Zed Attack Proxy work differently from Burp Suite. Could someone help me understand this?

I work as an Information Security and Infrastructure Analyst and also as a Back-end developer for a SaaS startup in the delivery sector in Brazil, and I would like to expand my skills and network by following and contributing to the community! Greetings to all!

My LinkedIn profile:

 https://www.linkedin.com/in/matheus-mbo/

[kingthorin+zap]

> However, Zed Attack Proxy does not allow the file to be sent after resending the request with the malicious script altering its extension in the POST request metadata to upload it. In this context, I needed to change the file extension before sending it 

What lead you to this conclusion? What have you tried/done?

> I couldn't understand why the interception, resending, and request editing functions of Zed Attack Proxy work differently from Burp Suite

Because it isn't Burp and isn't trying to be. That's kinda like asking why Linux doesn't behave the same as Windows. 

[ar]

Subject: Feature Request/Bug: multipart/form-data binary manipulation issues in Requester/Resend vs Burp Suite Repeater during File Upload testing

Body:

Hi ZAP Development Team,

I am a security researcher utilizing OWASP ZAP for server-side vulnerability assessments, specifically focusing on File Upload restrictions and WebShell execution bypasses (similar to PortSwigger's Web Security Academy labs).

I have encountered a significant behavioral difference between ZAP's Requester (Resend/Manual Request Editor) and Burp Suite's Repeater when manipulating metadata in multipart/form-data POST requests.

The Issue:

When attempting to bypass file upload filters by manually altering the file extension or filename within the raw HTTP request body (e.g., changing filename="exploit.php" to filename="exploit.php.jpg" or injecting a null byte %00), ZAP's Manual Request Editor often fails to properly submit the altered request or corrupts the binary payload boundary definitions.

Unlike Burp Repeater, which dynamically and transparently updates the request state and binary/text conversions of the multipart boundary length upon string editing, ZAP's editor seems to strictly lock or miscalculate the Content-Length or binary stream of the multipart body when a user modifies the raw text fields prior to clicking "Send". This makes solving strict File Upload bypass labs unreliable or impossible without dropping back to ZAP's HUD/Breakpoints for every single test.

Proposed Solution / Feature Request:

Can we implement a more robust or intelligent multipart/form-data automatic parsing mode within the Manual Request Editor / Requester?

• The editor should dynamically recalculate exact Content-Length and preserve strict multipart boundaries whenever raw text mutations (like altering filenames, content-types, or file signatures) are executed by the researcher inside the text area.
• Ensure that hex/null-byte injections (exploit.php%00.jpg) within raw multipart text forms are transmitted natively without being double-encoded or mangled during transmission.

ZAP is a phenomenal open-source tool, and fixing this core request-mutation behavior would immensely bridge the gap for researchers transitioning from commercial suites to ZAP for advanced server-side exploitation.

Best regards, ar

вс, 13 сент. 2026 г. в 04:09, kingthorin+zap <kingt...@gmail.com>:

--
ZAP by Checkmarx: https://www.zaproxy.org/
---
You received this message because you are subscribed to the Google Groups "ZAP User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zaproxy-users/d40357d3-6c92-483c-850a-aef41084d8adn%40googlegroups.com.

[!]

Encountered same/similar

[Simon Bennetts]

Its probably these bugs:

• https://github.com/zaproxy/zaproxy/issues/7976
• https://github.com/zaproxy/zaproxy/issues/9375

Cheers,

Simon