A critical vulnerability affecting Adobe Commerce and Magento Open Source has emerged as one of the most significant e-commerce security incidents of recent weeks.

Tracked as CVE-2026-75650, the vulnerability carries a CVSS score of 10.0 and is particularly significant because attackers began exploiting it before Adobe released a security fix.

However, one distinction is just as important as the vulnerability itself:

111,495 stores may potentially fall within the broader exposure landscape. That does not mean 111,495 stores were compromised.

In cybersecurity reporting, the difference between exposure and confirmed compromise is critical, particularly when dealing with a high-profile zero-day vulnerability.

What Is CVE-2026-75650?

CVE-2026-75650 is a critical vulnerability related to improper neutralisation of input within Magento’s template engine.

The vulnerability can allow an unauthenticated attacker to inject PHP code through Magento’s "styles" template property.

More importantly, exploitation does not require authentication or user interaction.

The injected code can execute when the standard “Payment Transaction Failed Reminder” email template is rendered. This creates a significant attack surface for affected Adobe Commerce and Magento environments exposed to the internet.

A Genuine Zero-Day

This is not a conventional case where a security patch was released and organisations simply failed to deploy it quickly enough.

According to the available research, exploitation of CVE-2026-75650 began on 4 September 2026.

Adobe released the corresponding hotfix on 7 September 2026.

This means attackers were actively exploiting the vulnerability approximately three days before the official fix became available.

CVE-2026-75650 should therefore be treated as a genuine pre-patch zero-day rather than a delayed-patching incident.

CISA subsequently added the vulnerability to its Known Exploited Vulnerabilities (KEV) Catalogue on 8 September.

Which Versions Are Affected?

Precise version identification is essential in this case.

The affected product ranges are:

• Adobe Commerce 2.4.4–2.4.9
• Adobe Commerce B2B 1.3.3–1.5.3
• Magento Open Source 2.4.6–2.4.9

There is an important distinction on the Magento Open Source side.

Some summaries have suggested that Magento Open Source versions beginning with 2.4.4 are affected. However, the available technical scope identifies Magento Open Source 2.4.6 and later as the affected range.

Organisations should therefore verify their exact product branch and patch level rather than relying on generalised statements such as “we are running Magento 2.4”.

Were 111,495 Stores Really Compromised?

No — at least not based on the evidence currently available.

The figure 111,495 represents StoreLeads' Q1 2026 estimate of active Magento and Adobe Commerce installations worldwide.

In other words, it represents an estimated installation population.

It is not a confirmed victim count.

Some headlines have presented this figure as though 111,495 stores had been “hit” or compromised. However, the underlying research does not support that conclusion.

As of Sansec's tracking updated on 13 September, exploitation had clearly been observed, but no aggregate number of compromised stores had been publicly confirmed.

The available reporting refers to individual victims and states that stores were being compromised, demonstrating that active exploitation was real and ongoing.

What remains unknown is the total number of successfully compromised environments.

What Are the Attackers Doing After Exploitation?

Research identified two unrelated attackers operating within the same exploitation window.

One attack chain involved a Rust-based backdoor that changed process names over time in an attempt to blend into the operating system.

Observed names included:

• gvfsd-user
• kworker
• fc-cache
• chronyd

These names may normally resemble legitimate Linux processes or services. Their context therefore matters.

Processes using these names while executing from directories such as /tmp or inappropriate user cache locations should be treated as suspicious and investigated.

A separate PHP web-shell operator was also observed exploiting the vulnerability on 7 September.

This illustrates a common characteristic of high-profile zero-days: once exploitation becomes public or widely understood, the vulnerability rapidly attracts additional opportunistic threat actors.

What Should Adobe Commerce and Magento Operators Do?

The first priority is to determine whether the environment falls within the affected version range.

Organisations running Adobe Commerce 2.4.4–2.4.9, Commerce B2B 1.3.3–1.5.3, or Magento Open Source 2.4.6–2.4.9 should verify that the relevant VULN-39341 / APSB26-146 hotfix has been applied.

However, patching alone should not be considered sufficient.

Security teams should also investigate the environment for indications of compromise.

Particular attention should be given to processes such as:

gvfsd-user

kworker

fc-cache

chronyd

These should be reviewed carefully if they are executing from /tmp, user cache directories, or other unexpected locations.

Where available, teams should also hunt for associated backdoor hashes, command-and-control infrastructure, web-shell artefacts and other relevant indicators of compromise.

For environments that were exposed before the patch became available, forensic triage should be considered part of the remediation process rather than an optional follow-up activity.

Being Patched Does Not Mean You Were Never Compromised

This is one of the most important lessons from any actively exploited zero-day.

An environment may be fully patched today and still have been compromised yesterday.

If an attacker gained access before the security update was applied, they may already have established persistence, deployed a backdoor or created another mechanism for maintaining access.

Security teams should therefore ask two separate questions:

Has the vulnerability been patched?

and

Was the system compromised before it was patched?

For actively exploited vulnerabilities, vulnerability management and incident response must operate together.

Exposure and Compromise Are Not the Same Metric

CVE-2026-75650 also demonstrates a broader problem in cybersecurity reporting.

An exposure count and a confirmed victim count represent fundamentally different things.

If a vulnerable technology has more than 100,000 active installations worldwide, this does not mean that more than 100,000 systems have been compromised.

Likewise, a CVSS score of 10.0 tells us about the technical severity of a vulnerability.

It does not tell us how many organisations were successfully attacked.

CVSS describes the severity and characteristics of the vulnerability.

Victim counts describe observed outcomes.

Conflating the two can significantly distort how an incident is communicated and understood.

As highlighted in CyberDistro's analysis, the size of an exposed population should never automatically be presented as the number of confirmed victims.

Conclusion

CVE-2026-75650 represents a serious security issue for the Adobe Commerce and Magento ecosystem.

Its CVSS 10.0 rating, unauthenticated exploitation path and confirmed exploitation before a patch became available all justify treating it as a high-priority security incident.

At the same time, organisations should be equally careful about how the scale of the incident is interpreted.

111,495 stores may represent the broader installation population potentially relevant to the vulnerability.

It does not represent 111,495 confirmed compromises.

The right approach is therefore to answer two questions independently:

How many systems could be exposed?

and

How many systems can we confirm were actually compromised?

At CyberDistro, we work with VARs, MSPs and system integrators across Türkiye and the wider region to help organisations distinguish between vulnerability exposure, exploitability and confirmed compromise through a broader vulnerability and exposure management portfolio.

If your organisation operates Adobe Commerce or Magento Open Source, do not limit your response to patch deployment alone.

Verify your exact product branch, apply the relevant hotfix, investigate for indicators of compromise and assess whether exploitation may have occurred before remediation.

Because during a critical zero-day incident, the question is not only:

“Are we vulnerable?”

The more important question may be:

“Could someone already have gained access?”