You can however export them with SQL:

SELECT
    ce.entity_id                                   AS customer_id,
    ce.email,
    TRIM(CONCAT(COALESCE(ce.firstname, ''), ' ', COALESCE(ce.lastname, ''))) AS customer_name,
    cg.customer_group_code                         AS customer_group,
    sw.name                                        AS website,
    ce.created_at                                  AS account_created,
    COALESCE(SUM(mr.points_balance), 0)            AS points_balance
FROM customer_entity ce
LEFT JOIN magento_reward mr ON mr.customer_id = ce.entity_id
LEFT JOIN customer_group  cg ON cg.customer_group_id = ce.group_id
LEFT JOIN store_website   sw ON sw.website_id = ce.website_id
GROUP BY ce.entity_id, ce.email, ce.firstname, ce.lastname,
         cg.customer_group_code, sw.name, ce.created_at
ORDER BY points_balance DESC, ce.entity_id;

That gives you every customer account, with a balance of 0 for the ones who have never earned a point, sorted with the biggest balances first.

¶Checking Balance History

If a specific balance looks wrong, the history table is the audit trail. Deltas for one customer:

SELECT h.created_at, h.action, h.points_delta, h.points_balance,
       h.is_expired, h.expired_at_static, h.expired_at_dynamic, h.comment
FROM magento_reward_history h
JOIN magento_reward mr ON mr.reward_id = h.reward_id
WHERE mr.customer_id = :customer_id
ORDER BY h.history_id;

points_balance on each history row is the running total as it stood after that event, so the last row should equal magento_reward.points_balance. When it does not, the usual cause is the expiry backlog above. Expiry itself is written as a reversing row with is_expired = 1 and is_duplicate_of pointing at the history row it cancels, so the original earn stays visible.

I checked the schema, the cron and the rate lookup against Adobe Commerce 2.4.8-p5 with magento/module-reward 101.2.8, and the same files are byte for byte identical on 2.4.7-p9 running 101.2.7-p5.

Patching CVE-2026-75650 closes the hole. It does nothing about anyone already inside. If the exploit was used against you before you patched, the attacker may be sitting on a valid admin session cookie, and possibly on a copy of your admin_user table. Neither expires because you deployed a patch.

There is no admin UI for this and no bin/magento command that does it. The quickest way to end every admin session and every admin password at once is two SQL statements:

UPDATE admin_user SET password = 'invalid';
UPDATE admin_user_session SET status = 3 WHERE status = 1;

Run them in that order, on the live database, and everyone is out.

¶Wiping every admin password hash

That is the point of the first statement. A stolen hash is now useless and so is a password the attacker already cracked or phished, because nothing they can type will match.

It does not throw a 500 on the next login attempt, which is the thing worth knowing before you run it. Magento\Framework\Encryption\Encryptor::isValidHash() calls explodePasswordHash(), which splits on : and expects three parts. The string invalid has none, so it throws RuntimeException('Hash is not a password hash'). That is caught one frame up by a catch (\Throwable) which falls back to $recreated = $this->hash($password), and the subsequent Security::compareStrings() fails. The admin gets the ordinary “The account sign-in was incorrect or your account is disabled temporarily” message. No fatal, no stack trace, no clue to anyone probing the login form that the column has been wiped.

¶Ending every live session

The second statement does that. admin_user_session is owned by Magento_Security, and its status column is declared in vendor/magento/module-security/etc/db_schema.xml as an unsigned smallint defaulting to 1. There is no lookup table, no enum and no foreign key on it, so the meaning of the number lives entirely in PHP.

¶Where the constants are

They are class constants on Magento\Security\Model\AdminSessionInfo, which is vendor/magento/module-security/Model/AdminSessionInfo.php. All four in full:

public const LOGGED_OUT = 0;
public const LOGGED_IN = 1;
public const LOGGED_OUT_BY_LOGIN = 2;
public const LOGGED_OUT_MANUALLY = 3;

What each one means in practice:

• 0, LOGGED_OUT: a normal end to a session. Written by AdminSessionsManager::processLogout() when someone signs out, by AdminSessionInfo::checkActivity() when the row is older than the configured admin session lifetime and by UserExpirationManager when an account’s expiry date passes.
• 1, LOGGED_IN: live. This is the only value the plugin below treats as valid, and the only one you need to match on.
• 2, LOGGED_OUT_BY_LOGIN: the same account signed in somewhere else and the config is set to allow a single session. Produces “Someone logged into this account from another device or browser. Your current session is terminated.”
• 3, LOGGED_OUT_MANUALLY: somebody deliberately ended the session from outside it. Produces “Your current session is terminated by another user of this account.”

There is a fifth value that is not on this class at all. AdminSessionsManager::LOGOUT_REASON_USER_LOCKED = 10 lives on Magento\Security\Model\AdminSessionsManager and is only ever used to pick a logout message, never written to the column. Do not use it in SQL.

¶Why 3 is the right number

LOGGED_OUT_MANUALLY is not an arbitrary pick. It is exactly what core writes when an admin uses the “Log Out All Other Sessions” button on their account page. That controller is Magento\Security\Controller\Adminhtml\Session\LogoutAll, and it calls AdminSessionsManager::logoutOtherUserSessions(), which ends with:

$collection->setDataToAll('status', \Magento\Security\Model\AdminSessionInfo::LOGGED_OUT_MANUALLY)
    ->save();

The same method is called internally when a password changes. So the SQL above is the core behaviour with the per-user filter taken off: instead of “every other session belonging to me”, it is “every live session belonging to anyone”.

¶How the status gets enforced

Enforcement is a plugin, security_admin_sessions_prolong, declared in vendor/magento/module-security/etc/adminhtml/di.xml and pointing at Magento\Security\Model\Plugin\AuthSession::aroundProlong(). Every admin request prolongs the session, and that method starts with:

if (!$this->sessionsManager->getCurrentSession()->isLoggedInStatus()) {
    $session->destroy();
    $this->addUserLogoutNotification();
    return null;
}

isLoggedInStatus() is a straight getData('status') == self::LOGGED_IN comparison against the database row. Set it to anything else and the next request the attacker makes destroys their session server side. You do not need to flush Redis or clear var/session for this to take effect, because the check is against the row, not the session payload.

The message the user sees comes from AdminSessionsManager::getLogoutReasonMessageByStatus(), a switch over those same constants. That is the practical argument for 3 over 0: your own staff get told the session was terminated rather than being silently dumped at the login screen.

¶Getting back in

You have just locked yourself out too, so know the way back before you run it.

The forgot-password flow still works. It sets a fresh rp_token and the reset writes a new hash without ever validating the old one, so any admin whose email address is correct and whose mail is actually being delivered can recover on their own. Test that transactional email is working before you wipe the column, not after.

Failing that, create a new admin from the CLI:

bin/magento admin:user:create \
  --admin-user=recovery \
  --admin-password='...' \
  --admin-email=you@example.com \
  --admin-firstname=Recovery \
  --admin-lastname=Admin

If you want the option of putting things back exactly as they were, take a copy of the column first:

CREATE TABLE admin_user_password_backup AS SELECT user_id, username, password FROM admin_user;

Think about whether you want that, though. After a suspected compromise the old hashes are the thing you are trying to get rid of, and a table full of them sitting in the same database is a liability. Drop it once everyone has reset.

¶Caveats

¶Magento_Security has to be enabled

With the module off the second statement does nothing. No plugin, no status check and the rows are inert. Some projects disable that module to stop the “session terminated” behaviour annoying staff who share logins. Check with bin/magento module:status Magento_Security first. If it is off, flush the session storage instead: redis-cli -n <session-db> FLUSHDB, or rm -rf var/session/* on a file-backed store.

¶session_id is not what it looks like

The column is declared varchar(1) and commented “Deprecated: Session ID value no longer used” in db_schema.xml. Do not try to target individual sessions through it.

¶This covers admin sessions only

Integration and API access is separate, in oauth_token and the integration tables. Customer sessions are separate again. If the compromise reached the point of creating an integration, revoking admin passwords does not touch it, and that is the persistence mechanism I would expect to find rather than a session cookie.

¶Patch first, then invalidate

Kicking everyone out of an unpatched store buys you minutes. The order is patch, deploy, then invalidate, then have everyone reset through the forgot-password flow.

I ran the code paths above against an Adobe Commerce 2.4.8-p5 installation, magento/module-security 100.4.8-p4. The constants and the plugin have been stable for a long time, but check them on your own version before trusting a number out of a blog post.

They are a virtual patch. The point of them is to reject requests carrying the template-directive payloads that the APSB26-146 bulletin covers, at the CDN, before the origin sees them. For a project that cannot deploy the real patch immediately, that is a reasonable stopgap.

The problem is what else they reject.

¶The symptom

Saving a CMS page or block in the admin panel fails. Depending on the theme and the admin’s own error handling you get a Fastly 403 page, a redirect back to the edit form with the content silently unsaved, or a JavaScript error where the save POST returned HTML instead of the JSON the grid expected. Nothing appears in var/log/exception.log or var/log/system.log, because the request never arrived. Magento is not involved.

This is a false positive, and an obvious one once you see it. The snippets match on the shape of a template directive in a request. Page content in Magento is made of template directives: {{block class="..."}}, {{widget type="..."}}, {{media url="..."}}. A content editor saving a page that contains a widget is posting the exact pattern the rule was written to catch. So is anyone saving an email template, a dynamic block or a product description with a media directive in it.

The tell is that the failure follows the content, not the user. Same admin, same page, save a plain paragraph and it works, paste a widget back in and it 403s.

¶Read them before you delete them

Do not delete blind. The snippet contents are not documented anywhere by Adobe, they were pushed to your service rather than committed to your repository, and once the version is gone the only copy is in Fastly’s version history. Record them first:

fastly service vcl snippet describe --service-id="$SID" --version=112 --name=accord-rce
fastly service vcl snippet describe --service-id="$SID" --version=112 --name=accord_rce_1

Swap 112 for your active version. If you do not know it, fastly service describe --service-id="$SID" prints it, and I covered listing and switching versions in more detail in this post on Fastly service versions.

Keep that output. It tells you the type (recv, fetch and so on), the priority and the match itself, which is what you need if you later decide to put a narrower version of the rule back.

¶Clone the active version

Fastly versions are immutable once activated, so you cannot edit the live one. Clone it:

fastly service-version clone --service-id="$SID" --version=active

That prints the new version number, for example Version: 113. Use your own number everywhere below.

¶Delete both snippets

fastly service vcl snippet delete --service-id="$SID" --version=113 --name=accord-rce
fastly service vcl snippet delete --service-id="$SID" --version=113 --name=accord_rce_1

Both. accord_rce_1 is easy to miss because the naming is inconsistent, one hyphenated and one underscored with a numeric suffix, and leaving either in place leaves the 403 in place.

¶Verify, then validate

List what is left on the new version:

fastly service vcl snippet list --service-id="$SID" --version=113

Neither name should appear. Everything else should, including the Adobe Commerce module’s own generated snippets and any custom ones you have added yourself, such as the SessionReaper and PolyShell media blocks.

Then make sure the version still compiles before you put traffic on it:

fastly service-version validate --service-id="$SID" --version=113

This matters more than it looks. Removing a snippet can break a later one that referenced a variable or a backend it declared, and a VCL that fails to compile on activation takes the site down rather than falling back.

¶Activate

fastly service-version activate --service-id="$SID" --version=113

Activation is near instant across the edge. Go and save the CMS page that was failing. It should save.

Rolling back is the same command pointed at the old number:

fastly service-version activate --service-id="$SID" --version=112

Two things to watch afterwards. The Adobe Commerce Fastly module can push its own VCL from the admin panel, under Stores > Configuration > Advanced > System > Full Page Cache > Fastly Configuration, and clicking upload there creates a further version. That is fine, it clones from active, so it will not resurrect the deleted snippets. But if accord-rce reappears on a new version you did not create, someone or something re-applied it, and on a cloud project that means asking Adobe support who pushed it and telling them why you removed it.

¶Removing the rules does not fix the vulnerability

The snippets were a virtual patch for CVE-2026-75650. Deleting them because they break content editing puts you back to unmitigated unless the real fix is in place. Confirm it is before or at the same time as you activate the new version:

• On cloud, take the magento/magento-cloud-patches 1.1.21 bump and check vendor/bin/ece-patches status | grep 15587 reports it applied. The entry pins exact patch levels, so a project one patch release behind gets nothing from it.
• Off cloud, apply the VULN-39341 composer patch for your line, or the identical MCLOUD-15587 file out of the 1.1.21 package, then setup:upgrade, setup:di:compile and cache:flush.

I went through both routes, what the patches change and where an extended BlockFactory still leaves you exposed, in the patch analysis.

If you do want an edge rule as well, write your own from the snippet contents you saved, scoped to the storefront and excluding /admin or whatever your admin front name is. The reason Adobe’s version breaks is that it does not make that distinction.

Adobe’s bulletin is APSB26-146.

Adobe’s September 2026 monthly patch for Magento landed today in magento/magento-cloud-patches 1.1.20 under the internal reference MCLOUD-15053. It is listed in patches.json as “Patch for Sep 2026 monthly release” and there are eleven files: one for each supported Open Source line and one for each supported B2B line. There is no Commerce (EE) build this month. August’s release shipped EE files alongside the others, so anyone going looking for one this month will not find it.

MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.4-p18.patch
MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.5-p17.patch
MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.6-p15.patch
MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.7-p10.patch
MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.8-p5.patch
MCLOUD-15053__Sep_2026_monthly_release_ce__2.4.9.patch

MCLOUD-15053__Sep_2026_monthly_release_b2b__1.3.3-p18.patch
MCLOUD-15053__Sep_2026_monthly_release_b2b__1.3.4-p17.patch
MCLOUD-15053__Sep_2026_monthly_release_b2b__1.4.2-p10.patch
MCLOUD-15053__Sep_2026_monthly_release_b2b__1.5.2-p5.patch
MCLOUD-15053__Sep_2026_monthly_release_b2b__1.5.3.patch

This is separate from the APSB26-146 / VULN-39341 patch I wrote up earlier today. Different files, different bugs and you need both.

As with that one, I diffed the version builds against each other before reading any of them. This time they are not identical. The Open Source patch touches eight files on 2.4.6 and later but only seven on 2.4.4 and 2.4.5, and two of the fixes get progressively thinner the further back you go. The B2B patch is one file on every line except 1.5.3, which gets two. The version differences are the most useful thing in here if you run an older line, so I have called them out under each fix.

¶Open Source: the eight files

vendor/magento/framework/Escaper.php
vendor/magento/module-backup/Controller/Adminhtml/Index/Rollback.php
vendor/magento/module-customer/i18n/en_US.csv
vendor/magento/module-customer-graph-ql/Model/Context/AddUserInfoToContext.php
vendor/magento/module-import-export/Controller/Adminhtml/Export/File/Delete.php
vendor/magento/module-instant-purchase/Model/InstantPurchaseOptionLoadingFactory.php
vendor/magento/module-paypal/Controller/Express/AbstractExpress.php
vendor/magento/module-sales/view/adminhtml/web/order/create/scripts.js

The i18n change is a single new string, “Address not found.”, for the Instant Purchase fix. That leaves seven real changes.

¶Backup rollback ran before it told you no

Magento\Backup\Controller\Adminhtml\Index\Rollback::execute() used to open like this:

if (!$this->_objectManager->get(\Magento\Backup\Helper\Data::class)->isRollbackAllowed()) {
    $this->_forward('denied');
}

if (!$this->getRequest()->isAjax()) {
    return $this->_redirect('*/*/index');
}

isRollbackAllowed() is a thin wrapper around isAllowed('Magento_Backup::rollback'), so the intent is clear. The problem is the missing return. _forward() does not throw and it does not stop the action. It marks the request as not dispatched and sets the next action name, and then control comes straight back to the line after it. The front controller only picks up the forward once execute() has finished. So an admin user without the rollback resource got the “denied” page rendered for them, after the rollback had already run.

The patch deletes the runtime check and replaces it with the constant the framework actually looks at:

class Rollback extends \Magento\Backup\Controller\Adminhtml\Index implements HttpPostActionInterface
{
    /**
     * @see _isAllowed()
     */
    public const ADMIN_RESOURCE = 'Magento_Backup::rollback';

The parent controller declares Magento_Backup::backup, so before this the dispatcher’s own check was satisfied by anyone who could create a backup. Now _isAllowed() requires the child resource, and it runs in dispatch() before execute() is ever entered. Nothing to fall through.

Context on exposure: this is an authenticated admin action behind a POST with a form key, and backup functionality has been disabled by default since 2.3. But rollback is about as destructive as an admin action gets, and the reason Magento_Backup::rollback exists as its own ACL node is precisely so that you can hand out backup creation without handing out restore. That separation was not real until now.

Identical on all six lines.

¶Export file delete could reach outside the export folder

Magento\ImportExport\Controller\Adminhtml\Export\File\Delete takes a filename from the request and did this with it:

$directoryWrite = $this->filesystem->getDirectoryWrite(DirectoryList::VAR_IMPORT_EXPORT);
try {
    $directoryWrite->delete($directoryWrite->getAbsolutePath() . 'export/' . $fileName);

To be fair to the old code, Write::delete() calls validatePath() first, so ../../app/etc/env.php was never going to work. The directory object refuses anything that resolves outside its root. The catch is where that root is. DirectoryList::VAR_IMPORT_EXPORT maps to plain var, not to var/importexport, so the check only guaranteed the target stayed somewhere under var/. export/../log/system.log is a valid path under that root. So is export/../import_history, and so is export/.. itself. delete() handles directories too, recursively. An admin user whose role includes Magento_ImportExport::export could remove logs, reports, import history or the export directory wholesale, and the controller would report “File … deleted” as if nothing odd had happened.

The patch normalises the name, then insists the result is an existing file under export/:

$fileName = $directoryWrite->getDriver()->getRealPathSafety(DIRECTORY_SEPARATOR . $fileName);
$fileExist = $directoryWrite->isFile('export' . $fileName);
if (!$fileExist || !$this->isAllowedExportFile($fileName)) {
    $this->messageManager->addErrorMessage(__(
        'Sorry, but the data is invalid or the file is not uploaded.'
    ));
    return $resultRedirect;
}
$directoryWrite->delete($directoryWrite->getAbsolutePath() . 'export' . $fileName);

getRealPathSafety() collapses .. segments without touching the filesystem, so a traversal attempt ends up as a plain filename that then has to exist as a file. Directories fail the isFile() check outright.

Version difference: The isAllowedExportFile() half exists only on 2.4.9. It goes through Magento\ImportExport\Model\Export\FileInfo, which is new in 2.4.9 as part of the queue-based export work, and checks that the extension is one of the configured export formats. On 2.4.4-p18 through 2.4.8-p5 the class does not exist, so the condition is just if (!$fileExist). The traversal is closed on every line; the extension allow-list is a 2.4.9 extra.

¶GraphQL customer context trusted the wrong store

Magento\CustomerGraphQl\Model\Context\AddUserInfoToContext is the processor that turns a bearer token into the GraphQL context’s user id, user type and is_customer flag. It gets two changes.

The first is what happens when a token is a customer token but the customer does not pass the isCustomer() check. That can only happen in one situation: account sharing is set to per website and the customer’s website is not the one being queried. Before the patch the context came out with is_customer = false but the user id still set to the customer’s id. Anything downstream that consults getUserId() rather than the is_customer extension attribute would carry on as that customer, on a website they do not belong to. The patch zeroes the id:

if (!$isCustomer
    && !empty($currentUserId)
    && $currentUserType === UserContextInterface::USER_TYPE_CUSTOMER
) {
    $contextParameters->setUserId(0);
}

The second change is about which store the website check compares against. It used $this->storeManager->getStore(), and the patch replaces that with a method that reads the Store header off the request directly:

private function getEffectiveStore(): StoreInterface
{
    $storeCode = trim((string) $this->request->getHeader('Store'));
    if (!empty($storeCode)) {
        return $this->storeManager->getStore($storeCode);
    }
    return $this->storeManager->getStore();
}

The reason is ordering, and Adobe’s own comment in the matching B2B change spells it out: the context can be built during request validation, before header processing has switched the store manager to the requested store. You can see the sequence on 2.4.8 in Magento\GraphQlCache\Controller\Plugin\GraphQl::beforeDispatch(), which calls validateRequest() and only then processHeaders(). Any request validator that asks for the context, and the B2B company validator does exactly that, gets one built while the store manager is still on the default store. The website check then ran against the wrong website, and ContextFactory keeps hold of what it built. A token from website A, sent with a Store header for website B, was being compared against the default website, whichever that happened to be. Reading the header explicitly makes the check correct regardless of when it runs.

Version difference: This is the one where the older lines get more than the newer ones, not less. On 2.4.8-p5 and 2.4.9 the per-website check already existed and the patch adjusts it. On 2.4.4-p18, 2.4.5-p17, 2.4.6-p15 and 2.4.7-p10 the check did not exist at all. isCustomer() was simply “is there a non-empty id and is the type customer”. The patch backports the whole thing: it adds Share and StoreManagerInterface as nullable constructor arguments with object manager fallbacks, and introduces the website comparison alongside the two changes above. If you are on one of those lines with account sharing per website, this patch is the first time GraphQL has enforced it for customer tokens. Test your headless or PWA storefront against every website after applying, because behaviour that previously worked by accident will now be refused.

¶Instant Purchase accepted anyone’s address IDs

Magento\InstantPurchase\Controller\Button\PlaceOrder reads instant_purchase_shipping_address and instant_purchase_billing_address from the POST as integers and hands them to InstantPurchaseOptionLoadingFactory::create(). The factory loaded them with addressRepository->getById() and used them. There was no check that they belonged to the customer placing the order. The payment token lookup right above it is scoped to the customer id, so this is an inconsistency rather than a design decision.

$shippingAddress = $this->getAddress($shippingAddressId);
$billingAddress = $this->getAddress($billingAddressId);
if ((int)$shippingAddress->getCustomerId() !== $customerId ||
    (int)$billingAddress->getCustomerId() !== $customerId) {
    throw new NoSuchEntityException(__('Address not found.'));
}

Address entity ids are sequential integers. A logged-in customer with a saved card could place an instant purchase against any other customer’s address id, and get that customer’s name, street and telephone back in the order confirmation. Instant Purchase is enabled by default in config.xml, though the button only appears for a customer who already has a vaulted payment token and default addresses, so in practice the population that can reach this is stores running Braintree or another vault-capable gateway. It is a textbook insecure direct object reference and the fix is the right one: compare ownership, throw the same not-found error you would for a non-existent id, do not leak that the id was real.

Identical on all six lines.

¶PayPal Express pinned a quote to the session without checking whose it was

Magento\Paypal\Controller\Express\AbstractExpress::_initCheckout() stores the quote it is working with into the checkout session as the PayPal quote id, and _getQuote() later falls back to loading whatever quote id is stored there when the session has no quote of its own. The patch adds an ownership test before the pin:

if ($quote->getId() && $this->isQuoteAllowedForUser($quote)) {
    $this->_getCheckoutSession()->setPayPalQuoteId($quote->getId());
}

private function isQuoteAllowedForUser(CartInterface $quote): bool
{
    if ((int)$quote->getId() === (int)$this->_getCheckoutSession()->getQuoteId()) {
        return true;
    }

    return $this->_customerSession->isLoggedIn()
        && (int)$quote->getCustomerId() === (int)$this->_customerSession->getCustomerId();
}

A quote is only written back into the session if it is already the session’s quote, or the logged-in customer owns it. Anything else is not pinned, and so cannot be picked up again by the fallback in _getQuote(). The failure this prevents is a checkout session ending up bound to a cart that belongs to somebody else, which in a PayPal return flow means their items, their addresses and potentially their order.

Version difference: This file is not in the 2.4.4-p18 or 2.4.5-p17 patches at all. The patch does not say why. Either the code path differs enough on those lines that the hunk does not apply, or Adobe chose not to backport it. If you are on 2.4.4 or 2.4.5 with PayPal Express enabled you should know that this particular fix has not reached you.

¶Admin order creation rendered a VAT number as HTML

When an admin validates a VAT number on the order creation screen, order/create/scripts.js builds the result message by substituting the number into a translated template and shows it in a modal:

message = parameters.vatInvalidMessage.replace(/%s/, params.vat);

The modal renders HTML. The VAT value comes from the billing address form on that screen, which is prefilled from the customer’s saved address, which the customer typed in themselves on the storefront. So a customer sets their VAT id to a script payload, an admin creates an order for them and clicks validate and the payload runs in the admin session. Stored XSS from a customer-controlled field into the admin. The fix is what you would expect:

var escapedVat = _.escape(params.vat);
...
message = parameters.vatInvalidMessage.replace(/%s/, escapedVat);

Underscore is added to the module’s dependencies for it. Identical on all six lines.

¶The URL escaper only decoded once

Magento\Framework\Escaper::escapeXssInUrl() is exposed on every block through AbstractBlock::escapeXssInUrl(), for URLs that came from a request and are about to go into an href. Core templates barely call it themselves; third-party and agency templates do, which is exactly the code that will not be in any Adobe test suite. It worked in three steps: html_entity_decode() the input, strip javascript:, data: and vbscript: schemes with a regex, then htmlspecialchars() the result with double_encode set to false so that any entities still present are left alone.

That last flag is the problem. Decode once means javascript: becomes javascript:. The scheme regex does not match that, because the j is an entity. htmlspecialchars() with double_encode = false leaves j exactly as it is. The browser then decodes the attribute value and sees javascript:. One layer of encoding more than the filter expected, and the filter is bypassed.

The patch decodes until the string stops changing:

private function decodeHtmlEntitiesToFixedPoint(string $data): string
{
    $iterationCap = 10;
    for ($iteration = 0; $iteration < $iterationCap; $iteration++) {
        $decoded = html_entity_decode($data);
        if ($decoded === $data) {
            return $data;
        }
        $data = $decoded;
    }

    return '';
}

Ten rounds is more than any legitimate URL needs, and if the input is still changing after ten it returns an empty string rather than guess. The scheme regex then runs against the fully decoded form, which is the only form worth checking.

If you have ever written your own “decode then filter” step anywhere, this is the pattern to look for. A single decode is a fixed assumption about how many layers the attacker used, and they get to choose that number.

Identical on all six lines.

¶B2B: two files, and one of them only on 1.5.3

vendor/magento/module-company/view/base/ui_component/company_form.xml
vendor/magento/module-company-graph-ql/Controller/HttpRequestValidator/CompanyValidator.php

¶Company form data was readable by any admin role

The first change is one line in the company form’s data source:

<dataSource name="company_form_data_source">
    <settings>
        <submitUrl path="company/index/save"/>
    </settings>
    <aclResource>Magento_Company::manage</aclResource>
    <dataProvider class="Magento\Company\Model\Company\DataProvider" name="company_form_data_source">

UI component forms load their data through mui/index/render, a generic admin endpoint that renders any registered component by namespace. That endpoint is gated by the admin session and by whatever aclResource the component’s data source declares, and nothing else. Without the declaration, mui/index/render?namespace=company_form&id=N would return the company record to any authenticated admin user regardless of role: company name, legal address, credit settings, the sales representative, the company admin’s details. The edit page itself was protected by its controller. The data behind it was not.

Adobe has been adding aclResource to grids and forms in security releases for years, and this is another one. It is on all five B2B lines.

¶CompanyValidator treated a zero user id as a customer

The second change is a companion to the Open Source GraphQL fix above. CompanyValidator is a request validator, which is why it carries the comment about the store scope not being ready yet. It decides whether the current context has a customer by checking:

if ($context->getUserId() === null
    || $context->getUserType() !== UserContextInterface::USER_TYPE_CUSTOMER
) {

Now that AddUserInfoToContext sets the user id to 0 for a customer token that fails the website check, 0 === null is false and the validator would carry on treating 0 as a real customer id. The patch changes the test to (int)$context->getUserId() <= 0, so zero takes the same fallback path as null.

Version difference: Only the 1.5.3 build contains this. The 1.5.2-p5, 1.4.2-p10, 1.3.4-p17 and 1.3.3-p18 patches carry the company_form.xml change alone, and this time there is a good reason. On 1.5.2 the validator does not look at the user id at all at this point. It checks $context->getExtensionAttributes()->getIsCustomer(), which is the flag the Open Source fix already sets correctly, so there is nothing to backport. The getUserId() === null test is a 1.5.3 rewrite, and this patch is fixing a regression that rewrite introduced.

¶Tested against 2.4.8

I checked the patches against a real 2.4.8-p5 installation with B2B 1.5.2-p3 before writing any of this, and the pre-patch code quoted above is from that vendor tree rather than from GitHub. git apply --check on the 2.4.8-p5 Open Source patch and the 1.5.2-p5 B2B patch both come back clean. The B2B one applies to a p3 install because company_form.xml has not changed between those patch levels. The 1.5.3 B2B build fails on the CompanyValidator hunk against 1.5.2, as it should.

One thing to be careful of: the 2.4.9 Open Source patch also passes git apply --check on a 2.4.8 tree. Every hunk’s context matches. It would then fatal the first time anyone deleted an export file, because it adds a use statement and a constructor argument for FileInfo, and that class does not exist below 2.4.9. Textual applicability is not the same as the right patch. Use the build named for your line.

¶What to do

Apply the patch for your line, and the B2B one if you have B2B. On Cloud it arrives with the magento/magento-cloud-patches 1.1.20 bump and is applied during deploy. Everywhere else, drop the .patch file into m2-hotfixes or apply it directly with git apply, then the usual:

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Two classes pick up new nullable constructor arguments: AddUserInfoToContext on every line, and Export\File\Delete on 2.4.9 only. Both fall back to the object manager, so preferences and plugins on those classes keep working. If you have replaced AddUserInfoToContext or overridden _initCheckout() in a PayPal customisation, your copy keeps the old behaviour and you need to port the change by hand.

Then, specific to this release:

• If you are on 2.4.4 or 2.4.5 with PayPal Express, you did not get the quote ownership fix. Know that.
• If you are on 2.4.4 through 2.4.7 with account sharing per website and a GraphQL storefront, run your customer flows against every website. The website check is new to you.
• Check the Backups and Import/Export grants on your admin roles. The rollback fix only matters for a role that holds backup without rollback, and the export fix for any role that holds export at all. Know which roles those are.

None of these are remote pre-authentication issues. Every one needs either an admin session or a customer session, and most need a specific feature enabled. That is the pattern of a monthly release rather than an emergency one. It is still nine changes in a single drop, and most of them are variations on the same mistake: the check existed, it was just in the wrong place, ran at the wrong time or stopped one layer too early.

You can read Adobe’s release notes for APSB26-138 over on their site.

This post discusses the StyleSmuggler exploit, discovered by my good friends at Sansec.

Adobe has shipped a set of composer patches under the internal reference VULN-39341, one build for each supported Magento line: 2.4.4-p18, 2.4.5-p17, 2.4.6-p15, 2.4.7-p10, 2.4.8-p5 and 2.4.9. I diffed all six against each other first, because that usually tells you something. They are byte-for-byte the same fix. The only differences are hunk offsets, blob hashes and one line where the older branch still uses const instead of public const. Every supported version gets the identical eight-file change, which means the bug has been in the platform since at least 2.4.4 and probably a lot longer.

What follows is an analysis of what the patch closes, based on the patch itself and on reading the pre-patch code in a real 2.4.7 vendor tree. There is no working exploit here and I am not going to publish one. The interesting part is the shape of the bugs, because two of them are patterns you have almost certainly written yourself.

¶The eight files

vendor/magento/framework/View/Element/BlockFactory.php
vendor/magento/framework/View/Layout/Generator/Block.php
vendor/magento/framework/Webapi/ErrorProcessor.php
vendor/magento/module-backend/Model/Widget/Grid/Row/UrlGeneratorFactory.php
vendor/magento/module-email/Block/Adminhtml/Template/Preview.php
vendor/magento/module-email/Model/AbstractTemplate.php
vendor/magento/module-newsletter/Block/Adminhtml/Queue/Preview.php
vendor/magento/module-newsletter/Block/Adminhtml/Template/Preview.php
pub/errors/processor.php

Three distinct problems, and they are worth separating because they carry very different risk.

¶Problem one: instantiate first, type-check second

This is the important one. BlockFactory::createBlock() looked like this:

public function createBlock($blockName, array $arguments = [])
{
    $blockName = ltrim($blockName, '\\');
    $block = $this->objectManager->create($blockName, $arguments);
    if (!$block instanceof BlockInterface) {
        throw new \LogicException($blockName . ' does not implement BlockInterface');
    }
    ...

Read the order of operations. The class is constructed, and only then is it asked whether it was ever allowed to exist. By the time the instanceof check runs and throws, the constructor has already executed. So has every constructor in the dependency graph the object manager resolved to build it, and so has any __destruct that fires when the rejected object is garbage collected.

That is arbitrary object instantiation, which in PHP is a well-worn route to worse things. You are not looking for a class that does something useful when you call a method on it, because you never get to call a method. You are looking for a class whose construction has a side effect: one that writes a file, opens a connection, deserializes something or hands a value to a sink further down. Magento’s object manager can construct a very large share of the classes in the codebase, plus everything in vendor/, and the arguments array is under the caller’s control too.

The fix is to resolve the DI preference for the requested name and type-check the string, before anything gets built:

$resolvedType = $this->objectManagerConfig->getInstanceType(
    $this->objectManagerConfig->getPreference($blockName)
);
if (!is_a($resolvedType, BlockInterface::class, true)) {
    throw new \LogicException($blockName . ' does not implement BlockInterface');
}
$block = $this->objectManager->create($blockName, $arguments);

is_a() with the third argument set to true accepts a class name string rather than an object, so the check happens with nothing instantiated. Resolving the preference first matters, because the name passed in is frequently an interface or a virtual type, and checking the raw name would reject legitimate blocks.

The same pattern, and the same fix, in UrlGeneratorFactory::createUrlGenerator(). Before:

$rowUrlGenerator = $this->_objectManager->create($generatorClassName, $arguments);
if (false === $rowUrlGenerator instanceof GeneratorInterface) {
    throw new \InvalidArgumentException('Passed wrong parameters');
}

After, with Adobe’s own comment left in the patch:

// Validate the type BEFORE instantiation.
if (!is_a($generatorClassName, GeneratorInterface::class, true)) {
    throw new \InvalidArgumentException('Passed wrong parameters');
}
return $this->_objectManager->create($generatorClassName, $arguments);

That one is reached from Magento\Backend\Block\Widget\Grid\ColumnSet::__construct(), which reads the generator class name straight out of block data:

$generatorClassName = \Magento\Backend\Model\Widget\Grid\Row\UrlGenerator::class;
if (isset($data['rowUrl'])) {
    $rowUrlParams = $data['rowUrl'];
    if (isset($rowUrlParams['generatorClass'])) {
        $generatorClassName = $rowUrlParams['generatorClass'];
    }

Anywhere block data is influenced by something less trustworthy than a developer editing layout XML, that is a class-name sink.

¶Why the block factory is the one that matters

A factory buried in the framework only matters if something can feed it a name. Something can.

Magento\Email\Model\Template\Filter::blockDirective() is what implements the {{block class="..."}} directive:

if (isset($blockParameters['class'])) {
    $block = $this->_layout->createBlock($blockParameters['class'], null, ['data' => $blockParameters]);
}

Layout::createBlock() goes to Layout\Generator\Block::getBlockInstance(), which goes to BlockFactory::createBlock(). And Magento\Cms\Model\Template\Filter is a one-line subclass:

class Filter extends \Magento\Email\Model\Template\Filter

So the directive is live in CMS pages, CMS blocks and widget content, and the result renders on the storefront to anonymous visitors. Pre-patch, the class named in that directive was constructed before anyone asked whether it was a block. An admin whose role grants nothing but CMS editing could reach a construction primitive across most of the codebase, and see the fallout on a public page. That is a privilege escalation inside the admin, not just a hardening nit.

The email and newsletter template editors reach the same directive by the same route, which is why the preview blocks are in this patch at all.

There is a small companion change in Layout\Generator\Block that tells you the new check throws in places the old code never expected an exception:

-            } catch (\ReflectionException $e) {
+            } catch (\ReflectionException | \LogicException $e) {

Without it, a layout naming a non-block class would surface the new LogicException as a fatal instead of a logged critical. Worth knowing if you have a theme or a module that names something odd in layout XML: post-patch it will log and render empty rather than blow up, but it also will not silently construct the object any more.

¶Problem two: request parameters typed as “whatever arrived”

Magento\Email\Block\Adminhtml\Template\Preview::_toHtml() builds an unsaved template out of raw request input:

$template->setTemplateType($request->getParam('type'));
$template->setTemplateText($this->_maliciousCode->filter($request->getParam('text')));
$template->setTemplateStyles($request->getParam('styles'));

getParam() returns whatever the query string or POST body says, and PHP will happily give you an array from text[]=a&text[]=b. The filter in the middle does not stop that. Magento\Framework\Filter\Input\MaliciousCode::filter() is documented as taking string|array, and it runs preg_replace() over the value, which returns an array when handed one:

/**
 * @param string|array $value
 * @return string|array
 */
public function filter($value)
{
    $replaced = 0;
    do {
        $value = preg_replace($this->_expressions, '', $value ?? '', -1, $replaced);
    } while ($replaced !== 0);

So an array, or a nested array, survived into setTemplateText(), which is plain magic-method setData() with no type at all, and from there into the template filter which expects a string throughout. The patch replaces the magic setters with real ones on Magento\Email\Model\AbstractTemplate:

public function setTemplateText($value)
{
    return $this->setData('template_text', is_string($value) ? $value : '');
}

public function setTemplateStyles($value)
{
    return $this->setData('template_styles', is_string($value) ? $value : '');
}

Coerce to empty string rather than throw, so nothing that legitimately passes null keeps working. Note also that styles was never passed through the malicious-code filter at all, and still is not: the string coercion is the whole of its protection.

The lesson generalises past this patch. getParam() is not a string. Every setSomething($request->getParam(...)) in your own code is an untyped hand-off, and Magento’s magic setters will store an array as cheerfully as a string.

¶Problem three: attacker-controlled strings written to disk as PHP-adjacent files

Two near-identical fixes, one in the Web API error path and one in the public error page.

Magento\Framework\Webapi\ErrorProcessor::_saveFatalErrorReport() before:

$this->directoryWrite->create('report/api');
$reportId = abs((int)(microtime(true) * random_int(100, 1000)));
$this->directoryWrite->writeFile('report/api/' . $reportId, $this->serializer->serialize($reportData));

After:

if (is_string($reportData)) {
    $reportData = str_replace('<?', '< ?', $reportData);
}
$this->directoryWrite->writeFile(
    'report/api/' . $reportId,
    self::REPORT_EXECUTION_GUARD . PHP_EOL . $this->serializer->serialize($reportData)
);

where the guard is the string <?php exit; ?>. pub/errors/processor.php gets the same treatment for the storefront reports under var/report/, with a recursive walk because that report data is an array:

private function sanitizeReportData(array $data): array
{
    array_walk_recursive($data, static function (&$value) {
        if (is_string($value)) {
            $value = str_replace('<?', '< ?', $value);
        }
    });
    return $data;
}

and a matching reader that strips the guard back off, so existing report viewing still works:

private function readReportFile(string $reportFile): string
{
    $contents = (string)file_get_contents($reportFile);
    $guard = self::REPORT_EXECUTION_GUARD;
    if (strncmp($contents, $guard, strlen($guard)) === 0) {
        $contents = ltrim(substr($contents, strlen($guard)), "\r\n");
    }
    return $contents;
}

The point is not that Magento was executing these files. It was not. The point is that any request that fatals, on /rest/..., on /graphql or on the storefront, gave you a file on disk in a predictable directory whose contents you substantially controlled, including PHP open tags. That is a write primitive parked one misconfiguration away from execution. All it needs is a webserver that serves var/ because someone loosened a location block, an include or file_get_contents anywhere that takes a path fragment, a backup tool that copies var/report somewhere web-visible or a template engine reached through problem one. <?php exit; ?> in front of the payload makes the file inert as a PHP script no matter how it eventually gets included, and neutralising <? to < ? means the body cannot reopen it.

This is the same defence Magento already applies to generated files, and the same reason Laravel writes <?php exit; ?> at the head of its session files. It is cheap and it is unconditional, which is exactly what you want in an error handler that by definition runs when things are already wrong.

¶The ACL additions, and what they are actually for

Three preview blocks pick up an admin resource constant and a check at the top of _toHtml():

private const ADMIN_RESOURCE = 'Magento_Email::template';
...
protected function _toHtml()
{
    if (!$this->_authorization->isAllowed(self::ADMIN_RESOURCE)) {
        return '';
    }

plus Magento_Newsletter::template on the newsletter template preview and Magento_Newsletter::queue on the queue preview.

It is worth being precise about what this does and does not mean, because it is easy to read a new isAllowed() call as proof that an endpoint was open. It was not. The controllers in front of these blocks were already gated. Magento\Email\Controller\Adminhtml\Email\Template carries public const ADMIN_RESOURCE = 'Magento_Email::template', the newsletter template controller carries Magento_Newsletter::template, and Magento\Newsletter\Controller\Adminhtml\Queue not only declares Magento_Newsletter::queue but overrides _isAllowed(). The admin router requires a session for all of them. Nothing in this patch is a pre-authentication issue, and nobody is hitting these URLs anonymously.

What the block-level check buys you is protection for the case where the block renders somewhere other than behind its own controller. Given problem one, that case is not hypothetical: {{block class="Magento\Email\Block\Adminhtml\Template\Preview"}} in content processed by the CMS filter is the exact scenario, and the block reads type, text and styles off the current request whatever that request happens to be. Moving the authorisation check from the route to the block means the check travels with the code that reads the input. That is the right place for it.

¶What to do

Apply the patch. It is one composer patch per version line, it touches no schema and no DI wiring you own, and there is nothing to configure afterwards. Clear generated code and recompile as usual, because BlockFactory picks up a new constructor argument:

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

The new second constructor argument on BlockFactory is nullable with an object-manager fallback, so a plugin or a preference of your own on that class will keep working. If you have extended BlockFactory or UrlGeneratorFactory and reimplemented createBlock or createUrlGenerator, your override silently keeps the old behaviour. Check for that first, it is the one realistic way to apply this patch and stay vulnerable.

Two things worth doing while you are in there, neither of which is in the patch:

Confirm your webserver cannot serve var/, generated/ or pub/media as anything executable. The nginx sample config gets this right; hand-rolled configs and Apache setups with a loose <Directory> block frequently do not. The report guard makes an inert file, but you would rather not be relying on it.

Grep your own code for the instantiate-then-check pattern, because it is a natural thing to write:

grep -rn --include=*.php -A 4 "objectManager->create(" app/code | grep instanceof

Any hit where the argument came from a request parameter, block data, layout XML from a merchant-editable source or a database column, is the same bug. The fix is the same one line: is_a($className, TheInterface::class, true) before you construct anything.

¶Why this one is worth reading the diff for

Most Magento security patches are a sanitizer added somewhere obvious. This one is a set of ordering bugs, and ordering bugs are invisible in review because every line involved looks correct. $this->objectManager->create() is correct. instanceof BlockInterface is correct. Putting them in that sequence is the entire vulnerability, and no amount of static analysis was going to flag it.

The same is true of the report writers. Nothing was executing those files, no test would fail and the code had presumably looked fine to everyone who read it since 2.4.0. It took someone asking a different question: not “is this correct” but “what does this give an attacker that they did not have before”.

¶Invalidating admin passwords afterwards

A few people in the Magento Open Source Slack have asked for the quickest way to invalidate admin passwords after rotating encryption keys. Do it in SQL:

UPDATE admin_user SET password = 'invalid';
UPDATE admin_user_session SET status = 3 WHERE status = 1;

then truncate the tfa_user_config table and clear out your session storage.

I’ve written more on doing the above in this post.

The emails kept arriving. The contact form was never the way in.

¶reCAPTCHA on the contact form only covers the frontend area

When you enable reCAPTCHA for “Contact Us” in Magento, the protection comes from the Magento_ReCaptchaContact module. If you look at what that module actually ships, it wires up a single observer:

<event name="controller_action_predispatch_contact_index_post">
    <observer name="recaptcha_on_contact_form"
              instance="Magento\ReCaptchaContact\Observer\ContactFormObserver"/>
</event>

That observer runs on controller_action_predispatch_contact_index_post, the controller action behind the standard POST /contacts/index/post/ form submission. No token, and the request is redirected back to the form without sending anything. This part works. I confirmed it by posting to the form endpoint with a valid form key and no reCAPTCHA response, and the submission was correctly rejected.

The problem is that the contact form controller isn’t the only way to send that email.

¶The contactUs GraphQL mutation reaches the same mailer

Magento ships a contactUs GraphQL mutation as part of Magento_ContactGraphQl, and it’s enabled by default. Its resolver does this:

$this->mail->send($input['email'], ['data' => $input]);

That $this->mail is Magento\Contact\Model\MailInterface, the same mailer the form controller uses, sending the exact same configured contact email template. But the resolver has no reCAPTCHA check. GraphQL is also exempt from form key and CSRF validation, so there’s nothing to supply and nothing to forge.

A single request is all it takes:

curl -s -X POST "https://www.example.com/graphql" \
  -H "Content-Type: application/json" \
  --data '{"query":"mutation { contactUs(input: { name: \"Test\", email: \"test@example.com\", telephone: \"0000\", comment: \"Test\" }) { status } }"}'

A successful call returns {"data":{"contactUs":{"status":true}}} and fires the enquiry email. Loop that a couple of hundred times and you have the flood. Because GraphQL requests with no Store header resolve to the default store view, every email arrived branded as the default site regardless of which store the attacker referenced.

This is also why it’s so easy to miss when you go looking in the logs. The form POSTs show up clearly in the access log as POST /contacts/index/post/, and they were all being rejected. The requests that actually sent mail were POST /graphql, and nginx doesn’t log GraphQL request bodies, so there’s nothing in the access log that says contactUs at all.

¶Confirming reCAPTCHA really was working

Before backporting anything, I proved the form-level reCAPTCHA wasn’t just broken. The same host that ran the enquiry flood also hammered customer/account/createpost, which is protected by reCAPTCHA in exactly the same way. If reCAPTCHA had been failing open, those would have created accounts. Checking the database for the window in question, zero accounts were created. The gate was up and doing its job. The GraphQL mutation walked around it.

¶The fix landed in Magento 2.4.9

This is a genuine gap in core, and Adobe fixed it in Magento 2.4.9 (commit LYNX-941, “Implement ReCaptcha for missing GraphQl mutations”, shipped in magento/security-package 1.1.8). The ContactUs resolver itself is unchanged; the fix is on the reCAPTCHA side.

Server-side reCAPTCHA for web API and GraphQL endpoints is driven by CompositeWebapiValidationConfigProvider. Each reCAPTCHA module registers its endpoints into that provider via etc/di.xml. If you look at 2.4.8, the customer, checkout, newsletter, review, send-a-friend and PayPal modules all register. Magento_ReCaptchaContact ships no etc/di.xml at all, so contact is absent from the list. The 2.4.9 fix adds the missing registration and a small provider class that returns the existing contact validation config for the ContactUs endpoint.

¶Backporting the fix to 2.4.8

If you can’t jump to 2.4.9 immediately, I’ve packaged the backport as a small module and released it for free under the MIT licence: DeployEcommerce/module-contact-graphql-recaptcha. Drop it in, enable it, and the contactUs mutation is gated by your existing contact reCAPTCHA config.

If you’d rather understand what it’s doing or build your own, the fix backports cleanly because all the infrastructure it depends on already exists in 2.4.8. You need two files.

A provider that returns the contact validation config when it sees the ContactUs endpoint:

<?php
declare(strict_types=1);

namespace Vendor\ContactGraphQlReCaptcha\Model;

use Magento\ContactGraphQl\Model\Resolver\ContactUs;
use Magento\ReCaptchaUi\Model\IsCaptchaEnabledInterface;
use Magento\ReCaptchaUi\Model\ValidationConfigResolverInterface;
use Magento\ReCaptchaValidationApi\Api\Data\ValidationConfigInterface;
use Magento\ReCaptchaWebapiApi\Api\Data\EndpointInterface;
use Magento\ReCaptchaWebapiApi\Api\WebapiValidationConfigProviderInterface;

class WebapiConfigProvider implements WebapiValidationConfigProviderInterface
{
    private const CAPTCHA_ID = 'contact';

    public function __construct(
        private readonly IsCaptchaEnabledInterface $isEnabled,
        private readonly ValidationConfigResolverInterface $configResolver
    ) {
    }

    public function getConfigFor(EndpointInterface $endpoint): ?ValidationConfigInterface
    {
        if ($endpoint->getServiceMethod() === 'resolve'
            && $endpoint->getServiceClass() === ContactUs::class
            && $this->isEnabled->isCaptchaEnabledFor(self::CAPTCHA_ID)
        ) {
            return $this->configResolver->get(self::CAPTCHA_ID);
        }

        return null;
    }
}

And an etc/di.xml that registers it into the composite provider:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\ReCaptchaWebapiApi\Model\CompositeWebapiValidationConfigProvider">
        <arguments>
            <argument name="providers" xsi:type="array">
                <item name="vendor_recaptcha_on_contact_form" xsi:type="object">Vendor\ContactGraphQlReCaptcha\Model\WebapiConfigProvider</item>
            </argument>
        </arguments>
    </type>
</config>

Add the usual registration.php and etc/module.xml (sequence it after Magento_ReCaptchaContact, Magento_ReCaptchaWebapiApi and Magento_ContactGraphQl), and enable it. I deliberately kept this under my own vendor namespace rather than overriding Magento\ReCaptchaContact, so it does not collide with core when the platform is eventually upgraded to 2.4.9, at which point the module can be removed.

Because it reuses the contact validation config, it’s gated by the same reCAPTCHA settings you’ve already configured. Legitimate token-bearing submissions are unaffected; only the tokenless GraphQL calls get blocked.

¶Watch out for the DI cache

One thing that caught me out while testing: the providers argument on the composite provider is merged from di.xml and cached. Adding the module is not enough on its own: you have to compile DI and flush the cache, otherwise the merged config still reflects the old, ungated state and the mutation stays wide open with no obvious sign anything is wrong:

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

After that, re-run the contactUs curl from earlier. Instead of {"status":true} you’ll get a reCAPTCHA validation error, and no email is sent.

¶Checking your own stores

If you’re on 2.4.8 or earlier with Magento_ContactGraphQl enabled and you don’t have a headless or PWA storefront that actually needs it, the simplest fix is to disable the module:

bin/magento module:disable Magento_ContactGraphQl

That closes the hole entirely with no custom code. If you are using GraphQL, install the extension. Either way, rate-limit /graphql at the edge while you are in there. The contact form is the obvious thing to protect, but it’s rarely the only door into the same piece of functionality.

¶The fix

In most cases a reinstall of the base package re-triggers the deploy and the missing directories reappear:

composer reinstall magento/magento2-base

That forces Composer to remove and re-add the package, which runs the magento-composer-installer deploy step again and copies the mapped files back into place. Worth running bin/magento afterwards to confirm the CLI is back.

¶Why it happens

The deploy is handled by magento/magento-composer-installer, and there is a bug in its copy strategy. The Copy::createDelegate() method uses file_exists(), which dereferences symlinks, so when a symlink with a missing target sits at one of the mapped destination paths, the installer reads it as absent, tries to mkdir() over the existing link node and hits a silent File exists error.

The error swallowing is worse. DeployManager::doDeploy() catches the ErrorException but only logs it under -vvv verbosity, so the remaining mappings get skipped with no warning. The install reports success while setup/ and friends are partially or completely empty.

I’ve raised a GitHub issue with the full reproduction. There’s also a longstanding PR against magento-composer-installer that removes the exception suppression so composer install fails loud and early instead of leaving you with a broken but apparently fine install. It has been open for years awaiting review.

If the reinstall doesn’t stick, check for a dangling symlink at the target paths before assuming Composer is at fault.

The well-known trick is to click anywhere on the page and type thisisunsafe. That still works, and you can also call the command the phrase triggers directly from the DevTools console.

¶The command

Open DevTools on the interstitial page and run:

sendCommand(SecurityInterstitialCommandId.CMD_PROCEED)

Chrome reloads and takes you through to the site. The interstitial is an internal Chrome page that exposes a sendCommand function and a SecurityInterstitialCommandId enum, and CMD_PROCEED is the same code path the thisisunsafe shortcut fires.

CMD_PROCEED resolves to 1, so if the enum isn’t in scope you can fall back to:

sendCommand(1)

¶When to reach for it

This is for your own dev servers and self-signed certificates: the kind of cert warning you have already decided is safe to ignore. Handy when the thisisunsafe typing trick feels flaky, or when you want something scriptable against a known internal page.

Obvious caveat: never do this to get past a certificate warning on a site you do not control.

¶The problem

Products that were genuinely in stock were being indexed as out of stock (or the reverse) in Klevu. The Magento storefront showed the correct status, but Klevu disagreed. This only happened on a store using MSI with stock assigned to a non-default source.

¶Why it happens

Klevu’s product indexing module calculates stock status through ProductStockStatusProvider, and the method it uses is controlled by this config path:

klevu/indexing/product_stock_status_calculation_method

There are four options:

• stock_item
• stock_registry
• is_available
• is_salable

The default is stock_item. With that setting, Klevu calls getFromStockItem(), which reads the is_in_stock flag off the product’s StockItem extension attribute:

private function getFromStockItem(
    ProductInterface $product,
    ?StoreInterface $store,
): bool {
    $extensionAttributes = $product->getExtensionAttributes();
    $stockItem = $extensionAttributes?->getStockItem();

    // Replicating original behaviour pre: 4.4.0
    return $stockItem
        ? (bool)$stockItem->getIsInStock()
        : $this->getFromStockRegistry($product, $store);
}

That extension attribute is backed by the legacy cataloginventory_stock_item table. Under MSI, that legacy table is only kept in sync from the default source.

You can see this in Magento core, in SetDataToLegacyCatalogInventoryAtSourceItemsSavePlugin::afterExecute():

foreach ($sourceItems as $sourceItem) {
    if ($sourceItem->getSourceCode() !== $this->defaultSourceProvider->getCode()) {
        continue;
    }
    // ...
    $sourceItemsForSynchronization[] = $sourceItem;
}

$this->setDataToLegacyCatalogInventory->execute($sourceItemsForSynchronization);

Any source item that isn’t the default source is skipped. So if your sellable stock lives on a custom source, the legacy table never reflects it, and getFromStockItem() reads stale data. Klevu then indexes the wrong status.

¶The fix

Switch the calculation method to stock_registry:

klevu/indexing/product_stock_status_calculation_method = stock_registry

With that setting Klevu calls getFromStockRegistry() instead, which goes through StockRegistryInterface::getStockStatus():

private function getFromStockRegistry(
    ProductInterface $product,
    ?StoreInterface $store,
): bool {
    /**
     * MSI has a plugin on this method to get the correct stock.
     */
    $stockStatus = $this->stockRegistry->getStockStatus(
        productId: $product->getId(),
        scopeId: $store
            ? (int)$store->getWebsiteId()
            : null,
    );

    return (bool)$stockStatus->getStockStatus();
}

As the comment notes, MSI plugs into this method and returns the aggregated stock across every source assigned to the website’s stock, not just the default one. That is what you want on multi-source.

The setting lives under Stores → Configuration → Klevu → Developer Settings → Stock Status Calculation Method, and it’s a global (default scope) setting. You can also set it directly:

bin/magento config:set klevu/indexing/product_stock_status_calculation_method stock_registry

The field comment in the admin mentions something easy to skip: changing this setting requires a discovery or update of the product catalog before it takes effect on existing indexes. So after switching, requeue your products:

bin/magento klevu:indexing:entity-update --entity-types KLEVU_PRODUCT --entity-ids all

¶Which option to pick

On MSI, stock_registry is the right choice because it is MSI-aware. The is_available and is_salable options load the product per store and call isAvailable() / isSalable() respectively, which are heavier (they hit the product repository) but reflect salable quantity logic. The default stock_item is fine on single-source setups but, as above, will silently break once stock moves off the default source.

Here’s how to check the actual running versions by SSH’ing into your environment.

¶Valkey

$ valkey-server -v
Valkey server v=8.0.1 sha=4fbab574:0 malloc=jemalloc-5.3.0 bits=64 build=84a9272b225dd059

If your environment is still running Redis rather than Valkey, you can use redis-server -v instead.

¶MariaDB

$ mariadb -V
mariadb  Ver 15.1 Distrib 10.11.9-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Note the uppercase -V flag here - lowercase -v won’t give you what you need.

¶RabbitMQ

$ dpkg -s rabbitmq-server | grep Version
Version: 4.1.0-1

RabbitMQ doesn’t have a straightforward version flag like the others, so querying the installed package via dpkg is the simplest approach.

¶Why this matters

Knowing your actual service versions is useful when debugging compatibility issues, preparing for upgrades or verifying that a platform change has actually taken effect. It’s also handy when raising support tickets with Adobe - having the exact version numbers saves a fair amount of back and forth.

The SessionReaper attack targets session data to extract customer and admin credentials, and the PolyShell technique builds on this by disguising executable PHP within files that appear to be valid image uploads.

¶Blocking access at the edge with Fastly

If you’re running Adobe Commerce Cloud or any Magento instance fronted by Fastly, you can block access to these paths before requests ever reach your origin server. This is a fairly simple custom VCL snippet that returns a 403 for any request targeting media/custom_options/:

if (req.url ~ "^/media/custom_options/") {
  error 403 "Forbidden";
}

Add this as a custom VCL snippet in your Fastly configuration with the type set to recv and priority 1. This will catch any direct access attempts to files within that directory - whether they’re SessionReaper scripts, PolyShell payloads or anything else that has no business being served publicly.

¶Edge-level blocking over application-level blocking

Blocking at Fastly rather than at the application level means the request never reaches nginx, Varnish or PHP. This is important for two reasons - it reduces the attack surface significantly and it means even if an attacker has managed to upload a malicious file, they can’t execute it by requesting it directly through the public URL.

You should still be auditing your media/custom_options/ directory for any suspicious files and ensuring your Magento instance is patched, but adding this edge-level block is a solid defensive layer that takes seconds to deploy.

¶Important Note

If your store actively uses custom options with file upload fields on products, you’ll need to be more careful with this approach. Blanket blocking the entire media/custom_options/ path could interfere with legitimate file uploads that customers need to access. In that case you may need to refine the VCL to target specific file extensions or patterns rather than the whole directory.

¶Further reading

Sansec’s research on both of these attack vectors is well worth a read if you haven’t already:

• SessionReaper Exploitation - the session hijacking attack targeting customer and admin credentials
• Magento PolyShell - the PolyShell research that builds on the SessionReaper technique

With a bit of luck this saves you from a headache down the line. If you’re not already monitoring your media directories for unexpected PHP files, now is a good time to start.

French phone numbers are commonly written with dots as separators (e.g. 06.76.40.32.22), and Austrian numbers often use a forward slash (e.g. +43680/2149568). Both of these formats are rejected by Magento’s Telephone validator out of the box.

The Telephone model validator in vendor/magento/module-customer/Model/Validator/Telephone.php uses a regex pattern that doesn’t account for dots or slashes:

private const PATTERN_TELEPHONE = '/(?:[\d\s\+\-\()]{1,20})/u';

This means any customer trying to save their phone number in a perfectly valid international format gets hit with “Invalid Phone Number” - not a great experience.

The issue is tracked internally as ACP2E-4554 and was discussed in magento/magento2#40544 and magento/magento2#40545. The fix was committed but if you’re on a version that doesn’t include it yet, here’s a patch.

Here’s an m2-hotfixes patch that adds support for dots and forward slashes in telephone validation:

--- a/vendor/magento/module-customer/Model/Validator/Telephone.php
+++ b/vendor/magento/module-customer/Model/Validator/Telephone.php
@@ -21,9 +21,11 @@
      * \() :Matches open and close parentheses
      * \+: Matches the plus sign.
      * \-: Matches the hyphen.
+     * \.: Matches the dot character (e.g. 06.76.40.32.22)
+     * \/: Matches the forward slash (e.g. +43680/2149568)
      * \d: Digits (0-9).
      */
-    private const PATTERN_TELEPHONE = '/(?:[\d\s\+\-\()]{1,20})/u';
+    private const PATTERN_TELEPHONE = '/(?:[\d\s+().\/ -]{1,20})/u';

     /**
      * Validate telephone fields.
@@ -35,7 +37,7 @@
     {
         if (!$this->isValidTelephone($customer->getTelephone())) {
             parent::_addMessages([[
-                'telephone' => "Invalid Phone Number. Please use 0-9, +, -, (, ) and space."
+                'telephone' => "Invalid Phone Number. Please use 0-9, +, -, (, ), ., / and space."
             ]]);
         }

Save this as m2-hotfixes/ac-13791__telephone-validation-dots-slashes.patch (or whatever naming convention you use for your hotfixes directory).

The updated regex pattern '/(?:[\d\s+().\/ -]{1,20})/u' adds . and / to the allowed character set.

In the admin UI there’s a handy “Create Permanent Redirect for old URL” checkbox that appears when you change a product’s URL key. Behind the scenes, this sets url_key_create_redirect on the product - and you can pass exactly the same attribute in your API requests to get the same behaviour.

¶The API request

When updating a product’s URL key, include url_key_create_redirect alongside url_key in your custom_attributes array:

PUT /rest/V1/products/{sku}

{
  "product": {
    "custom_attributes": [
      {
        "attribute_code": "url_key",
        "value": "new-product-url-key"
      },
      {
        "attribute_code": "url_key_create_redirect",
        "value": "1"
      }
    ]
  }
}

Setting the value to 1 tells Magento to create a 301 redirect from the old URL to the new one. The redirect is written to the url_rewrite table with redirect_type set to 301.

If you want to suppress redirect creation entirely - for example during a bulk initial import where no old URLs exist yet - set the value to 0 or omit the attribute.

¶Why this matters for bulk operations

If you’re running a bulk URL key update across hundreds or thousands of products, you’ll want to be deliberate about this. Passing url_key_create_redirect: 1 on every product creates a redirect entry for each one, which can pile up in url_rewrite over time - especially if products have had multiple URL key changes.

It’s worth cleaning out stale redirects periodically, or being selective about which updates warrant a redirect versus which are clean-slate changes (new products, dev/staging refreshes, etc.).

¶Verifying the redirect was created

You can check the url_rewrite table directly after the API call:

SELECT *
FROM url_rewrite
WHERE entity_type = 'product'
  AND redirect_type = 301
  AND target_path LIKE '%new-product-url-key%'
ORDER BY url_rewrite_id DESC
LIMIT 10;

Or use the REST API to inspect the product’s URL rewrites:

GET /rest/V1/url-rewrites/products/{product_id}

With a bit of luck this saves you the debugging time of wondering why your URL key updates are silently dropping old links.

In Magento/Adobe Commerce, only configurable, bundle and grouped products should have child relationships. When simple products end up with children in these tables, it’s usually the result of a botched import, a failed product type conversion or some other data corruption.

¶Finding the problem

First, identify any invalid entries in catalog_product_relation where the parent is a simple product:

SELECT
    cpr.parent_id,
    cpr.child_id,
    parent.entity_id as parent_entity_id,
    parent.sku as parent_sku,
    parent.type_id as parent_type,
    child.entity_id as child_entity_id,
    child.sku as child_sku,
    child.type_id as child_type
FROM
    catalog_product_relation cpr
INNER JOIN
    catalog_product_entity parent ON cpr.parent_id = parent.row_id
INNER JOIN
    catalog_product_entity child ON cpr.child_id = child.row_id
WHERE
    parent.type_id = 'simple'
ORDER BY
    parent.entity_id, child.entity_id;

Similarly, check catalog_product_super_link for non-configurable parents (this table should only contain configurable product relationships):

SELECT
    cpsl.link_id,
    cpsl.product_id,
    cpsl.parent_id,
    parent.entity_id as parent_entity_id,
    parent.sku as parent_sku,
    parent.type_id as parent_type,
    child.entity_id as child_entity_id,
    child.sku as child_sku,
    child.type_id as child_type
FROM
    catalog_product_super_link cpsl
INNER JOIN
    catalog_product_entity parent ON cpsl.parent_id = parent.row_id
INNER JOIN
    catalog_product_entity child ON cpsl.product_id = child.row_id
WHERE
    parent.type_id != 'configurable'
ORDER BY
    parent.entity_id, child.entity_id;

You can also get a quick count of how many invalid entries exist:

SELECT 'catalog_product_relation' as table_name,
       COUNT(*) as invalid_count,
       'Parents with type_id=simple' as issue
FROM catalog_product_relation cpr
INNER JOIN catalog_product_entity parent ON cpr.parent_id = parent.row_id
WHERE parent.type_id = 'simple'

UNION ALL

SELECT 'catalog_product_super_link' as table_name,
       COUNT(*) as invalid_count,
       'Parents with type_id!=configurable' as issue
FROM catalog_product_super_link cpsl
INNER JOIN catalog_product_entity parent ON cpsl.parent_id = parent.row_id
WHERE parent.type_id != 'configurable';

¶Checking for orphans

While you’re at it, check for orphaned references where the parent or child product no longer exists:

-- Missing parents in catalog_product_relation
SELECT cpr.parent_id, cpr.child_id, 'Missing parent' as issue
FROM catalog_product_relation cpr
LEFT JOIN catalog_product_entity parent ON cpr.parent_id = parent.row_id
WHERE parent.row_id IS NULL;

-- Missing children in catalog_product_relation
SELECT cpr.parent_id, cpr.child_id, 'Missing child' as issue
FROM catalog_product_relation cpr
LEFT JOIN catalog_product_entity child ON cpr.child_id = child.row_id
WHERE child.row_id IS NULL;

¶Cleaning up

Back up your database first. Then remove the invalid entries:

-- Remove invalid entries from catalog_product_relation
DELETE cpr
FROM catalog_product_relation cpr
INNER JOIN catalog_product_entity parent ON cpr.parent_id = parent.row_id
WHERE parent.type_id = 'simple';

-- Remove invalid entries from catalog_product_super_link
DELETE cpsl
FROM catalog_product_super_link cpsl
INNER JOIN catalog_product_entity parent ON cpsl.parent_id = parent.row_id
WHERE parent.type_id != 'configurable';

After cleanup, reindex and clear cache:

bin/magento indexer:reindex
bin/magento cache:clean

One thing to consider - if those simple products should actually be configurable products, you’ll need to convert them rather than just deleting the relationships. The queries above assume the relationships themselves are the problem, not the product types.

Navigate to:

chrome://flags/#ai-mode-omnibox-entry-point

Set the flag to Disabled and relaunch Chrome.

claude --model claude-opus-4-5-20251101

You can also edit your config file to set this as the default if you want to use it by default rather than 4.6.

As you can now sign git commits with SSH keys rather than GPG and given that pretty much everyone already has an SSH key (and pretty much no one has a GPG key properly configured) - this is a much more practical approach.

Caleb Hearth has written an excellent post on how to set this up.

If you’re using GitHub, you’ll need to upload your SSH key separately as a signing key (distinct from your authentication key) - but once that’s done you’ll get the verified badge on your commits.

I’ll collate the release information here through the year and document
what has/hasn’t been released as per the official release schedule.

13/01/2026: No patches released, confirmed by Nathan Smith via Slack.

10/02/2026: There was a release planned but then was revoked. Currently no release planned.

10/03/2026: Pending

14/04/2026: Pending

12/05/2026: Pending, should be full semver release (well, Adobe’s attempt at it).

09/06/2026: Pending

14/07/2026: Pending

11/08/2026: Pending

08/09/2026: Pending

13/10/2026: Pending

10/11/2026: Pending

08/12/2026: Pending

Installing build dependencies...
  Installing php build dependencies: composer/composer
  W: Changed current directory to /app/.global/composer/composer
  W: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
  W: Loading composer repositories with package information
  W: Updating dependencies
  W: Your requirements could not be resolved to an installable set of packages.
  W:
  W:   Problem 1
  W:     - Root composer.json requires composer/composer 2.7.0 (exact version match: 2.7.0 or 2.7.0.0), found composer/composer[2.7.0] but these were not loaded, because they are affected by security advisories. To ignore the advisories, add ("PKSA-1gck-s111-yq7g", "PKSA-b8f7-zn44-r4gz", "PKSA-s25b-vbmp-jvhh") to the audit "ignore" config. To turn the feature off entirely, you can set "block-insecure" to false in your "audit" config.
  W:

E: Error building project: `composer` could not be run.

E: Error: Unable to build application, aborting.

To fix the issue, update the version of composer used to build your project in the .magento.app.yaml file:

dependencies:
    php:
        composer/composer: '^2.9'

For Magento 2.4.7 and up, use ^2.9, for anything else use ^2.2 which should give you 2.2.26.

A few of the team had looked into this but drawn a bit of a blank so I offered to take a look and it ended up being a fairly puzzling one to debug.

The same payload POST direct to a local running version of the application would give the expected 200 response, but when running through it’s production stack of Cloudflare and into the excellent Corefinity - we suddently started getting 400 response codes which was fairly odd as the custom controller that was receiving the payload had no code in it to return a 400 response.

My first thought was that Cloudflare was stopping the requests going due to either the body content or an OWASP ruleset. Running the requests through in no-proxy mode discounted this as being the issue.

A fairly important piece of debugging spotted that the nginx log presented the 400 error as well, so that ruled out Cloudflare being the issue.

I added some ancillary logging to fire whenever the controller Magento side fired to determine whether or not the request was even getting that far and fairly quickly realised that they weren’t even hitting Magento to return a 400 response.

My thoughts then shifted to either PHP’s post_max_size, or perhaps
max_input_vars set to low and the payload couldn’t be parsed. The additional logging never fired when the 400 was being returned so that pointed to nginx or varnish being the culprit.

At this point, I trapped a few of the outbound POST requests again and spotted that once they’d been through Cloudflare there was quite a number of headers and suspected that the issue we were actually running into was that nginx’s two configuration values were too low for:

client_header_buffer_size
large_client_header_buffers

This turned out to be the case, once these were increased the 400 errors soon
disappeared. We did also debug whether varnish was involved but fairly quickly
ruled out that being part of the issue. It was solely nginx.

If you ever encounter add odd 400 response for a webhook on any host, I can highly recommend that you check those two configuration values first and with a bit of luck I’ve saved you some debugging.

The best piece of advice I can give you is to isolate the point inside the stack you’re getting to when the 400 is thrown, that will help you narrow down what the cause is quickly.

If two import processes run concurrently in Magento 2.4.6, they can interfere with each other in unexpected ways. For example, if you’re simultaneously importing customers and products, product data might erroneously appear in the customer import process, causing failures. I discovered this while debugging a customer importer that ended up being fed stock source import data.

The issue stems from how Magento handles large import files using the importexport_importdata table. The default batch size limit is set to 100 records in vendor/magento/module-import-export/etc/config.xml. When an import exceeds this threshold, Magento splits the data across multiple rows in the database table and this is fed into the import
engine.

The problem occurs when concurrent imports add their validated data simultaneously to this shared table. Processes can then retrieve mixed or incorrect data from other running imports, leading to validation errors and data corruption.

¶Reproduction

- Open Magento admin in two separate browser sessions or systems
- Navigate to System > Data Transfer > Import in both
- In the first session: Select "Customers and Addresses" with 500+ records
- In the second session: Select "Catalog Product Import" with 50-60 records
- Validate both imports
- Click Import on the first system, then immediately click Import on the second

It’s fixed in this commit which was pushed out in 2.4.8. For 2.4.7, Adobe have provided this ACSD-63793_2.4.7-p3_v2.patch patch:

diff --git a/vendor/magento/module-import-export/Block/Adminhtml/Import/Edit/Form.php b/vendor/magento/module-import-export/Block/Adminhtml/Import/Edit/Form.php
index bf394c9ed0c42..11eaaa1a4a202 100644
--- a/vendor/magento/module-import-export/Block/Adminhtml/Import/Edit/Form.php
+++ b/vendor/magento/module-import-export/Block/Adminhtml/Import/Edit/Form.php
@@ -1,7 +1,7 @@
 <?php
 /**
- * Copyright © Magento, Inc. All rights reserved.
- * See COPYING.txt for license details.
+ * Copyright 2013 Adobe
+ * All Rights Reserved.
  */
 namespace Magento\ImportExport\Block\Adminhtml\Import\Edit;
 
@@ -264,6 +264,16 @@ protected function _prepareForm()
                 'value' => '',
             ]
         );
+        $fieldset->addField(
+            '_import_history_id',
+            'hidden',
+            [
+                'name' => '_import_history_id',
+                'label' => __('Import History id'),
+                'title' => __('Import History id'),
+                'value' => '',
+            ]
+        );
         $fieldsets['upload'] = $fieldset;
         $form->setUseContainer(true);
         $this->setForm($form);
diff --git a/vendor/magento/module-import-export/Controller/Adminhtml/Import/Validate.php b/vendor/magento/module-import-export/Controller/Adminhtml/Import/Validate.php
index c388851edcbe4..bf0758bb2105c 100644
--- a/vendor/magento/module-import-export/Controller/Adminhtml/Import/Validate.php
+++ b/vendor/magento/module-import-export/Controller/Adminhtml/Import/Validate.php
@@ -1,7 +1,7 @@
 <?php
 /**
- * Copyright © Magento, Inc. All rights reserved.
- * See COPYING.txt for license details.
+ * Copyright 2011 Adobe
+ * All Rights Reserved.
  */
 declare(strict_types=1);
 
@@ -50,6 +50,11 @@ public function execute()
                 $ids = $import->getValidatedIds();
                 if (count($ids) > 0) {
                     $resultBlock->addAction('value', Import::FIELD_IMPORT_IDS, $ids);
+                    $resultBlock->addAction(
+                        'value',
+                        '_import_history_id',
+                        $this->historyModel->getId()
+                    );
                 }
             } catch (\Magento\Framework\Exception\LocalizedException $e) {
                 $resultBlock->addError($e->getMessage());
diff --git a/vendor/magento/module-import-export/Model/History.php b/vendor/magento/module-import-export/Model/History.php
index 9a97367ba8453..ad0be7fbb8bc1 100644
--- a/vendor/magento/module-import-export/Model/History.php
+++ b/vendor/magento/module-import-export/Model/History.php
@@ -1,7 +1,7 @@
 <?php
 /**
- * Copyright © Magento, Inc. All rights reserved.
- * See COPYING.txt for license details.
+ * Copyright 2015 Adobe
+ * All Rights Reserved.
  */
 namespace Magento\ImportExport\Model;
 
@@ -9,33 +9,34 @@
  * Import history model
  *
  * @api
+ * @SuppressWarnings(PHPMD.CookieAndSessionMisuse)
  * @SuppressWarnings(PHPMD.CouplingBetweenObjects)
  * @SuppressWarnings(PHPMD.LongVariable)
  * @since 100.0.2
  */
 class History extends \Magento\Framework\Model\AbstractModel
 {
-    const HISTORY_ID = 'history_id';
+    public const HISTORY_ID = 'history_id';
 
-    const STARTED_AT = 'started_at';
+    public const STARTED_AT = 'started_at';
 
-    const USER_ID = 'user_id';
+    public const USER_ID = 'user_id';
 
-    const IMPORTED_FILE = 'imported_file';
+    public const IMPORTED_FILE = 'imported_file';
 
-    const ERROR_FILE = 'error_file';
+    public const ERROR_FILE = 'error_file';
 
-    const EXECUTION_TIME = 'execution_time';
+    public const EXECUTION_TIME = 'execution_time';
 
-    const SUMMARY = 'summary';
+    public const SUMMARY = 'summary';
 
-    const IMPORT_IN_PROCESS = 'In Progress';
+    public const IMPORT_IN_PROCESS = 'In Progress';
 
-    const IMPORT_VALIDATION = 'Validation';
+    public const IMPORT_VALIDATION = 'Validation';
 
-    const IMPORT_FAILED = 'Failed';
+    public const IMPORT_FAILED = 'Failed';
 
-    const IMPORT_SCHEDULED_USER = 0;
+    public const IMPORT_SCHEDULED_USER = 0;
 
     /**
      * @var \Magento\ImportExport\Helper\Report
@@ -122,7 +123,7 @@ public function addErrorReportFile($filename)
     public function updateReport(Import $import, $updateSummary = false)
     {
         if ($import->isReportEntityType()) {
-            $this->load($this->getLastItemId());
+            $this->load($import->getData('_import_history_id') ?? $this->getLastItemId());
             $executionResult = self::IMPORT_IN_PROCESS;
             if ($updateSummary) {
                 $executionResult = $this->reportHelper->getExecutionTime($this->getStartedAt());
diff --git a/vendor/magento/module-import-export/i18n/en_US.csv b/vendor/magento/module-import-export/i18n/en_US.csv
index cc1098841bab8..378daac3afa25 100644
--- a/vendor/magento/module-import-export/i18n/en_US.csv
+++ b/vendor/magento/module-import-export/i18n/en_US.csv
@@ -29,6 +29,7 @@ Import,Import
 "File to Import","File to Import"
 "Select File to Import","Select File to Import"
 "Images File Directory","Images File Directory"
+"Import History id","Import History id"
 "For Type ""Local Server"" use relative path to &lt;Magento root directory&gt;/var/import/images, e.g. <i>product_images</i>, <i>import_images/batch1</i>.<br><br>For example, in case <i>product_images</i>, files should be placed into <i>&lt;Magento root directory&gt;/var/import/images/product_images</i> folder.","For Type ""Local Server"" use relative path to &lt;Magento root directory&gt;/var/import/images, e.g. <i>product_images</i>, <i>import_images/batch1</i>.<br><br>For example, in case <i>product_images</i>, files should be placed into <i>&lt;Magento root directory&gt;/var/import/images/product_images</i> folder."
 "Download Sample File","Download Sample File"
 "Please correct the data sent value.","Please correct the data sent value."

As noted earlier, there’s more discussion and info on GitHub Issue #37593.

If you need to list versions of your service, you can do so using the Fastly CLI
tool using:

fastly service-version list -t API_KEY -s SERVICE_ID

This will return you a list of service versions and their associated dates:

NUMBER  ACTIVE  STAGED  LAST EDITED (UTC)
1        false    false    2020-06-09 17:25
2        false    false    2020-06-09 21:01
3        false    false    2020-06-10 00:08
4        false    false    2020-06-10 02:27
5        false    false    2020-06-10 06:40
6        false    false    2020-06-10 09:02
7        false    false    2020-06-11 16:07
8        false    false    2020-06-25 20:02
9        false    false    2020-06-25 20:02
10       false    false    2020-07-13 08:42
11       false    false    2020-07-13 08:43
12       false    false    2020-07-22 10:09
13       false    false    2020-07-28 20:07
14       false    false    2020-07-28 19:51
15       false    false    2020-08-03 12:04
16       false    false    2020-09-29 20:04
17       false    false    2020-10-02 12:03
18       false    false    2020-10-29 21:32
19       false    false    2020-12-01 12:03
20       false    false    2021-01-07 12:57
21       false    false    2021-01-07 12:58
22       false    false    2021-01-07 12:59
23       false    false    2021-01-07 13:01
24       false    false    2021-01-30 08:05
25       false    false    2021-02-16 10:41
26       false    false    2021-02-17 09:17
27       false    false    2021-03-18 14:29
28       false    false    2021-03-31 08:04
29       false    false    2021-05-06 10:14
30       false    false    2021-05-10 10:08
31       false    false    2021-05-10 10:09
32       false    false    2021-05-12 14:01
33       false    false    2021-05-30 08:05
34       false    false    2021-06-07 21:07
35       false    false    2021-06-07 21:19
36       false    false    2021-07-16 10:08
37       false    false    2021-07-16 11:11
38       false    false    2021-07-29 08:04
39       false    false    2021-09-27 08:05
40       false    false    2021-11-10 16:15
41       false    false    2021-11-11 17:39
42       false    false    2021-11-15 11:52
43       false    false    2021-11-26 08:04
44       false    false    2021-12-09 11:28
45       false    false    2022-01-25 08:04
46       false    false    2022-01-28 09:34
47       false    false    2022-02-08 16:30
48       false    false    2022-03-08 10:46
49       false    false    2022-03-26 08:04
50       false    false    2022-03-29 01:53
51       false    false    2022-04-19 12:27
52       false    false    2022-05-18 08:30
53       false    false    2022-05-25 08:04
54       false    false    2022-07-24 08:03
55       false    false    2022-07-24 08:03
56       false    false    2022-08-17 13:23
57       false    false    2022-09-20 08:21
58       false    false    2022-09-22 08:04
59       false    false    2022-09-27 13:47
60       false    false    2022-09-27 13:56
61       false    false    2022-09-28 09:11
62       false    false    2022-10-03 09:02
63       false    false    2022-10-19 13:56
64       false    false    2022-11-21 08:02
65       false    false    2022-12-06 05:43
66       false    false    2022-12-08 15:14
67       false    false    2022-12-13 09:31
68       false    false    2022-12-13 09:34
69       false    false    2022-12-22 16:00
70       false    false    2022-12-22 16:04
71       false    false    2023-01-20 08:03
72       false    false    2023-01-27 12:45
73       false    false    2023-02-23 16:15
74       false    false    2023-03-21 08:02
75       false    false    2023-04-21 16:07
76       false    false    2023-04-21 16:34
77       false    false    2023-04-21 16:46
78       false    false    2023-04-21 18:25
79       false    false    2023-04-21 20:16
80       false    false    2023-04-22 11:53
81       false    false    2023-04-22 12:03
82       false    false    2023-04-24 09:39
83       false    false    2023-04-24 09:55
84       false    false    2023-04-24 09:56
85       false    false    2023-04-24 10:00
86       false    false    2023-04-24 10:07
87       false    false    2023-04-27 13:05
88       false    false    2023-04-27 13:07
89       false    false    2023-05-02 08:35
90       false    false    2023-05-02 10:22
91       false    false    2023-05-20 08:04
92       false    false    2023-05-24 17:20
93       false    false    2023-05-25 09:28
94       false    false    2023-05-31 18:13
95       false    false    2023-07-06 12:34
96       false    false    2023-07-19 08:05
97       false    false    2023-08-15 09:41
98       false    false    2023-08-15 09:41
99       false    false    2023-08-15 10:51
100      false    false    2023-08-15 10:52
101      false    false    2023-08-15 14:31
102      false    false    2023-08-22 07:08
103      false    false    2023-08-22 13:45
104      false    false    2023-08-22 15:21
105      false    false    2023-08-22 15:26
106      false    false    2023-08-22 15:25
107      false    false    2023-08-22 15:25
108      false    false    2023-09-06 21:37
109      false    false    2023-08-22 15:26
110      false    false    2023-09-15 13:28
111      false    false    2023-09-15 13:38
112      false    false    2023-09-17 08:04
113      false    false    2023-09-23 05:36
114      false    false    2023-09-23 05:49
115      false    false    2023-09-23 06:12
116      false    false    2023-09-25 06:09
117      false    false    2023-10-05 05:58
118      false    false    2023-10-05 06:35
119      false    false    2023-10-05 09:06
120      false    false    2023-10-05 09:08
121      false    false    2023-10-05 09:09
122      false    false    2023-10-05 09:29
123      false    false    2023-10-27 07:20
124      false    false    2023-11-07 14:24
125      false    false    2023-11-16 08:04
126      false    false    2023-11-20 12:45
127      false    false    2023-12-12 08:05
128      false    false    2023-12-13 17:57
129      false    false    2024-01-15 08:04
130      false    false    2024-03-01 10:44
131      false    false    2024-03-15 08:05
132      false    false    2024-04-10 14:16
133      false    false    2024-04-10 14:20
134      false    false    2024-05-02 18:39
135      false    false    2024-05-14 08:05
136      false    false    2024-05-17 10:23
137      false    false    2024-05-17 10:26
138      false    false    2024-05-17 10:31
139      false    false    2024-05-17 10:34
140      false    false    2024-05-17 12:24
141      false    false    2024-05-17 12:25
142      false    false    2024-05-17 12:28
143      false    false    2024-05-21 09:11
144      false    false    2024-05-21 09:17
145      false    false    2024-05-21 09:30
146      false    false    2024-05-21 09:30
147      false    false    2024-05-21 12:22
148      false    false    2024-06-03 10:03
149      false    false    2024-06-19 06:07
150      false    false    2024-06-28 06:55
151      false    false    2024-07-05 12:05
152      false    false    2024-07-08 07:14
153      false    false    2024-07-08 11:52
154      false    false    2024-07-09 07:25
155      false    false    2024-07-13 08:03
156      false    false    2024-07-19 06:28
157      false    false    2024-07-19 06:57
158      false    false    2024-07-22 11:32
159      false    false    2024-08-16 12:39
160      false    false    2024-09-11 08:04
161      false    false    2024-09-25 17:58
162      false    false    2024-10-14 21:41
163      false    false    2024-10-22 07:29
164      false    false    2024-10-22 22:09
165      false    false    2024-11-10 08:04
166      false    false    2024-11-13 14:30
167      false    false    2024-11-22 08:03
168      false    false    2024-12-17 08:42
169      false    false    2024-12-22 03:13
170      false    false    2024-12-22 03:58
171      false    false    2025-01-09 08:04
172      false    false    2024-12-22 03:53
173      false    false    2025-01-29 21:54
174      false    false    2025-01-29 21:54
175      false    false    2025-02-13 14:20
176      false    false    2025-03-10 08:05
177      false    false    2025-03-21 08:44
178      false    false    2025-03-21 12:03
179      false    false    2025-03-21 15:12
180      false    false    2025-03-21 15:13
181      false    false    2025-03-25 23:02
182      false    false    2025-05-08 16:36
183      false    false    2025-05-09 08:03
184      false    false    2025-05-15 16:18
185      false    false    2025-05-21 11:16
186      false    false    2025-05-24 13:15
187      false    false    2025-06-11 13:24
188      false    false    2025-07-08 08:03
189      false    false    2025-07-29 16:18
190      false    false    2025-08-06 16:26
191      false    false    2025-09-05 14:48
192      false    false    2025-09-06 08:04
193      false    false    2025-09-08 17:38
194      false    false    2025-09-11 22:18
195      false    false    2025-09-22 07:00
196      false    false    2025-09-22 23:59
197      false    false    2025-10-14 16:04
198      false    false    2025-10-20 12:13
199      false    false    2025-10-20 13:25
200      false    false    2025-10-21 12:16
201      false    false    2025-11-05 08:04
202      false    false    2025-11-20 10:58
203      false    false    2025-11-20 10:46
204      false    false    2025-11-20 11:30
205      false    false    2025-11-20 11:53
206      true     false    2025-11-20 11:53

From here, you can activate one of those versions by running this command:

fastly service-version activate --version=204 -t API_KEY -s SERVICE_ID

You can fetch both your API_KEY key and SERVICE_ID from the file mounted at:

/mnt/shared/fastly_tokens.txt

in your Commerce Cloud cluster if you don’t have the tokens to hand.

curl -H "Fastly-Key: API_KEY” -X POST "https://api.fastly.com/service/SERVICE_ID/purge_all"

You can fetch both your API_KEY key and SERVICE_ID from the file mounted at:

/mnt/shared/fastly_tokens.txt

in your Commerce Cloud cluster.

REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

[2025-04-08T10:29:29.486342+00:00] 
ERROR: Magento version '2.4.7.0-patch5' does not support Valkey backend 
model '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

There is a Github issue for this problem. That
latest release of ece-tools does have a fix for the issue albeit not a great fix.

W: Unable to apply data patch Magento\Company\Setup\Patch\Data\SetComp
W: anyForStructure for module Magento_Company. Original exception message: SQL
W: STATE[42000]: Syntax error or access violation: 1305 FUNCTION abcdefghijk 
W: .REGEXP_LIKE does not exist, query was: UPDATE `company_structure` SET `com
W: pany_id` = ? WHERE (REGEXP_LIKE(path, '^7(/.+)?$'))

I sent this in to Adobe’s Cloud support and got this Absolute gem of a response from support:

We investigated this further and please find more details regarding this error below:

W: Unable to apply data patch Magento\Company\Setup\Patch\Data\SetComp
W: anyForStructure for module Magento_Company. Original exception message: SQL
W: STATE[42000]: Syntax error or access violation: 1305 FUNCTION abcdefghijk
W: .REGEXP_LIKE does not exist, query was: UPDATE company_structure SET com W: pany_id = ? WHERE (REGEXP_LIKE(path, ‘^7(/.+)?$’))

The Adobe Commerce version 2.4.6-p10 uses the function “REGEXP_LIKE” in the file \Magento\Company\Setup\Patch\Data\SetCompanyForStructure.

The function “REGEXP_LIKE” is not supported in hashtag MariaDB which is the default Database used by Adobe Commerce.

No idea how this one got through QA.

If you pin the version of the B2B extension to 1.4.2-p3 it’ll work or you could patch out that function.