# CVE-2023-28322: more POST-after-PUT confusion

Reused libcurl handle that did a PUT then a POST with CURLOPT_POSTFIELDS still invokes the read callback, sending wrong data or use-after-free.

- Payout: hidden
- Severity: low
- Program: Internet Bug Bounty
- Found by: kurohiro
- Disclosed: 2023-06-25
- CVE: CVE-2023-28322
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1991428
- Library page: https://bugbountylibrary.com/r/h1%3A1991428
- Tags: area:oss domain:oss impact:data-leak kind:bounty platform:hackerone sev:low tech:curl technique:regression technique:source-review vuln:info-disclosure vuln:memory-corruption

**Target:** libcurl HTTP(S) transfer handle state machine
**Root cause:** Two separate variable fields tracked HTTP method and behavior, allowing a confused middle state when a reused handle transitions from PUT to POST; the read callback is still used despite CURLOPT_POSTFIELDS being set.
**Steps:**
1. Create a curl handle and issue a PUT request using CURLOPT_READFUNCTION.
2. Reuse the same handle for a POST request with CURLOPT_POSTFIELDS set.
3. Observe libcurl still calls the read callback for data to send instead of using POSTFIELDS.
4. Result: wrong data sent, or use-after-free/segfault if callback buffer is stale.
**How found:** Likely code review of the handle-reuse logic where method and behavior were stored in separate fields, spotting the inconsistent state on PUT-to-POST transition.
**Exploitation:** Requires an application reusing a curl handle across PUT then POST; the confused state causes unintended data from the read callback to be transmitted or memory misuse, potentially leaking data to an unintended recipient.
**Insight:** When auditing HTTP client libraries, test handle reuse across method changes (PUT→POST) and check whether option state (POSTFIELDS vs READFUNCTION) is reset consistently; duplicated state fields are a smell for confused-state bugs.