← WebKit — 2026-W38
57d9da4c518ba2e2a1ef2d69c64e78be4a73b69a A FormData body should survive collection of its source
severity medium
class UAF
confidence 0.6
signal score 7.77
Source/WebCore/Modules
patch-now
Primitive: FetchBody FormData outliving its source DOMFormData (dangling entry/blob references)
Triage note: FetchBody now stores and propagates (through clone/createProxy) a RefPtr<DOMFormData> m_formDataSource alongside the FormData produced by FormData::createMultiPart(domFormData); deliberately keeping the source alive indicates the derived FormData referenced data owned by the DOMFormData and could dangle after it was destroyed.
Triage note: FetchBody now stores and propagates (through clone/createProxy) a RefPtr<DOMFormData> m_formDataSource alongside the FormData produced by FormData::createMultiPart(domFormData); deliberately keeping the source alive indicates the derived FormData referenced data owned by the DOMFormData and could dangle after it was destroyed.
Structural signals: smartptr_member_added (+6.47), surgical (+1.3)
Commit message
A FormData body should survive collection of its source
https://bugs.webkit.org/show_bug.cgi?id=324258
Reviewed by Youenn Fablet.
FetchBody::extract() turned a DOMFormData into a FormData and then dropped it.
FormData keeps only the blob: URLs of its file entries, so once the DOMFormData
was collected the files went with it. This showed up as flakiness in
multipart/form-data tests (bug 323972), where a Response is built from a
FormData and read back.
Per Fetch the body's source is the FormData object, so keep it: the registry
reference counts registrations, and holding the files keeps the data alive
whether or not anything else still refers to it. clone() copies the source and
createProxy() moves it, matching what each does with the body.
Tests upstream: https://github.com/web-platform-tests/wpt/pull/62715
https://github.com/web-platform-tests/wpt/pull/62738
Canonical link: https://commits.webkit.org/321238@main
Before / after
Loading diff…
On This Page