APSB24-40 (June 2024) fixed CosmicSting, CVE-2024-34102, an unauthenticated XXE that Adobe raised to Priority 1 on July 8, 2024. The same releases made checkout CSP strict by default, which blocks inline scripts on payment pages. That second change is why so many checkouts broke right after patching.
Update (2026-10-16): APSB24-40 is two years old now, but the strict checkout CSP it brought along is still the default on every supported release. For the most recent patch I've written up, see StyleSmuggler and APSB26-146 (September 2026). Also note that Adobe's release naming has moved from
-pNpatch numbers to date-based builds like2.4.9-2026-oct.
How APSB24-40 went from Priority 3 to Priority 1
APSB24-40 looked like a routine patch when Adobe released it on June 11, 2024, as a Priority 3 update (important, but not urgent).
By June 26, Adobe had bumped it to Priority 2, which means install it inside a 30-day window. Then on July 8, it became Priority 1, the highest level, meaning the vulnerability was being actively exploited and the patch should go on as soon as possible (ideally within 72 hours).
That escalation was about CosmicSting, not CSP. CVE-2024-34102 is an XXE (CVSS 9.8) that an unauthenticated attacker can use to read files off the server, including app/etc/env.php and the encryption key inside it. Adobe confirmed it was exploited in the wild in limited attacks, and later attacks chained it with other bugs into full RCE.
If you couldn't take the full security release right away, Adobe also shipped an isolated patch for just this CVE (VULN-27015) in late June 2024, followed by a hotfix on July 17. Adobe's knowledge base article for the isolated patch lists the versions it covers. Either way, rotate your encryption key after patching. A key that was read before you patched can still be used to forge admin tokens after you patch.
The CSP change rode along in the same releases, and it's what turned the patch into a checkout problem.
Understanding CSP
CSP tells the browser which script, style and image sources it may load. Everything else is blocked (or, in report-only mode, logged).
It's one of the most effective defenses against XSS. If an attacker manages to inject a script into your checkout to skim card data, a strict CSP stops the browser from running it, or from sending the data anywhere that isn't on the list.
The trade-off is that CSP is easy to get wrong in both directions. Too strict, and you block legitimate scripts and break parts of your site. Too loose, and it doesn't protect much of anything.
Cautionary note: Google's 2016 research paper showed how ineffective CSP whitelists can be. That's worth knowing, but it doesn't make maintaining proper
csp_whitelist.xmlfiles pointless. Security works best in layers, and every additional layer makes an attack harder. CSP is no exception.
Key changes in APSB24-40
Strict mode on payment pages. Before this change, CSP ran in report-only mode everywhere, including the storefront checkout and admin order creation. A violation got logged, and the content loaded anyway. Now, CSP on those two pages runs in strict (restrict) mode by default, so anything that doesn't match the policy is blocked.
This shipped as the default in Magento 2.4.7, and the June 2024 security releases carried it to the older release lines (magento/magento2#38823 tracks it landing in 2.4.5-p8). So if you're on 2.4.7 or later, this applies to you whether or not you remember APSB24-40.
Inline scripts blocked. Inline scripts are JavaScript embedded directly in the HTML instead of loaded from a file, and they're a common XSS vector. Strict CSP now disables them by default on the storefront checkout and in the admin when creating an order. If you have customizations that rely on inline scripts there, you'll need to rework them to be CSP-compliant.
Checkout now depends on CSP. Magento_Checkout requires magento/module-csp in its composer.json (you can confirm this in vendor/magento/module-checkout/composer.json). If you'd previously disabled the CSP module, expect trouble after patching.
Impact on checkout functionality
Strict CSP makes the checkout a lot harder to skim, but it can also break customizations and third-party extensions.
Say you have a custom loyalty-points feature in the checkout that uses inline JavaScript. After patching, it likely stops working, because inline scripts are now blocked.
Or say a shipping extension injects scripts from the provider's domain to show real-time rates. If that domain isn't in your CSP whitelist, those scripts get blocked too.
Even with no custom code at all, payment gateways, analytics tools and other services ship Magento extensions that inject scripts into checkout. If they weren't updated for the new rules, they break.
These issues weren't theoretical. When this patch was released, many store owners reported problems right after applying it, ranging from minor visual glitches to checkout failures that stopped customers from placing orders.
Challenges for Magento stores
The biggest trap was stores that had disabled the CSP module. Plenty of developers turned it off to get rid of the warnings. With checkout now depending on CSP, applying the update without re-enabling it can take the checkout down entirely.
There are modules out there such as Yireo_DisableCsp and Disable CSP Shim, but I do not recommend installing these types of modules. CSP is just one layer of security, and at times it may not be completely effective, but every additional layer you add improves the overall security of your store. It's much better to learn how CSP works and implement it than to disable it because it's a hassle.
Next is auditing any custom code that relies on inline JavaScript in the checkout. Under strict CSP those scripts are blocked, so you need to find every one and move it into a proper JS file (or whitelist it correctly).
Third-party integrations are the other half. Payment gateways, analytics tools and similar services that inject scripts into checkout need to be CSP-compliant, which sometimes means waiting on the vendor for an update.
Finally, the fast priority jump pushed a lot of stores to patch in a hurry, and rushed patches skip testing. None of this is hard, but it has to be done before you patch prod, not after: test in staging, audit your custom code and integrations, and have a rollback plan ready.
Implementing the patch safely
Start with a full backup of your code and database. That's your safety net if anything goes wrong.
Next, apply the patch to a staging copy of your store first. Staging should match production in installed server software and configuration, so there are no surprises when you deploy. This is a best practice for any update, not just this one.
Before applying the patch, review your current CSP settings. Check whether the CSP module is enabled, and note any custom policies you've set up. That gives you a baseline to compare against after the update.
When you're ready, apply the patch following Adobe's official instructions. If you'd previously disabled the CSP module, re-enable it before testing.
After patching, test the store thoroughly, especially checkout: every payment method, shipping option, discount code and custom feature. Simulate as many real-world scenarios as you can. A patch should never introduce breaking changes on production.
If something breaks, check the browser console and your server logs for CSP violation reports. They tell you which scripts are being blocked and where they come from, so you can fix them or whitelist them. And if production breaks in a way staging didn't, your staging environment isn't doing its job, because it should always be a 1:1 copy of production.
How do I set checkout CSP back to report-only?
If the update broke your checkout and you need it working again right now, you can put checkout CSP back into report-only mode. Treat this as a short-term workaround while you fix the underlying scripts.
The cleanest way is to set it in app/etc/env.php, which deploys with your code and applies the same value in every environment:
'system' => [
'default' => [
'csp' => [
'mode' => [
'storefront_checkout_index_index' => [
'report_only' => '1',
],
'admin_sales_order_create_index' => [
'report_only' => '1',
],
],
],
],
],Merge that into the existing system key (create it if it doesn't exist), then clear the config cache with bin/magento cache:clean config. The admin_sales_order_create_index entry does the same for admin order creation, so drop it if you only need the storefront.
The other option is a direct database write:
INSERT INTO core_config_data (
`scope`,
`scope_id`,
`path`,
`value`
)
VALUES (
'default',
0,
'csp/mode/storefront_checkout_index_index/report_only',
1
)
ON DUPLICATE KEY UPDATE
`value` = VALUES(`value`);Normally you'd use bin/magento config:set to save a config value, but this path has no admin field defined for it, so the command errors out:
The "csp/mode/storefront_checkout_index_index/report_only" path doesn't exist. Verify and try again.That's why you need either env.php or SQL here. If you go the SQL route, wrap it in a data patch inside a custom module so it applies the same way in every environment, rather than running it by hand on each MySQL server.
Is report-only PCI compliant?
Probably not for long. Report-only mode stops the browser from blocking anything on the payment page, inline scripts included, and that runs straight into PCI DSS 4.0 requirements 6.4.3 and 11.6.1, which have been mandatory since March 31, 2025. Those require you to authorize and integrity-check every script on payment pages, and to detect unauthorized changes to them.
Magento's answer to the script integrity part is Subresource Integrity, which 2.4.7 also enabled on payment pages, alongside strict CSP. Running checkout in report-only mode might still pass an audit if you can show other controls that do the same job, but you'll have to document that alternative and defend it. Get back to strict mode as soon as your scripts are fixed.
Best practices for CSP in Magento
First and foremost, keep CSP enabled. Disabling it to avoid dealing with violations removes one of the few defenses you have against checkout skimmers.
Managing CSP is ongoing work. Every new feature, extension or integration can need a policy update, so review your CSP settings as part of your regular maintenance (you do have regular maintenance in place... right?). The Magento CSP Whitelist Generator can generate the XML for you. To add a host by hand, the preview lesson on how to add a host to the content security policy XML walks through it.
When you add a source to your CSP whitelist, be as specific as possible. Avoid wildcards and overly broad domains. The tighter the list, the more your CSP actually prevents.
If you're unsure about a policy change on a non-payment page, test it in report-only mode first. You can review the violation reports for unexpected issues before enforcing it.
Monitor those violation reports regularly, too. They show misconfigurations, but they can also show attempted attacks. A sudden spike in violations from one source can mean someone is trying to inject content into your site.
If you work with a team, make sure everyone understands CSP. It's easy for a developer to add a script that violates the policy if they don't know how it works.
For a general overview of how CSP works in Magento, check out Adobe's Content Security Policies guide and the original Magento CSP architecture document.
CSP is just one layer. Keeping Magento and every extension patched, taking regular backups, and enforcing strong admin authentication all matter just as much.
Key takeaways
- APSB24-40 went to Priority 1 because of CosmicSting (CVE-2024-34102), an exploited XXE. Patch it and rotate your encryption key.
- The same releases made CSP strict on checkout and admin order creation, and blocked inline scripts there. That's the default on 2.4.7 and later.
- Strict CSP breaks non-compliant customizations and extensions, so test checkout thoroughly in staging before patching prod.
- You can set checkout CSP back to report-only in
env.php(or with SQL), but only as a stopgap, since it conflicts with PCI DSS 4.0 payment page requirements.
If you've had a third-party checkout extension that still won't play nice with strict CSP, I'd like to hear which one and how you worked around it.
