Confirmed payload-integrity bug
Reviewed master at 886c36d8ebe861aa987059a1744d45b78797baae (v4.7.0). Suggested priority: P2.
build_http_probe_command validates body as a UTF-8 string with a 50,000-byte cap, then passes it to curl using -d. Curl interprets a leading @ as a filename, even when the shell argument is correctly quoted.
This silently sends file contents rather than the supplied string. It can transmit a readable file from the selected execution host to the requested endpoint; the string-length check also does not bound the file bytes. This is not an authority-escalation claim: administrators intentionally control their hosts. The defect is that the operation differs from the caller's explicit payload.
Wire-level reproduction
An isolated fixture created a temporary file containing FIXTURE FILE CONTENT\n, started a disposable loopback HTTP server, and used the production command builder with:
method: POST
body: @<temporary-file-path>
The generated curl command executed against that fixture:
curl exit: 0
Supplied body starts with literal @: True
Received: b'FIXTURE FILE CONTENT'
Exact requested payload transmitted: False
Independently reproduced twice. Only synthetic temporary-file content was used. Existing focused suite: 135 passed.
Production path
BrowserWebTools._handle_http_probe executes the generated command locally or on the selected managed host. POST, PUT and PATCH share this body handling.
Acceptance criteria
- Send
body literally, including leading @, without treating it as a file directive. A literal-data curl option such as --data-raw is worth evaluating rather than adding unnecessary temporary-file machinery.
- Enforce the byte limit against the bytes actually transmitted.
- Verify server-received bytes for leading
@, existing and nonexistent paths, multiline text, UTF-8 and the size boundary, across POST/PUT/PATCH.
- Preserve current shell escaping and host authorization.
Behavior change: accidental implicit file uploads become literal strings, as advertised. Explicit file upload would need its own contract.
Prior issue: #29 concerned insufficient wire-level coverage and was closed as an enhancement. This issue is distinct: the payload bug is now demonstrated, not merely hypothesized from missing tests. No source changes were made.
Confirmed payload-integrity bug
Reviewed
masterat886c36d8ebe861aa987059a1744d45b78797baae(v4.7.0). Suggested priority: P2.build_http_probe_commandvalidatesbodyas a UTF-8 string with a 50,000-byte cap, then passes it to curl using-d. Curl interprets a leading@as a filename, even when the shell argument is correctly quoted.This silently sends file contents rather than the supplied string. It can transmit a readable file from the selected execution host to the requested endpoint; the string-length check also does not bound the file bytes. This is not an authority-escalation claim: administrators intentionally control their hosts. The defect is that the operation differs from the caller's explicit payload.
Wire-level reproduction
An isolated fixture created a temporary file containing
FIXTURE FILE CONTENT\n, started a disposable loopback HTTP server, and used the production command builder with:The generated curl command executed against that fixture:
Independently reproduced twice. Only synthetic temporary-file content was used. Existing focused suite: 135 passed.
Production path
BrowserWebTools._handle_http_probeexecutes the generated command locally or on the selected managed host. POST, PUT and PATCH share this body handling.Acceptance criteria
bodyliterally, including leading@, without treating it as a file directive. A literal-data curl option such as--data-rawis worth evaluating rather than adding unnecessary temporary-file machinery.@, existing and nonexistent paths, multiline text, UTF-8 and the size boundary, across POST/PUT/PATCH.Behavior change: accidental implicit file uploads become literal strings, as advertised. Explicit file upload would need its own contract.
Prior issue: #29 concerned insufficient wire-level coverage and was closed as an enhancement. This issue is distinct: the payload bug is now demonstrated, not merely hypothesized from missing tests. No source changes were made.