UPSTREAM FIX
magento2-40349: Built-in FPC keys still containing marketing params after stripping
Community fix magento2-40349 merged into magento/magento2 on 2026-05-12, not in a release yet; applies cleanly to 2.4.9.
Fixes built-in FPC keys still containing marketing params after stripping edited
- Pull request title
- Marketing params added back into query used for built-in FPC identifier creation
- Pull request
- magento/magento2#40349
- Issues
- #40350 human
- Author
- @NateSwanson7
- Merged
- 2026-05-12
- Fixed in
- no release yet
- Reported on
- —
- Categories
- Cache
- Components
- magento/framework, magento/module-page-cache
Labels
- Area
- Framework
- Component
- PageCache
- Priority
- P2
- Severity
- —
- Reported on (labels)
- 2.4.x
Issue
Title and steps come from the upstream issue and pull request.
Description
- Marketing parameters (e.g., utm_*, gclid, fbclid, etc.) are stripped by regex
into a sanitized $url, but then reintroduced during cache identifier generation.
into a sanitized $url, but then reintroduced during cache identifier generation.
Steps to reproduce
1. Enable built-in Full Page Cache mode.
2. Visit any storefront page with marketing/tracking parameters included in the URL, e.g.:
https://example.com/?utm_source=test&utm_medium=cpc&gclid=TEST123&foo=bar
3. Observe that Magento applies regex stripping patterns inside
Magento\Framework\App\PageCache\Identifier::getValue() to remove marketing parameters.
4. However, inspect the final cache key (e.g. via debugging
or enabling cache debug mode):
- The sanitized URL (with tracking params removed) is used only for generating the base URL.
- The
5. As a result, the cache identifier still contains all original query parameters,
including marketing parameters that were intended to be stripped.
6. This leads to different FPC entries for equivalent URLs that differ only by
marketing/tracking parameters.
2. Visit any storefront page with marketing/tracking parameters included in the URL, e.g.:
https://example.com/?utm_source=test&utm_medium=cpc&gclid=TEST123&foo=bar
3. Observe that Magento applies regex stripping patterns inside
Magento\Framework\App\PageCache\Identifier::getValue() to remove marketing parameters.
4. However, inspect the final cache key (e.g. via debugging
Identifier::getValue()or enabling cache debug mode):
- The sanitized URL (with tracking params removed) is used only for generating the base URL.
- The
$query portion of the FPC identifier is rebuilt using the original request’s query array.5. As a result, the cache identifier still contains all original query parameters,
including marketing parameters that were intended to be stripped.
6. This leads to different FPC entries for equivalent URLs that differ only by
marketing/tracking parameters.
Expected result
- Marketing/tracking parameters defined in
(e.g., utm_*, gclid, fbclid, msclkid, etc.) should be removed before building
the Full Page Cache identifier.
- The query string used in the identifier should be reconstructed from the
sanitized URL (after marketing params are removed), not from the original
request's query array.
- URLs that differ only by ignored marketing parameters should produce the
same built-in FPC cache key.
getMarketingParameterPatterns() (e.g., utm_*, gclid, fbclid, msclkid, etc.) should be removed before building
the Full Page Cache identifier.
- The query string used in the identifier should be reconstructed from the
sanitized URL (after marketing params are removed), not from the original
request's query array.
- URLs that differ only by ignored marketing parameters should produce the
same built-in FPC cache key.
Actual result
- Marketing parameters (e.g., utm_*, gclid, fbclid, etc.) are stripped by regex
into a sanitized $url, but then reintroduced during cache identifier generation.
- In
which contains the full original query string including all marketing parameters.
- Therefore, the resulting cache key still includes marketing parameters,
causing cache fragmentation and defeating the purpose of the new
marketing-parameter-stripping logic.
- Only the *order* of query parameters is normalized (via ksort()),
but the actual marketing parameters are not removed.
into a sanitized $url, but then reintroduced during cache identifier generation.
- In
reconstructUrl(), $query is rebuilt from:$this->request->getUri()->getQueryAsArray()which contains the full original query string including all marketing parameters.
- Therefore, the resulting cache key still includes marketing parameters,
causing cache fragmentation and defeating the purpose of the new
marketing-parameter-stripping logic.
- Only the *order* of query parameters is normalized (via ksort()),
but the actual marketing parameters are not removed.
Taken from the upstream issue.
Code match per tag
Each tag was checked with git apply --check against that tag's files. A clean match means the change applies; it is not a test result. Tags that already contain the fix are marked.
| Line | Code match per tag | Tests |
|---|---|---|
| 2.4.6 | 2.4.6 file-missing 2.4.6-p1 file-missing 2.4.6-p2 file-missing 2.4.6-p3 file-missing 2.4.6-p4 file-missing 2.4.6-p5 file-missing 2.4.6-p6 file-missing 2.4.6-p7 file-missing 2.4.6-p8 file-missing 2.4.6-p9 file-missing 2.4.6-p10 file-missing 2.4.6-p11 file-missing 2.4.6-p12 file-missing 2.4.6-p13 file-missing 2.4.6-p14 file-missing 2.4.6-p15 file-missing | 2.4.6: no test data 2.4.6-p1: no test data 2.4.6-p2: no test data 2.4.6-p3: no test data 2.4.6-p4: no test data 2.4.6-p5: no test data 2.4.6-p6: no test data 2.4.6-p7: no test data 2.4.6-p8: no test data 2.4.6-p9: no test data 2.4.6-p10: no test data 2.4.6-p11: no test data 2.4.6-p12: no test data 2.4.6-p13: no test data 2.4.6-p14: no test data 2.4.6-p15: no test data |
| 2.4.7 | 2.4.7 conflict 2.4.7-p1 conflict 2.4.7-p2 conflict 2.4.7-p3 conflict 2.4.7-p4 conflict 2.4.7-p5 conflict 2.4.7-p6 conflict 2.4.7-p7 conflict 2.4.7-p8 conflict 2.4.7-p9 conflict 2.4.7-p10 conflict | 2.4.7: no test data 2.4.7-p1: no test data 2.4.7-p2: no test data 2.4.7-p3: no test data 2.4.7-p4: no test data 2.4.7-p5: no test data 2.4.7-p6: no test data 2.4.7-p7: no test data 2.4.7-p8: no test data 2.4.7-p9: no test data 2.4.7-p10: no test data |
| 2.4.8 | 2.4.8 conflict 2.4.8-p1 conflict 2.4.8-p2 conflict 2.4.8-p3 conflict 2.4.8-p4 conflict 2.4.8-p5 conflict | 2.4.8: no test data 2.4.8-p1: no test data 2.4.8-p2: no test data 2.4.8-p3: no test data 2.4.8-p4: no test data 2.4.8-p5: no test data |
| 2.4.9 | 2.4.9 clean | 2.4.9: test could not run before the patch, passes afterunit: could not run before, passes after |
Triage
Model @cf/cloudflare/clef. Probability this is a bug fix: 97.7%. Probability it is security relevant: 0.8%.
Show the model's answers and probabilities
| Question | Answer | Probabilities | Confidence |
|---|---|---|---|
| Change kind | bugfix | bugfix 95.3%, refactor 2.5%, tests_only 0.9%, feature 0.6%, dependency 0.4%, docs_only 0.4% | 89.0% |
| Area | framework | framework 96.9%, other 0.8%, frontend 0.7% | 93.0% |
| Reported version | unspecified | unspecified 34.8%, 2.4.7-p4 1.6%, 2.4.6 1.4% | 11.7% |
| Scope | 1.02 of 2 | 1 55.9%, 2 23.2%, 0 21.0% | 11.4% |
| Risk | 0.58 of 2 | 1 47.9%, 0 46.9%, 2 5.2% | 17.9% |
| Worth backporting | 1.29 of 2 | 2 51.1%, 1 26.7%, 0 22.2% | 7.3% |
Download
For cweagans/composer-patches, choose a version below and download the bundle. Copy its magento2-40349/ folder into patches/composer/, merge composer.patches.json into composer.json, then run composer install. Test files are always removed; paths are relative to each package root, using the default -p1 level.
Bundle README (what the ZIP ships)
# magento2-40349 Community fix merged upstream into magento/magento2, adapted by magento.watch. This is not a patch published by Adobe. Pull request: https://github.com/magento/magento2/pull/40349 Issue: https://github.com/magento/magento2/issues/40350 Author: @NateSwanson7 Source commit: d127632528a875ded6fa05f7e84e68367191ce0a Modifications: test files and documentation removed, paths rewritten relative to each Composer package. Licence: OSL-3.0 / AFL-3.0, as the original Magento Open Source code. Maintainer: Łukasz Bajsarowicz (@lbajsarowicz)
Licence: Magento Open Source code under OSL-3.0 and AFL-3.0. The bundle carries the original author, source commit and the list of modifications.
