Magento Open Source 2.4.7 adds PHP 8.3 support plus quality and performance fixes. See what's new and whether it's time to update your store.
On this page
Magento Open Source 2.4.7 release notes
Magento Open Source 2.4.7 introduces support for PHP 8.3, enhancing performance and compatibility. This release incorporates numerous quality fixes and enhancements, addressing various issues reported by users and developers. Core Composer dependencies and third-party libraries have been updated to their latest versions, ensuring optimal functionality and security.
Magento Open Source 2.4.7 highlights
Security enhancements
This release incorporates the same essential security fixes and platform security enhancements found in Adobe Commerce 2.4.6-p5, 2.4.5-p7, and 2.4.4-p8. For detailed information on these resolved issues, please refer to the Adobe Security Bulletin.
To date, there have been no confirmed attacks associated with these vulnerabilities. However, it’s important to acknowledge that certain vulnerabilities could potentially be exploited to gain access to sensitive customer information or compromise administrator sessions. Most of these vulnerabilities necessitate initial access to the Admin panel by an attacker.
As a precautionary measure, we strongly advise you to implement all necessary precautions to safeguard your Admin panel. This includes, but is not limited to, the following efforts:
- IP allowlisting
- two-factor authentication
- use of a VPN
- use of a unique location rather than
/admin - good password hygiene
Additional security enhancements
Limitations on the number of auto-generated coupon codes. Magento Open Source now limits the number of coupon codes that are automatically generated. The default maximum is 250,000. Merchants can use the new Code Quantity Limit configuration option (Stores > Settings:Configuration > Customers > Promotions) to prevent potentially overwhelming the system with many coupons.
Optimization of the default Admin URL generation process. The generation of the default Admin URL has been optimized for increased randomness, which makes generated URLs less predictable.
A new full-page cache configuration setting can help to mitigate the risks associated with the HTTP {BASE-URL}/page_cache/block/esi endpoint. This endpoint supports unrestricted, dynamically loaded content fragments from Commerce layout handles and block structures. The new Handles params size configuration setting sets the value of this endpoint’s handles parameter, which determines the maximum allowed number of handles per API. The default value of this property is 100. Merchants can change this value from the Admin (Stores > Settings:Configuration > System > Full Page Cache > Handles params size).
Added Subresource Integrity (SRI) support to comply with PCI 4.0 requirements for verification of script integrity on payment pages. Subresource Integrity (SRI) support provides integrity hashes for all JavaScript assets residing in the local filesystem. The default SRI feature is implemented only on the payment pages for the Admin and storefront areas. However, merchants can extend the default configuration to other pages.
Changes to Content Security Policy (CSP) – Configuration updates and enhancements to Adobe Commerce Content Security Policies (CSPs) to comply with PCI 4.0 requirements. For details, see Content Security Policies in the Commerce PHP Developer Guide.
The default CSP configuration for payment pages for Commerce Admin and storefront areas is now restrict mode. For all other pages, the default configuration is report-only mode. In releases prior to 2.4.7, CSP was configured in report-only mode for all pages.
Added a nonce provider to allow execution of inline scripts in a CSP. The nonce provider facilitates the generation of unique nonce strings for each request. The strings are then attached to the CSP header.
Added options to configure custom URIs to report CSP violations for the Create Order page in the Admin and the Checkout page in the storefront. You can add the configuration from the Admin or by adding the URI to the config.xml file.
Platform enhancements
PHP 8.3 compatibility. This release introduces support for PHP 8.3. Magento Open Source now supports both PHP 8.3 and 8.2. PHP 8.2 will be supported until its End of Service (EOS) date in December 2025. After December 2025, all merchants running 2.4.7 deployments should migrate to PHP 8.3.
Magento Open Source 2.4.7 is still compatible with PHP 8.1 for upgrade purposes only. PHP 8.1 is not supported and not recommended. Magento Open Source 2.4.7 core code, all bundled extensions, and all Adobe-owned extensions and SaaS services are compatible with PHP 8.3.
RabbitMQ 3.13 support. This release is compatible with the latest version of RabbitMQ 3.13. Compatibility remains with RabbitMQ 3.11 and 3.12, which is supported through August 2024 and December 2024 respectively, but Adobe recommended using Magento Open Source 2.4.7 only with RabbitMQ 3.13.
Varnish cache 7.4 support. This release is compatible with the latest version of Varnish Cache 7.4. Compatibility remains with the 6.0.x and 7.2.x versions, but we recommended using Magento Open Source 2.4.7 only with Varnish Cache version 7.4 or version 6.0 LTS.
- Elasticsearch 8.11 compatibility
- OpenSearch 2.12 and OpenSearch 1.3 support
- Redis 7.2
- The extjs library has been replaced with the latest version of jsTree.
- jquery/fileUpload library has been removed.
- Composer 2.7.x. Compatibility with Composer 2.2.x remains.
GraphQL
Magento Open Source 2.4.7 includes enhanced GraphQL caching abilities, GraphQL schema support for custom attributes, support for headless order cancellation, and improved resolver caching.
More flexible cart management. The clearCart mutation now clears the contents of a specified shopping cart in a single action. It replaces the clearCustomerCart mutation, which has been deprecated.
Improvements in create cart mutations. The createGuestCart mutation has been added to replace the deprecated createEmptyCart mutation. Previously, if you used createEmptyCart, you could not determine whether the cart was for a guest or logged-in customer.
Order items now include product images. OrderItemInterface exposes product images, which permits images to be associated with ordered products and load more efficiently.
Expanded support for resolver caching. The following GraphQL query resolvers are now cacheable in the GraphQL Resolver Results cache, which improves performance when queries are submitted with POST requests:
Magento\CustomerGraphQl\Model\Resolver\Customer::resolveMagento\CustomerGraphQl\Model\Resolver\CustomerAddress::resolveMagento\CustomerGraphQl\Model\Resolver\IsSubscribed::resolveMagento\CatalogGraphQl\Model\Resolver\Product\MediaGallery::resolve
Web API framework
This release introduces two new REST endpoints that provide a workaround for a limitation with the REST API GET and POST V1/products/attributes endpoints. These endpoints return the same value for the is_filterable attribute for both the Filterable(with results) and Filterable(no results) options of the Use in Layered Navigation option. (The is_filterable attribute property is of type Boolean, which does not permit setting this property to Filterable(no results).)
Two new REST endpoints have been implemented as a workaround:
PUT /V1/products/attributes/{attributeCode}/is-filterable/{isFilterable}. Path parameters: attributeCode (String) and isFilterable (int values are: 0 is No; 1 is Filterable (with results); 2 is Filterable (no results)).
GET /V1/products/attributes/{attributeCode}/is-filterable. Path parameters: attributeCode (String).
Frequently Asked Questions
Answers to the questions we hear most often.
Is Magento 2.4.7 still supported?
Yes, for now. Adobe's release lifecycle lists 2.4.7 as released on 9 April 2024 with regular support ending on 9 April 2027, and its latest patch, 2.4.7-p10, arrived on 12 May 2026. So a 2.4.7 store is patched and safe to run today, with under a year of runway left. That is comfortable enough not to panic and short enough that upgrade planning belongs in this year's budget rather than being deferred indefinitely.
Which Magento versions are current in 2026?
Magento Open Source 2.4.9 was released on 12 May 2026 with regular support into May 2029, and 2.4.8 was released on 8 April 2025 with support until 11 April 2028. The 2.4.6 line reaches end of regular support on 11 August 2026, so stores still on it are within weeks of losing security patches. If you are on 2.4.7, you are two releases behind but still supported, which is a good position to plan an upgrade from rather than react to.
What has changed in the platform stack since 2.4.7?
A great deal. Where 2.4.7 introduced PHP 8.3 support, Adobe's supported stack for 2.4.9 is PHP 8.5, Composer 2.10, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Varnish 8 and nginx 1.30. Two changes stand out: Elasticsearch no longer appears in the 2.4.9 matrix at all, and Redis has been replaced by Valkey. Upgrading from 2.4.7 is therefore an infrastructure project as much as an application one.
Should I upgrade to 2.4.8 or wait for the next release?
If you are on 2.4.7 and stable, going to 2.4.9 directly is usually the better use of the effort, because the expensive part of any upgrade is extension compatibility and regression testing rather than the version jump itself. Doing that work once to reach a release supported into May 2029 beats doing it twice. Choose 2.4.8 instead if a critical extension or integration you depend on has no 2.4.9-compatible release yet, which is worth checking before you commit either way.
How urgent are Magento security patches really?
More urgent than most merchants treat them. Sansec found that around 75 percent of Magento and Adobe Commerce stores were still unpatched a week after the fix for CosmicSting, tracked as CVE-2024-34102, and thousands were subsequently breached. This article notes that many vulnerabilities require admin access first, which is true and often used as a reason to delay. It is a weak reason, because admin credentials leak, and the gap between publication and patching is exactly the window attackers work in.
How should I protect the Magento admin panel?
Restrict it before you rely on the login form. Change the admin URL from the default, limit access by IP or put it behind a VPN, enforce two-factor authentication for every account, and remove users who left the project. Then add the boring hygiene: unique passwords, no shared accounts, and a quarterly review of who still needs access. Most Magento compromises that begin with the admin panel begin with a credential that should not have still existed rather than with a clever exploit.
What is the difference between a quality release and a security patch?
Quality releases such as 2.4.7 or 2.4.9 bundle new functionality, dependency upgrades and hundreds of fixes, and generally require testing and sometimes infrastructure changes. Security-only patches, published between quality releases, contain just the security fixes and are designed to apply with minimal disruption so there is no excuse for delay. Knowing which you are looking at determines your response time: a security patch should be assessed within days, while a quality release can be scheduled.
Do I need to upgrade if my store is running fine?
Running fine is not the same as being supported. Once a version passes end of support, newly disclosed vulnerabilities are never patched for it, so the risk grows every month while nothing visibly changes on the storefront. You also gradually lose compatibility with current PHP versions, payment provider SDKs and extension updates, which makes each deferred upgrade larger and more expensive than the one before. The cheapest upgrade is always the one you do while you are still supported.
How long should I budget for the upgrade from 2.4.7?
Weeks rather than days for most mid-market stores, with extension compatibility taking the largest share. The core upgrade command is usually the easy part. The work is auditing third-party modules for compatible releases, reworking customisations that touched changed core code, moving the server stack to the supported versions, regression testing checkout and payments, and rehearsing the deployment. Stores with heavy customisation and many extensions should scope generously rather than optimistically.
Does Magento Open Source get the same security fixes as Adobe Commerce?
Broadly yes for the core platform, which is what this article's note about shared security fixes across the 2.4.6, 2.4.5 and 2.4.4 patch lines reflects. The difference is in features rather than security: Live Search, Product Recommendations and several B2B capabilities are Adobe-hosted services requiring an Adobe Commerce licence and are not available on Open Source. So security parity is real, feature parity is not, and proposals should be explicit about which edition they assume.
How do I test an upgrade without risking the live store?
Upgrade a clone first, using a sanitised copy of the production database. Sanitise before the data leaves production, because a raw dump contains customer names, addresses and order history that should not be distributed to laptops. Then run the journeys that actually generate revenue: search, add to cart, checkout with your payment provider in sandbox, order confirmation emails, and any ERP or shipping integration. Containerised environments make this rehearsal cheap enough to repeat until deployment is uneventful.
How do I stay informed about future releases?
Follow Adobe's security bulletins and the release lifecycle page directly rather than relying on a vendor to tell you. Both list what changed, what is affected and, crucially, the dates each version stops receiving support, which is the information that should drive your roadmap. Set a recurring calendar reminder to check your current version's end of support date once a quarter. Most stores that end up dangerously behind got there through drift, not a decision.
