#17371·mautic

Form submissions write tracking cookies before consent; kiosk mode does not suppress them

Author: Daniel454545Created Sep 14, 2026Updated Sep 16, 2026
LabelsT1bugprivacy

Mautic Series

7.1.x series (not supported)

Mautic installed version

7.1.3

Way of installing

Other (please specify if relevant in the bug report)

PHP version

8.4.25

What browsers are you seeing the problem on?

Chrome

What happened?

Version note: I only have 7.1.3 available to test against. I could not find anything in the relevant code path that suggests this changed in a later release, and the audit in #17311 does not list the form submission path among the callers of isRequestTrackable() either. Anyone running a current version can confirm or rule this out in about two minutes using the steps above.

Related to #17311 (milestone 1a, privacy audit). Two items in the audit look incomplete, and a runtime test on 7.1.3 disagrees with the user documentation.

Gap 1: the form submission surface is missing from "Tracking cookies set before consent"

The audit lists mautic_device_id, mtc_id and mautic_referer_id as written for any anonymous visitor "on a tracked page, landing page, mtracking.gif pixel, tracked link or asset link, with no consent check". Form submissions are not in that list, although the surface table records form submissions as not depending on mtc.js and as able to persist activity.

Measured on 7.1.3: submitting a form writes mautic_device_id (1 year) and mtc_id (session) with no consent check. Reproduced on the public form page /form/, so no embed, no CDN, no iframe and no second domain are involved. Cookies appear only after submission, not on page load, which locates the write in the submission handling rather than in generic page-hit tracking.

mautic_referer_id is not written on this path, unlike on the /r/ redirect path — two different code paths with two different cookie sets.

Gap 2: kiosk mode is described without reference to cookies

The audit describes kiosk mode only in terms of contact logic: no device-history association, no tracked-contact merge, progressive profiling disabled, submission record and IP still recorded. It says nothing about cookies.

The user documentation does: it states that in kiosk mode Mautic "turns off tracking of Contacts created through the Form, so that the Form doesn't generate cookies or associate any IP address with the Contact record", and that Mautic "doesn't track the device submitting the Form". The original implementation (#253) had the same intent.

On 7.1.3 the cookie part of that guarantee does not hold. Kiosk mode is partially working — each submission creates a new contact instead of merging, so the setting is read and applied — but mautic_device_id and mtc_id are still written.

This matters beyond the docs: the community RFC on cookie management (forum thread 27801) treats kiosk mode as the mitigation for Problem 5, form submissions setting cookies without a consent step. If the audit's taxonomy records that surface as mitigable, it currently is not.

How can we reproduce this issue?

  1. Create a form with an email field and a "create/update contact" submit action.
  2. Set Kiosk mode = Yes. Save.
  3. Open https://<mautic-host>/form/<id> in a fresh guest or incognito profile.
  4. DevTools, Application, Cookies: no Mautic cookies present.
  5. Submit the form.
  6. Check the cookies again.

Expected, per the documentation: no tracking cookies. Actual:

mautic_device_id | random device id | ~1 year | Secure, not HttpOnly, SameSite=None mtc_id | id of the newly created contact | Session | Secure, not HttpOnly, SameSite=None

Each submission in a fresh profile produced a new device id and a new contact id, as expected for kiosk mode.

Also reproduced with the form embedded via generate.js on an external domain, both with and without a "Redirect to URL" post-submit action. The behaviour is identical in all three variants, so embedding, CDN delivery and post-submit redirects are ruled out as causes.

DNT is honoured on this path

Runtime check, same form and same procedure, with Do Not Track enabled in Chrome: no cookies are written. So IpLookupHelper::isRequestTrackable() is reached on the form submission path as well, even in kiosk mode, and the surface is covered by the 7.2 consent work in that respect.

That may be worth recording explicitly in the coverage table, since the form submission path is not among the callers listed in the audit.

It does not change the two gaps above: without a DNT or GPC header the cookies are written with no consent step, and kiosk mode does not prevent it.

``

Relevant log output

bash

Code of Conduct

  • I confirm that I have read and agree to follow this project's Code of Conduct



Care about this issue? Want to get it resolved sooner? If you are a member of Mautic, you can add some funds to the Bounties Project so that the person who completes this task can claim those funds once it is merged by a member of the core team! Read the docs here.