[Bug] # Unbounded loop in `setConsentGiven()` causes renderer OOM crash when `mtm_consent_removed` cannot be deleted

[CircleCode]

What happened?

Tracker.setConsentGiven() drains consentRequestsQueue with a for loop
whose bound is re-evaluated on every iteration, while the callee appends to that
same array. If the consent-removed cookie cannot be deleted, the loop never
terminates and the browser tab crashes.

The loop

// js/piwik.js — this.setConsentGiven
deleteCookie(CONSENT_REMOVED_COOKIE_NAME, configCookiePath, configCookieDomain);

var i, requestType;
for (i = 0; i < consentRequestsQueue.length; i++) {
    requestType = typeof consentRequestsQueue[i][0];
    if (requestType === 'string') {
        sendRequest(consentRequestsQueue[i][0], configTrackerPause, consentRequestsQueue[i][1]);
    } else if (requestType === 'object') {
        sendBulkRequest(consentRequestsQueue[i][0], configTrackerPause);
    }
}
consentRequestsQueue = [];

sendRequest() pushes back onto the array being iterated:

// js/piwik.js — sendRequest
function sendRequest(request, delay, callback) {
    refreshConsentStatus();
    if (!configHasConsent) {
        consentRequestsQueue.push([request, callback]);   // <-- grows the loop bound
        return;
    }
    ...
}

// js/piwik.js — refreshConsentStatus
function refreshConsentStatus() {
    if (getCookie(CONSENT_REMOVED_COOKIE_NAME)) {
        configHasConsent = false;
    } else if (getCookie(CONSENT_COOKIE_NAME)) {
        configHasConsent = true;
    }
}

So when the deleteCookie() on the first line fails to remove the cookie,
each iteration re-reads mtm_consent_removed, still finds it, sets
configHasConsent = false, and re-queues the request. i advances by one and
consentRequestsQueue.length grows by one, so the condition never becomes
false.

The loop is synchronous and never yields. It ends only when the renderer
exhausts its heap and the tab is killed.

Why the delete can fail

deleteCookie uses only the currently configured scope:

function deleteCookie(cookieName, path, domain) {
    setCookie(cookieName, '', -129600000, path, domain);
}

Cookie identity is (name, domain, path). Deletion requires the domain and
path attributes to match those the cookie was written with. If
mtm_consent_removed exists under a different scope than the tracker's
current configCookieDomain / configCookiePath, the delete writes a second,
already-expired cookie beside the original and the original survives — so
getCookie(CONSENT_REMOVED_COOKIE_NAME) keeps returning a value indefinitely.

Ways this arises in practice:

1. A changed setCookieDomain between deploys, leaving orphaned cookies from
   the previous configuration that the new configuration cannot delete. These
   persist until expiry — and forgetConsentGiven() sets a 30-year expiry by
   default, so effectively forever.
2. Any configCookiePath change, including the implicit default derived from the
   current page path.
3. Two tracker instances with different cookie domains on the same page — less
   common in general, but this was our case, and it fails within a single page
   load. Tracker A calls setCookieDomain('*.example.com'); tracker B does not
   call it at all. forgetConsentGiven() on A writes domain=.example.com; B's
   setConsentGiven() attempts a host-only delete and fails.

In all cases the misconfiguration is on the site's side. The consequence — a
hard renderer crash rather than degraded tracking — comes from the loop.

Observed consequences

• Tab renders, then becomes unresponsive during load, then crashes.
• Nothing is logged. No exception, no console warning.
• CPU sits at roughly 20%, not 100%, because ~90% of the loop's wall time is
  spent blocked in the synchronous document.cookie IPC. This defeats the usual
  "look for the pegged core" heuristic.
• The DevTools debugger cannot break in and the Performance panel cannot
  finish processing, because the thread never reaches an interruptible point.
  We could only capture this via chrome://tracing, which collects out of
  process.
• Once a visitor has an undeletable cookie, the site is permanently broken for
  them. It cannot self-heal.

Because the failure is silent and unrecoverable, affected visitors are likely to
close the tab rather than report anything — so this may already be occurring
undetected on other installations.

What should happen?

A stale or unexpectedly-scoped mtm_consent_removed cookie should, at worst,
cause tracking requests to be withheld. It should never be able to hang or crash
the page. Specifically:

• setConsentGiven() should complete in bounded time regardless of cookie state.
• A failed cookie deletion should be surfaced to the developer, not silent.
• Requests that cannot be sent should be retried on a later consent event, not
  cause an unbounded retry within the current call.

1. Make the drain loop bounded (primary)

Detach the queue before iterating, so the callee cannot extend the bound:

var pending = consentRequestsQueue;
consentRequestsQueue = [];
for (i = 0; i < pending.length; i++) {
    ...
}

Requests re-queued by sendRequest() then land in a fresh array and are retried
on the next consent event instead of extending the current pass. This change
alone converts the crash into a no-op.

2. Trust the explicit call over the cookie

setConsentGiven() is an explicit statement that consent exists. Having
refreshConsentStatus() immediately override configHasConsent back to false
from a cookie the caller just asked to have deleted is surprising. Consider
skipping the refresh for requests drained by setConsentGiven(), or setting a
flag for the duration of the drain.

3. Verify deletion and warn

After deleteCookie(CONSENT_REMOVED_COOKIE_NAME, ...), re-read the cookie; if
it survives, console.warn naming the attempted domain and path. That single
log line would have saved us a great deal of time, and would let site owners
find the misconfiguration themselves.

4. Reduce document.cookie reads

refreshConsentStatus() runs on every sendRequest(), and each read is a
blocking IPC whose cost scales with cookie-jar size. A short-lived cache of the
parsed cookie string, invalidated on write, would cut this substantially even in
non-pathological cases.

5. Consider a broader delete

Optionally attempt deletion across the current host and its registrable-domain
variants, so scope changes do not leave permanently undeletable orphans.

How can this be reproduced?

change setCookieDomain between 2 deployments

Matomo version

Saas

PHP version

No response

Server operating system

No response

What browsers are you seeing the problem on?

No response

Computer operating system

No response

Relevant log output

Environment

• Matomo Cloud tracker, matomo.js 156 KB (bundling FormAnalytics,
  MediaAnalytics, AbTesting; Heatmap/SessionRecording not enabled)
• Two tracker instances via Google Tag Manager
• Axeptio CMP, pushing consent to GTM on every page load via
  replayInitialGtmEvents
• Nuxt 3 SSR application
• Reproduced in Brave 152 and Chrome 152 on macOS 26.6.2 (arm64)
• Cookie jar 5,271 bytes at time of crash (unusually large, which made the
  per-iteration cost worse and the crash faster)
• Chrome heap limit ~4 GB

What we measured on the real crash

From a chrome://tracing capture with v8.cpu_profiler (Performance panel cannot be used — the thread never reaches an interruptible point):

getCookie — 6,629 ms self time, 40,530 samples, 66.9% of all CPU, in a single profile node
CookieJar::Cookies — 5,947 ms across 13,463 calls (~0.44 ms each), i.e. ~90% of the loop's wall time is blocked in synchronous IPC
One contiguous execution, 3.26 s → 9.92 s, zero gaps above 4.5 ms — a single setConsentGiven() invocation that never yields

Validations

• Read our Contributing Guidelines.
• Follow our Security Policy.
• Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
• The provided steps to reproduce is a minimal reproducible of the Bug.

--

Note: bug reported assisted by Claude after deep anaysis

[des-innocraft]

Hi @CircleCode ,

Thank you for creating this issue and bringing it to our attention — we really appreciate it.

We’ve reviewed and triaged the problem internally. Our team will prioritise investigating and addressing it, and we’ll share an update here as soon as we have more information.

If you have any additional details or questions in the meantime, please feel free to add them here.