What exactly is an AI agent?

An AI agent does more than simply answer questions. It can receive a goal, determine the steps required to achieve it, retrieve information and then perform actions in other systems.

A customer could, for example, tell a shopping agent: “Find me a black office chair for less than €500 that can be delivered this week.”

The agent could then search for suitable products and merchants, compare prices and availability and, where supported, prepare the checkout process.

The agent itself would normally not run inside the Magento store. It could be part of a search engine, an AI assistant, a shopping platform or a procurement system.

The roles can be simplified like this:

How does the agent find the store?

UCP does not handle the entire discovery process itself. An agent may find a merchant through a search engine, product index, marketplace, product feed or a predefined list of suppliers.

Once the agent knows the domain of a store, it can check whether that store supports UCP. The store publishes a machine-readable profile under:

/.well-known/ucp

This profile describes which UCP capabilities the store supports and how they can be accessed.

An agent could therefore discover a Magento store through a normal product search and then determine: This merchant supports UCP and allows me to access its catalogue and start a checkout.

This is where UCP becomes particularly relevant for Magento merchants.

Making Magento accessible to AI agents

A Magento store already contains almost everything a shopping agent needs: products, prices, inventory, carts, customers, shipping methods, payment methods and orders.

A UCP integration therefore does not need to recreate these functions. Instead, it acts as an additional interface between Magento and external agents.

UCP does not automatically replace Magento REST or GraphQL. A Magento extension could continue to use existing Magento services, service contracts, REST or GraphQL internally while exposing those capabilities externally through UCP.

The important difference is that a completely separate integration should not be required for every individual platform. The store describes its capabilities in a standardised way, allowing a compatible agent to discover and use them.

What could an AI agent do with a Magento store?

Possible use cases include product search and product advice, checking prices and stock levels, building a cart, selecting shipping options, preparing a checkout or retrieving an order status.

This can also become particularly interesting in B2B commerce. A company could provide its purchasing agent with a list of approved suppliers. The agent would not even need to search the web for those stores. It could directly check which suppliers support UCP and which products are currently available.

For a Magento merchant, the important question is therefore less:

“How do I build an AI agent?”

and much more:

“How do I make my products and commerce capabilities available so that AI agents can work with them?”

That is where UCP comes in.

Alongside the browser, mobile apps, REST and GraphQL, this may create another way of accessing a Magento store. A customer would no longer necessarily have to operate the storefront directly. An AI agent could take over parts of the purchasing process on their behalf.

Would you like to know what UCP and AI agents could mean for your Magento store? Feel free to contact me. We can look at which interfaces and use cases would actually make sense for your store.

The vulnerabilities CVE-2026-109618 and CVE-2026-109619 may, under certain conditions, allow attackers to execute code on the server, potentially without being logged in first. Both were rated 9.2 in severity.

Why older Magento stores are especially affected

Many Magento 1 installations still rely on PHP 5.x or PHP 7.x. Older Magento 2 versions may also depend on specific PHP versions.

Switching to PHP 8.3 or 8.4 can therefore break a store. Outdated libraries, custom extensions and Magento core modifications can turn an upgrade into a substantial project.

The problem is: PHP 5.x and PHP 7.x no longer receive regular security updates. A store that ran perfectly yesterday may therefore face significant additional risk today.

Older PHP 8 versions may also be affected. A version number beginning with 8 does not, by itself, mean a system is secure.

What can store owners do now?

The good news is that reducing the immediate risk does not always require a complete Magento upgrade straight away.

Depending on your server configuration, consider the following:

• Secure your web server: Block malicious requests as early as possible through Apache, nginx or an upstream firewall.
• Harden PHP configuration: Disable unnecessary PHP functions and restrict dangerous request processing at the server level.
• Protect the admin area: Add extra protection for Magento admin and reduce unnecessary public access.
• Check your hosting environment: Ask whether your provider supplies security fixes for the older PHP release you use.
• Review Magento extensions: Remove unused functionality and restrict potentially vulnerable interfaces.

Important: These measures do not replace a security patch for PHP itself. They can limit some attack vectors but cannot provide complete protection. In some cases, taking a vulnerable installation temporarily offline may be necessary.

Why not simply upgrade PHP?

With a current Magento 2 store, moving to a supported PHP version may be relatively straightforward if the installed extensions are compatible.

Magento 1 and older Magento 2 installations are different. Their dependencies must be reviewed first. Some extensions can be adapted; elsewhere, a more substantial modernization may be required.

A blanket PHP upgrade is therefore not a good idea. The store still needs to work properly after the security changes.

I can help secure your Magento store

Running Magento 1 or Magento 2 on PHP 5.6, 7.4 or another outdated PHP version and unsure how to respond to the latest security vulnerabilities?

Please contact me.

I can assess your Magento installation, PHP environment and options for short-term mitigation. The first priority is understanding the real exposure and implementing sensible measures without unnecessarily disrupting a working store.

If a lasting upgrade is needed, we can plan the appropriate route, from adapting individual extensions to a full Magento upgrade.

Further information

Official details about the vulnerabilities, affected PHP versions and available patches can be found directly from PHP development team.

Use the following query to display URL rewrites for a specific SKU:

SELECT
    p.sku,
    u.store_id,
    s.code AS store_code,
    s.name AS store_name,
    u.request_path,
    u.target_path,
    u.redirect_type
FROM url_rewrite AS u
JOIN catalog_product_entity AS p
    ON u.entity_id = p.entity_id
LEFT JOIN store AS s
    ON s.store_id = u.store_id
WHERE u.entity_type = 'product'
  AND p.sku = 'MEINE-SKU'
ORDER BY u.store_id, u.request_path;

request_path contains the URL visible to customers, while target_path points to Magento’s internal target. The field store_id bzw. store_name identifies which store view each rewrite belongs to.

Several entries for one product are not necessarily duplicates or errors. Different store_id values usually mean Magento maintains separate rewrites for different store views.

Also useful is redirect_type. The value 0 means a normal rewrite without a redirect, 301 and 302 indicate permanent and temporary redirects respectively.

After changing URL keys, migrating or importing data, this query helps you see which rewrites Magento actually stores for a product.

grep -RInP 'ObjectManager\s*::\s*getInstance\s*\(' app/code

For example, the search may find:

$objectManager = \Magento\Framework\App\ObjectManager::getInstance();

$productRepository = $objectManager->get(
    \Magento\Catalog\Api\ProductRepositoryInterface::class
);

The regular expression accounts for different amounts of whitespace around :: and before the opening parenthesis. The option -R performs a recursive search, -n prints line numbers, and -P enables grep’s Perl-compatible regular expressions.

You can also look for subsequent calls through a variable called $objectManager :

grep -RInP '\$objectManager\s*->\s*(get|create)\s*\(' app/code

In custom Magento code, direct ObjectManager use is generally Bad Practicenot recommended. The main reason is that it hides a class’s dependencies. You cannot see which services a class needs from its constructor, because it fetches them later from the ObjectManager.

That makes the code harder to understand and test. With dependency injection, you can replace a dependency with a mock object in a unit test. If a class retrieves the service itself from the global ObjectManager, the test must also account for that hidden access.

Changes become more difficult as well. A class that takes five services in its constructor clearly declares its dependencies. If it fetches those services across several methods, you must read the entire class to find them.

It is cleaner to pass dependencies through the constructor:

use Magento\Catalog\Api\ProductRepositoryInterface;

public function __construct(
    private ProductRepositoryInterface $productRepository
) {
}

Magento then resolves the concrete implementation through dependency injection configuration. Preferences, proxies, plugins and other ObjectManager mechanisms still work, but your class does not need to know how a dependency is constructed.

The ObjectManager itself is not inherently bad: Magento relies on it internally. The problem is directly using it throughout application code, turning dependency injection into a hidden service locator.

bin/magento setup:db:status

Magento compares the database state with the installed modules and reports whether an upgrade is still needed.

If everything is current, setup:upgrade does not need to run unnecessarily. If Magento reports a version mismatch, perform the upgrade.

bin/magento setup:upgrade

bin/magento module:status

Magento groups the output into List of enabled modules and List of disabled modules. This quickly shows whether an extension is actually loaded or merely exists in the filesystem.

You can also inspect an individual module:

bin/magento module:status Vendor_Module

After deployments, upgrades or manual changes to app/code , this is a quick way to confirm whether Magento considers a module enabled.

A module directory existing on disk does not automatically mean the module is enabled.

bin/magento indexer:status

If an indexer reports Reindex required, you can rebuild it individually. First, use the following command to find its indexer ID:

bin/magento indexer:info

For example, you can rebuild just the product price index:

bin/magento indexer:reindex catalog_product_price

Of course, bin/magento indexer:reindex can rebuild all indexes at once. On larger Magento 2 stores, it is often better to check which index is actually affected.

The following SQL query lists the 20 largest tables, including data size, index size and total size:

SELECT
    TABLE_NAME AS Table_Name,
    TABLE_ROWS AS Rows_Estimated,
    ROUND(DATA_LENGTH / 1024 / 1024, 2) AS Data_MB,
    ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS Index_MB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS Total_MB,
    ROUND(DATA_LENGTH / 1024 / 1024 / 1024, 3) AS Data_GB,
    ROUND(INDEX_LENGTH / 1024 / 1024 / 1024, 3) AS Index_GB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 3) AS Total_GB
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'YOUR_MAGENTO_DATABASE'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

YOUR_MAGENTO_DATABASE Replace this with the actual name of your Magento database. You can find it, for example, in app/etc/env.php under dbname.

The Total_MB and Total_GB are particularly useful because it includes data and indexes. This helps spot unusually large cron, quote, log or extension tables.

The column Rows_Estimated should be treated only as an approximate value for InnoDB. For locating especially large tables, DATA_LENGTH and INDEX_LENGTH are more important.

The query does not change any data and is a useful first check before investigating why your Magento database has grown so large.

Flush Magento Cache roughly means: remove the cache entries Magento knows belong to Magento.

bin/magento cache:clean

bzw.

bin/magento c:c

Magento clears its own entries but leaves the underlying cache storage intact.

Flush Cache Storage instead means: Clear the entire cache storage currently used by Magento.

bin/magento cache:flush

bzw.

bin/magento c:f

Think of it as a drawer: cache:clean removes only Magento’s items from the drawer. cache:flush empties the entire drawer.

This matters with Redis, for example. If another application uses the same Redis storage, Flush Cache Storage may remove that application’s cache data too.

For normal cache maintenance, Flush Magento Cache. Flush Cache Storage is generally sufficient. The other option is more drastic and should be used only when the entire cache storage really needs to be emptied.

Enable maintenance mode and allow your own IP address with:

bin/magento maintenance:enable --ip=123.123.123.123

Other visitors will then see the maintenance page while the allowlisted IP can still access the store.

Check the current status at any time with:

bin/magento maintenance:status

When the work is finished, disable maintenance mode again:

bin/magento maintenance:disable

This is particularly useful for Magento upgrades and deploymentsbecause you can test the frontend before reopening the store to everyone.