Security

Adobe Commerce on cloud infrastructure has enforced deadlines. The security and compliance notice lists them per release line and per dependency. The consequence is spelled out: the Admin is suspended while the storefront stays online, or inbound traffic is suspended and the storefront goes offline.

2.4.8 and 2.4.9 are marked "not required at this time" on that page. Open Source and on-premises shops are not subject to these deadlines, but they are not subject to the protection either: Adobe’s lifecycle policy does not provide security or quality fixes for third-party dependencies that reach end of life while a release is still supported, so an on-premises shop that stays on MySQL 8.0 after 2026-04-30 or on Elasticsearch 7.17 after 2026-01-15 carries that risk itself.

Source: Adobe Experience League: Security and compliance notice (enforcement policy)

Source: Adobe Experience League: Software lifecycle policy

Source: NVD: CVE-2022-24086

Source: NVD: CVE-2024-34102

CVE-2025-54236, nicknamed SessionReaper, is described by NVD as improper input validation that allows session takeover, CVSS 3.1 base score 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Adobe fixed it on 2025-09-09 in bulletin APSB25-88 with an emergency hotfix rated priority 2. According to Sansec, a security vendor, the first attacks followed on 2025-10-22, after a research firm published its analysis; Adobe then confirmed abuse and raised the priority to 1, and CISA added the CVE to its catalog on 2025-10-24. The scale figures that circulated (about 31 percent of stores reached on 2025-10-24, 81 percent visited by 2025-11-01) are Sansec’s estimates, not Adobe’s, and Adobe’s own knowledge-base article for the bulletin still says that Adobe had no evidence of exploitation, so it should not be quoted as current. The "unauthenticated remote code execution" description comes from the researchers' analysis (file-based session storage), while NVD says session takeover. The lasting advice from the incident is the same as always: patch within days, and do not store sessions in files on a server that also serves untrusted input; the local store here keeps sessions in Valkey.

Source: NVD: CVE-2025-54236

Source: Sansec: SessionReaper research (vendor)

Adobe published seven bulletins for Commerce and Magento in 2026 up to the check date, and they show the cadence of the new monthly model:

Source: Adobe: Security bulletin APSB26-146

Source: Adobe Experience League: APSB26-146 knowledge base article

The Adobe bulletin pages return an access-denied status to some automated clients, so a link checker may flag them; they open in a browser. NVD and the CISA catalog are the places to check dates and scores mechanically.

What the 2026 sequence teaches:

setup:install takes --backend-frontname. If the option is omitted the installer picks a random URI such as admin_jkhgdfq; Adobe recommends the random value. The local store uses /admin_local. The effect is easy to see with curl: the usual names answer 404, and only the configured one serves the login page.

Output on the local store:

Source: Adobe Experience League: Secure your Commerce site and infrastructure

A hidden URI is not a control by itself (it is discoverable from logs and from the HTML of other pages), it just removes the noise of scripts that probe the default names. With the Add Secret Key to URLs setting every Admin link also carries a per-session key.

Native two-factor authentication (2FA) for the Admin comes from the module Magento_TwoFactorAuth. The first time an Admin user signs in, they must set up every provider that is required, and afterwards one of the configured providers is needed for each sign-in. The 2FA configuration applies to the whole installation, not per website. The providers are Google Authenticator (time-based one-time passwords), Duo Security (SMS and push), Authy and U2F devices such as YubiKey. The settings are under Stores > Settings > Configuration > Security > 2FA.

Source: Adobe Experience League: Security > 2FA configuration reference

Source: Adobe Experience League: Two-factor authentication

Three details matter in practice. First, 2FA also gates the Admin token endpoint: with the module enabled, POST /rest/V1/integration/admin/token answers "Please ask an administrator with sufficient access to configure 2FA first" until the user has set up a provider, so integrations should use integration tokens or an IMS flow instead of admin tokens (see API authentication). Second, stores that enable Adobe Identity Management Services (IMS) authentication have the native 2FA disabled, because IMS handles the authentication; that is the supported way to have no native 2FA, and the module cannot be turned off from the Admin. Third, the local store used for this page has the module disabled with module:disable Magento_TwoFactorAuth, which is the usual local-development shortcut and not a configuration for a real shop.

2.4.9 added blocks that let an Admin user configure additional 2FA providers by verifying with an already configured provider or with an emailed link; that streamlines the setup and needs no action from the merchant.

Stores > Settings > Configuration > Advanced > Admin > Security holds the rest of the Admin account controls. The table lists the fields and the values that the local Mage-OS 3.6.0 store reported with bin/magento config:show.

Source: Adobe Experience League: Security for the Admin

The Admin login can also be protected by a CAPTCHA or Google reCAPTCHA. On the local store admin/captcha/enable and customer/captcha/enable both reported 1. The reCAPTCHA modules (Magento_ReCaptchaAdminUi, Magento_ReCaptchaCheckout, Magento_ReCaptchaWebapiRest, Magento_ReCaptchaWebapiGraphQl and more) cover the forms and, since 2.4.9, the REST and GraphQL customer account creation too: when CAPTCHA is enabled for the Create Account form, API account creation is protected as well, and updateCustomer, updateCustomerV2, contactUs and applyCouponsToCart gained reCAPTCHA. The brute-force rule is that every interface of a protected function needs the protection: a controller behind a challenge and a token mutation without one is still a login oracle.

Give each Admin user the smallest role that does their work (System > Permissions > User Roles). Roles are built from ACL resources declared by modules in etc/acl.xml, and the module section below shows how a custom page and a REST route are tied to a resource. Adobe also recommends locking critical configuration values so that they cannot be changed from the Admin: bin/magento config:set --lock-env <path> <value> writes the value to app/etc/env.php, and --lock-config writes it to app/etc/config.php.

The command that does the opposite deserves a warning: bin/magento app:config:dump copies the whole configuration into config.php and env.php, which locks every value in the Admin and makes the files the source of truth for websites and stores too. It exists for deployment pipelines that import configuration, and it should not be run casually on a live store.

Source: Adobe Experience League: Set configuration values

CSP can run in report-only mode (violations are logged in the browser console or sent to a reporting endpoint, nothing is blocked) or in restrict mode (violations are blocked). Since 2.4.7, payment pages in the storefront and the Admin are in restrict mode and everything else is report-only; before 2.4.7 all pages were report-only. The enforced header for payment pages does not contain 'unsafe-inline' in script-src, so only whitelisted inline scripts run. eval() is still allowed. The mode of an area is the configuration path csp/mode/<area>/report_only (0 restricts, 1 reports) with the area storefront or admin, and a page can have its own mode by using its full action name: the checkout page, the multishipping billing page and the Admin order creation page each declare report_only 0 in their module’s config.xml.

The local store shows this on the wire:

The first line is the home page (report only), the second the checkout (enforced).

Source: Adobe Commerce developer docs: Content security policies

A module that loads a script from a payment widget has to declare the host, in the policy that needs it and nowhere else. Adding a host to default-src when only a script is loaded is the typical overreach. The declaration is etc/csp_whitelist.xml:

Source: Adobe Commerce developer docs: Content security policies

The policies that can be configured are default-src, base-uri, child-src, connect-src, font-src, form-action, frame-ancestors, frame-src, img-src, manifest-src, media-src, object-src, script-src and style-src, and a value is either a host (type="host") or an inline-content hash (type="hash" with algorithm="sha256"). After a cache flush the header of the module’s page contained the two whitelisted hosts (https://widgets.pocketcoffee.example.test in script-src and https://api.pocketcoffee.example.test in connect-src). The schema csp_whitelist.xsd validated this file on Mage-OS 3.6.0; Adobe’s page of backward-incompatible changes for 2.4.9 lists module-csp/etc/csp_whitelist.xsd among removed XSD files, so the xsi:noNamespaceSchemaLocation URN of this file has to be checked against an Adobe 2.4.9 installation before an upgrade (see upgrades).

The module restricts its own page to restrict mode with no inline scripts and no inline event handlers by declaring the page’s action name in etc/config.xml:

Source: Adobe Commerce developer docs: Page specific Content-Security-Policies

The path segment storefront_pcsec_index_index is the area plus the full action name (pcsec_index_index). A controller can also implement Magento\Csp\Api\CspAwareActionInterface and return additional policies from modifyCsp(). The policies keys under a page name (scripts/inline, scripts/event_handlers) control the 'unsafe-inline' and event-handler allowances of that page.

Under a restrictive policy an inline <script> is blocked unless the framework signs it. The class Magento\Framework\View\Helper\SecureHtmlRenderer (the $secureRenderer variable in .phtml templates) does that, and since 2.4.7 the framework provides a per-request nonce through Magento\Csp\Helper\CspNonceProvider::generateNonce(), and the renderer used it on the local store; a hash is the alternative when the content is static. Use renderTag() for script and style tags, renderEventListenerAsTag() for onclick-style attributes and renderStyleAsTag() for style attributes. The roast date badge template of the module uses all three, and the .phtml also shows the three escaping calls used for output:

Source: Adobe Commerce developer docs: Whitelist an inline script or style

The comment /* @noEscape */ before the renderer calls is required by the static test (see The phtml XSS sniff), because the sniff cannot know that the renderer output is already safe. The page that this template belongs to is served with the enforcing header. These are the observed results (the whitelisted hosts and a nonce are present, and the policy has no report-only suffix):

and the renderer added the nonce to every inline script that it produced:

Using inline scripts and styles at all is discouraged in favour of UI components and classes; the renderer exists for the cases where a dynamic value really has to reach inline code. Scripts and styles entered in the Admin (the Scripts and Style Sheets field of the HTML Head section of a design configuration) must be whitelisted by hash as well, which is the reason why a skimmer cannot simply be pasted there on a payment page.

Violations can be sent to an endpoint with csp/mode/<area>/report_uri (Stores > Configuration > Security > Content Security Policy; the Admin order creation and storefront checkout pages can have their own URIs and fall back to the area default). A browser message such as "Refused to execute inline script because it violates the following Content Security Policy directive: script-src" means a script was not rendered through SecureHtmlRenderer or the nonce provider; fix the template, do not add 'unsafe-inline'.

Subresource Integrity (SRI) lets the browser verify that a script it fetched is the file the shop meant to serve. To meet the script-integrity requirement of PCI DSS 4.0 on payment pages, Magento 2.4.4-p9, 2.4.5-p8, 2.4.6-p6, 2.4.7, 2.4.8 and later provide integrity hashes for the JavaScript files in the local filesystem. The hashes are generated when static content is deployed: in 2.4.9 they cover minified, bundled and merged files and every deployment strategy (standard, quick, compact), and they are stored per area, theme and locale in pub/static/<area>/<vendor>/<theme>/<locale>/sri-hashes.json (merged runtime files in pub/static/_cache/merged/sri-hashes.json); before 2.4.8 they were kept in the cache. SRI is enabled by default on the payment pages only. To enable it on another page, a module adds a layout file that includes Magento_Csp::js/sri.js and the block Magento\Csp\Block\Sri\Hashes (template Magento_Csp::sri/hashes.phtml) to the head.additional container of that page. There is no SRI generation for remote scripts; the hash of a remote file can be computed with base64_encode(hash('sha256', $content, true)) and the tag needs both integrity and crossorigin attributes.

Source: Adobe Commerce developer docs: Subresource Integrity

registration.php, composer.json and etc/module.xml are the usual three files. The sequence makes Magento_Csp and Magento_Config load first, because the module overrides their configuration:

Source: Adobe Commerce developer docs: Content security policies

The module was installed with bin/magento module:enable PocketCoffee_Security and bin/magento setup:upgrade; both reported success and bin/magento setup:db:status reported "All modules are up to date".

Cross-site scripting (XSS) is injected markup that a browser runs. There are three kinds: persisted (the value comes from the database), reflected (the value comes from the request and is echoed) and DOM-based (client-side only). The rule of the documentation is to validate input but to escape output as close as possible to the place where it is printed, in the encoding of that place, because the same value can be harmless in JSON and dangerous in HTML.

The class Magento\Framework\Escaper (the $escaper variable in templates) has one method per context:

Source: Adobe Commerce developer docs: Cross-site scripting (XSS)

The local run of the console command shows the same hostile string, <script>alert(1)</script>"', in four contexts:

The last line is escapeUrl('javascript:alert(1)'): the scheme is removed, so a link built from a request parameter cannot execute script. The page then behaves in the same way over HTTP. With ?label=<img src=x onerror=alert(1)> and ?more=javascript:alert(1) the rendered HTML was:

Knockout templates have a naming rule instead: a property bound as inner HTML must be named with the suffix UnsanitizedHtml, and a static test enforces it. When DOM nodes are created in JavaScript, set innerText and attributes instead of innerHTML. UI component data providers return user data that is rendered for component linking, so values that must be taken literally are listed in a __disableTmpl array of the data provider’s result.

The Magento coding standard has a sniff, Magento2.Security.XssTemplate, that finds every echo in a template and decides whether the output is escaped. It accepts an $escaper or block escape method, a cast to (int) or (bool), count(), string literals without variables, methods whose name contains Html, and an explicit comment, /* @noEscape */ (output does not need escaping) or /* @escapeNotVerified */ (escaping has not been checked and should be). Everything else is an error. The module’s template passes after the renderer calls got the @noEscape comment (without it the sniff reported three errors, one for each renderer call). A bad template shows the other outcomes:

Source: Adobe Commerce developer docs: Static test for templates

Run with vendor/bin/phpcs --standard=Magento2 --extensions=php,phtml:

Line 6, which calls escapeHtml() on $block, is accepted as escaped but reported as a warning ("Using escapeHtml on $block is deprecated. Please use equivalent method on $escaper", and phpcbf can fix it). Line 7 is accepted because of the comment, and the comment is a statement that a reviewer has to verify.

Cross-site request forgery makes a logged-in browser send a request the user did not intend. The framework’s defence is the form key. A controller opts in to the check by implementing one or more of the marker interfaces HttpGetActionInterface, HttpPostActionInterface, HttpPutActionInterface and so on: the framework then denies other HTTP methods, and for any method other than GET it requires a valid form_key. The key is added to forms by lib/web/mage/common.js; in a template it is $block->getBlockHtml('formkey'), in JavaScript the global FORM_KEY, and on the server Magento\Framework\Data\Form\FormKey. The Coffee Club sign-up handler needs nothing for the check except the interface:

Source: Adobe Commerce developer docs: Cross-site request forgery (CSRF)

The page that is served from the full-page cache has no per-session key in the HTML; the browser sets a form_key cookie with JavaScript and the framework compares it with the submitted value. The five cases below were run with curl against the local store:

Source: Adobe Commerce developer docs: Cross-site request forgery

A request that carries the X-Requested-With: XMLHttpRequest header skips the form key check in the default validator: the same POST without any key returned {"joined":true}. The header cannot be set by a cross-site form, and browsers only allow it in cross-origin requests with a CORS preflight, so this is a deliberate exception for AJAX, but it means that an endpoint that is reachable by JavaScript must do its own authorization and not lean on the form key.

Magento authorizes by configuration first and in code second.

The module declares the ACL resources and three REST routes, one for each level:

Source: Adobe Commerce developer docs: Authorization

Source: Adobe Commerce developer docs: Authorization

and the service implements the explicit check for the self route (the class is also the example of constructor property promotion with readonly, which PHP 8.5 and the Magento 2.4.9 code base use):

Source: Adobe Commerce developer docs: Authorization

The routes behave as follows on the local store (the admin token comes from the integration token endpoint with the local test account):

The last line is the point of the forced parameter: an administrator token cannot call a self route, because there is no customer to fill the parameter in. The guest and administrator cases, and the admin page (which redirects to the login page without a session), were exercised; the success case of self needs a customer token and a customer account, and it was not run, nor was an Admin role that lacks the resource (the page shows the code and the configuration for them).

The 401 responses of the local store contain a stack trace in the JSON trace field because the store runs in developer mode; the trace is only added in developer mode, which is one more reason to run production mode on every internet-facing environment.

Two rules cover data at rest.

The hash string is hash:salt:version. The version 3_32_2_67108864 means hash version 3 (HASH_VERSION_ARGON2ID13_AGNOSTIC, Argon2id) followed by the seed length (32), the operations limit (2) and the memory limit (67,108,864 bytes) that were used, so that the parameters can change in the future without invalidating stored hashes; isValidHash() also accepts older MD5 and SHA-256 hashes. Calling getHash($value) without the salt argument returns an unsalted SHA-256 hash, which is not suitable for passwords or tokens that can be guessed. The cipher string is key-version:cipher:base64-ciphertext; cipher 3 is ChaCha20-Poly1305 (CIPHER_AEAD_CHACHA20POLY1305) and key version 0 is the first key listed in crypt/key of env.php.

Source: Adobe Commerce developer docs: Sensitive information

A configuration value that is a secret needs three declarations: the field type obscure with the encrypted backend model in system.xml, a sensitive entry for Magento\Config\Model\Config\TypePool in di.xml (so that config:show and the dumps mask it and config:sensitive:set accepts it), and a decrypt call where it is read. The environment entry marks a value that differs per environment and must not be committed with the configuration:

Source: Adobe Commerce developer docs: Sensitive information

Source: Adobe Commerce developer docs: Data re-encryption

Runs on the local store:

config:sensitive:set writes a sensitive value to app/etc/env.php so that it is not in the database at all (the command applied the encrypted backend model: the value in the file started with 0:3:), and the callback accepted a request signed with the value set that way; the file then has to be protected like the encryption key (env.php must not be readable by other users and must never be committed). When the encryption key changes (bin/magento encryption:key:change), values in core_config_data and in payment tables must be re-encrypted with bin/magento encryption:data:re-encrypt core_config_data sales_order_payment. Custom tables with encrypted columns add a re-encryptor with a virtual type of Magento\EncryptionKey\Model\Data\ReEncryptorList\ReEncryptor\SimpleHandler that names the table, the primary key and the columns; bin/magento encryption:data:list-re-encryptors lists what is registered. On the local store it printed:

An e-mail link that must work without a session (finish a Coffee Club sign-up) needs a self-signed token with an expiry, which needs no storage. The framework offers Magento\Framework\Jwt\JwtManagerInterface and a JwkFactory for the keys. The console command of the module signs a token with HS256, reads it back, and then shows the two failures a token reader has to handle:

Source: Adobe Commerce developer docs: Temporal authorization

Output:

Two findings from running it matter. First, JwtManagerInterface::read() verifies the signature but does not check the exp claim: the expired token was read without an exception, and the RuntimeException came from the explicit check in read() of the command. A caller that skips that check accepts expired tokens. Second, JwkFactory::createHs256() throws "Shared secret key must be at least 2048 bits" for a 256-byte key and accepts a 2048-byte key: the implementation compares the string length (bytes) with 2048, so the message and the check disagree. For an HMAC secret, derive a long random key and store it like any other secret rather than relying on the message.

Source: Adobe Commerce developer docs: Mass assignment

Source: Adobe Commerce developer docs: File uploads

Source: Adobe Commerce developer docs: Server-side request forgery

Source: Adobe Commerce developer docs: Brute force attacks

The documentation lists PHP functions that lead to code execution or weak cryptography and the coding standard rejects them: eval, unserialize and serialize (use Magento\Framework\Serialize\SerializerInterface), md5 and sha1 for anything sensitive, srand, mt_srand and mt_rand (use random_int()), include with a user-controlled path, and the class ArrayObject, whose unserialize() is exploitable. Low-level functionality such as the curl_* functions is discouraged in favour of Magento\Framework\HTTP\Adapter\Curl, superglobals should be read through Magento\Framework\HTTP\PhpEnvironment\Request, and file_get_contents() should be replaced by the filesystem API. A deliberately bad class,

Source: Adobe Commerce developer docs: Non-secure functions

was checked with vendor/bin/phpcs -q --standard=Magento2 (PHP_CodeSniffer 3.13.6 with the Magento coding standard of Mage-OS 3.6.0):

Two of the lines of the class passed silently, and that is worth knowing: the ObjectManager::getInstance() call and sha1() were not reported by the standard in this version, so a code review still has to look for them (the page on dependency injection explains why the ObjectManager must not be used directly). The module itself, with severity 1 and the php and phtml extensions, reported no errors and no warnings.

Source: Adobe Commerce developer docs: Security, performance and data handling

The module’s Admin page needs only the menu entry and the route, and is protected by ADMIN_RESOURCE:

Source: Adobe Commerce developer docs: Authorization

An unauthenticated request to the Admin route answered 200 with the login page (the URL included the Admin URI, and the secret key requirement redirects anything else to the dashboard of a logged-in user). The unauthorized-role case needs an Admin user with a limited role and was not run.