Flapjack, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the security team.

Overview: A potential Use-After-Free vulnerability exists in the browser process due to improper handling of std::set iterators in ServiceWorkerVersion::OnTimeoutTimer. When multiple requests time out simultaneously, error callbacks can synchronously trigger the cancellation of other timed-out requests, leading to the use of a dangling iterator. This heap corruption occurs in the privileged browser process and could potentially lead to a sandbox escape.

Affected files:

• content/browser/service_worker/service_worker_version.cc
• content/browser/service_worker/service_worker_version.h

Estimated timestamp from git blame: 2025-08-26

Summary

A potential Use-After-Free (UAF) vulnerability has been identified in ServiceWorkerVersion::OnTimeoutTimer within content/browser/service_worker/service_worker_version.cc. The flaw occurs when multiple Service Worker requests time out simultaneously. During timeout processing, std::set iterators are invalidated early, but can still be accessed if an error callback synchronously finishes another timed-out request.

Because this vulnerability triggers a UAF on internal libc++ tree nodes, it bypasses MiraclePtr (BRP) protections. Successful exploitation could lead to arbitrary memory read/write and a sandbox escape from the browser process.

Root Cause Analysis

The ServiceWorkerVersion class tracks active requests in inflight_requests_ (a base::IDMap) and their expiration times in request_timeouts_ (a std::set). Each InflightRequest stores a timeout_iter pointing to its corresponding entry in the request_timeouts_ set.

When the timeout timer fires, ServiceWorkerVersion::OnTimeoutTimer executes in two phases:

1. First Loop (Iterator Invalidation): It iterates through request_timeouts_, copies the data of all expired requests into a vector, and immediately erases them from the set (it = request_timeouts_.erase(it)). This frees the underlying red-black tree nodes and invalidates the timeout_iter pointers stored in the corresponding InflightRequest objects.
2. Second Loop (Callback Execution): It loops through the copied data and calls MaybeTimeoutRequest, which runs the error_callback for each timed-out request.

A developer comment explicitly acknowledges that these error callbacks can “synchronously finish another request”. If the error callback for Request A synchronously triggers the completion or cancellation of Request B (e.g., an external keep-alive request or an associated fetch/sync request), ServiceWorkerVersion::FinishRequest(B) is invoked.

If Request B also timed out in the same cycle, it has not yet been processed by the second loop. Therefore, it still exists in inflight_requests_. When FinishRequest (via FinishRequestWithFetchCount) handles Request B, it executes request_timeouts_.erase(request->timeout_iter);.

Since Request B’s timeout_iter was already invalidated during the first loop, this results in a UAF. The std::set::erase function attempts to read from and rebalance the freed node, corrupting the heap.

Potential Attack Steps

Note: These are suggested steps based on code analysis; our tooling agent does not yet have the ability to run working exploit code.

1. From a compromised renderer or malicious website, register a Service Worker.
2. Trigger two concurrent requests that are coupled in a way where the failure of one triggers the cancellation of the other (e.g., an Extension event and its associated EXTERNAL_REQUEST keep-alive).
3. Intentionally stall the Service Worker’s execution (e.g., via infinite loops or unresolved Promises) to ensure both requests hit their maximum expiration time simultaneously.
4. The browser’s timeout timer fires. OnTimeoutTimer erases both requests from the request_timeouts_ set, freeing both nodes.
5. OnTimeoutTimer fires the error callback for the first request.
6. The callback synchronously finishes the second request. FinishRequest attempts to erase the second request from the request_timeouts_ set using its dangling iterator.
7. By grooming the heap beforehand, the attacker reclaims the freed std::set node. When the erase tree-rebalancing algorithm executes, it processes the attacker-controlled memory, leading to arbitrary memory read/write and eventual Remote Code Execution (RCE).

Suggested Fix

To prevent the dangling iterator dereference, ensure that when an element is erased from request_timeouts_, the timeout_iter in the corresponding InflightRequest is properly invalidated.

1. Modify InflightRequest to handle an invalid iterator state (e.g., by setting it to request_timeouts_.end()).
2. In OnTimeoutTimer, when erasing elements from the set, look up the InflightRequest in inflight_requests_ and update its timeout_iter to request_timeouts_.end().
3. In FinishRequestWithFetchCount, check if request->timeout_iter != request_timeouts_.end() before attempting to erase it.

Evaluated with Chrome root at commit: 09ec9e7cc4d24823d20b6d37cf3d282734f6bf0f

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.