A new security reality for commerce

As threats evolve, speed matters more—and everyone in the Shopware ecosystem has a part to play.

The security landscape is changing: AI-assisted research is helping researchers and attackers find weaknesses and develop working exploits faster. We are expanding our security work, hardening Shopware, and improving how security fixes reach shops. Keeping shops protected is a shared effort: our work has the greatest impact when merchants make security an operational priority, agencies deploy updates promptly, and extension partners keep their code secure and dependencies up to date.

What we are doing at Shopware

Publishing security patches remains an essential part of our work. But addressing individual vulnerabilities is only one part of adapting to this situation.

Expanding the security team

We are expanding our security team to strengthen both proactive security work and our response to findings.

This includes reviewing designs and code, improving automated checks, and helping development teams address recurring root causes.

We also want to improve report triage and fix coordination, turning lessons from findings into practical guidance and safer development patterns across Shopware.

If you want to help improve the security of Shopware and its ecosystem, have a look at our open positions.

Looking for vulnerabilities proactively

We continue to combine regular, externally conducted penetration testing with our existing bug-bounty program, through which researchers can responsibly report vulnerabilities. Additionally, we are actively scanning for vulnerabilities using the most capable AI models available to us.

These approaches complement each other. External researchers bring different perspectives, while AI-assisted analysis helps us examine more code and possible interactions. A model's output still needs to be validated: a plausible description is not proof that a vulnerability exists, and a scan that finds nothing is not proof that the code is secure.

Therefore, we treat AI as an additional tool for finding problems, not as a replacement for security engineering or the researchers who work with us.

We already use the latest advances in AI to scan incoming code. At the same time, we need to find and fix weaknesses in existing code, prioritizing findings according to their potential impact and the risk they pose to shops.

The likely outcome is more security fixes and more frequent security releases. That is a positive consequence of finding and addressing weaknesses that might previously have remained undetected. Agencies, merchants, and extension partners should be prepared for this increased update cadence and have a process in place to apply security fixes promptly.

Making exploit chains harder to complete

Fixing the initial vulnerability is important, but we also need to look at what an attacker could do after gaining an initial foothold.

For example, an attacker who gains limited access should not automatically be able to turn that access into broader control over the shop. That depends on the boundaries between different parts of the system and on which operations remain possible with the access they have gained.

We will further harden these boundaries to block common exploit chains and limit the impact of an initial compromise. This does not make the original vulnerability acceptable or remove the need to patch it. It adds protection for cases where one defense has already failed.

We are also improving the forensic data available to help detect and investigate attacks. The goal is to make it easier to identify exploitation attempts while they are happening and, if an incident occurs, reconstruct what happened and understand which parts of the shop were affected.

Making security fixes easier to apply

Publishing a security fix gives merchants a way to protect their shops, but it also gives attackers clues about the vulnerability. Getting that protection into production quickly is therefore just as important as making it available. Once a vulnerability is disclosed, exploitation attempts can follow quickly and may be automated. Shops affected by that vulnerability need a process that gets protection into production promptly.

We are rethinking how we deliver security patches so that securing a shop requires less time and coordination. Agencies and merchants need to be able to apply protection quickly without turning every security update into a larger upgrade project.

We are strengthening the testing, compatibility, and reliability of security updates, building on what we have learned from previous releases. The goal is to help merchants and agencies apply protection quickly and with confidence.

Why the security landscape is changing

Security updates have always been part of running an online shop. However, the number of security reports we receive and the pace at which attackers act on disclosed vulnerabilities have changed considerably. That has consequences for how we develop Shopware, but also for how extensions are maintained and production shops are operated.

Our own reporting data helps explain why we are strengthening these efforts. The following chart shows Shopware 6 bug-bounty reports and security advisory records created over time.

These figures include unpublished advisory records and do not represent distinct confirmed vulnerabilities; reports and advisories do not map one to one.

The increase in findings does not tell us how many shops are affected or compromised. More reports do not, by themselves, show that the software has become less secure. They show that more potential weaknesses are being reported and investigated. AI-assisted research can uncover vulnerabilities that likely remained undetected before these tools became available.

However, those tools are available to attackers as well. If a security researcher can find an issue with AI, we have to assume that a bad actor may independently find it too. Responsible disclosure therefore cannot be treated as a period in which only the researcher and the vendor know about a vulnerability. The time available to investigate, fix, and deploy protection may be much shorter, even before an advisory is published.

Once an advisory is public, we already see automated exploitation attempts within days. So both parts matter: acting quickly on incoming reports and getting the resulting protection into production promptly.

This is an industry-wide challenge

AI-assisted research is changing both how many weaknesses are found and how readily they can be turned into working attacks.

The recent PHP security release illustrates this: PHP2Shell researchers used AI to help demonstrate exploitation of a long-standing weakness whose impact had remained unproven.

Software does not have to change for its practical exposure to change—the tools available to researchers and attackers can change around it.

Other projects are seeing a similar increase in security findings. In a recent post about Symfony and Twig, Fabien Potencier described a sharp rise in reports and advisories alongside the growing use of AI in security research.

These are just a few examples of what has happened across the wider ecosystem in the last month alone:

• Magento and Adobe Commerce: Sansec reproduced four BlockStrap exploit routes within 24 hours of Adobe’s patch.
• WordPress: Patchstack observed probing within hours of a security patch, followed by exploitation attempts the next day.
• Shopify's app ecosystem: Selleasy reported an incident involving injected scripts that redirected customers to phishing pages.

These examples illustrate a shared challenge across platforms and their ecosystems, not a comparison of vendors' security records.

What this means for extension partners

A shop consists of more than Shopware core. Extensions can handle customer data, expose API routes, process files, or change what happens during checkout. Their security is therefore part of the security of the shop itself.

In successful attacks we have investigated, third-party extensions have already been used as part of the attack. This is not just a theoretical concern that might become relevant at some point in the future.

If you maintain extensions, start reviewing them now. A useful starting point is to look at where data enters your extension and what a caller is allowed to do with it:

• Are permissions and ownership checked on the server, rather than only in the Administration interface?
• Is untrusted input handled safely before it reaches database queries, templates, or file operations?
• Are the libraries your extension depends on current and free of known vulnerabilities?
• Could limited access to one feature be combined with another feature to gain more access than intended?

AI-assisted reviews can help with this work, but the findings still need to be checked against the actual behavior of the extension.

We are also exploring how additional tools and processes could help extension partners identify vulnerabilities, coordinate findings, and deliver security fixes more easily. In parallel, partners should start reviewing their code and addressing the issues they find.

What agencies and merchants should do

For practical guidance on supported versions, infrastructure security, and extension management, see our Security Best Practices guide.

Know which responsibilities your hosting model covers

With Shopware SaaS, we take care of securing and maintaining the platform and its infrastructure, including automatically applying platform updates and security patches.

You do not need to manage servers or install the Security Plugin yourself.

With Shopware PaaS Native, we manage the underlying infrastructure, including servers, networking, managed databases, and platform backups, and provide a web application firewall enabled by default.

You or your agency still manage the application: testing and deploying Shopware, Security Plugin, extension, and dependency updates, and securing your custom code.

You also select a supported, compatible PHP version in the application configuration.

Runtime extension management is already disabled; extensions are managed through Composer and deployments.

Managed infrastructure and a firewall do not replace prompt application updates.

In both models, merchants remain responsible for their configuration, access and user management, and the security of external apps and integrations they operate or connect.

For self-hosted shops, infrastructure security also needs to be managed by you or your hosting provider.

Keep the Security Plugin installed and up to date

We are changing our recommendation for self-hosted shops.

Previously, we recommended the Shopware Security Plugin primarily when a platform update could not be deployed immediately.

We now recommend keeping it installed, activated, and up to date with a version compatible with the shop, even when the platform itself is already fully up to date. See our Security Plugin guide for the updated recommendation, compatibility, and installation instructions.

Having the plugin in place makes it easier to apply the next security update promptly.

Make sure your shop runs a Shopware version that is still receiving security support, as shown in our release policy.

The plugin changelog lists the issues fixed by each plugin release.

The Security Plugin provides a fast way to apply supported fixes to known vulnerabilities in Shopware’s own code, especially when a complete platform update cannot be deployed immediately. It does not replace updates to PHP, third-party dependencies, extensions, or Shopware itself. Additional hardening and broader security improvements are delivered in regular Shopware releases and are usually not backported through the plugin. Keeping Shopware and its extensions up to date therefore remains essential to benefit from those additional layers of protection.

When a relevant Security Plugin release becomes available, update it as soon as possible. Do not defer that work to the next weekly or monthly maintenance window. We see automated exploitation attempts within days of advisory publication, so a process that routinely leaves shops unprotected for weeks does not match the threat.

That does not mean skipping validation. It means having a process in place that allows an urgent security update to be checked and deployed promptly, separately from larger feature releases or routine maintenance.

If you suspect your shop has already been compromised, applying a security update alone does not establish that it is clean; contact your hosting provider and agency first, and follow our guide to responding to a cyberattack.

Treat security communication as an operational task

When we send a security notice, it needs to reach someone who can act on it. Receiving an email is not the same as protecting the shop.

Agencies and merchants should agree on who receives those notices, who checks whether a shop is affected, and who is responsible for deploying the required protection. The handover between merchant, agency, and hosting provider should already be clear before an urgent update arrives.

We also have a responsibility to make our communication clear and actionable. Security notices should explain what is affected, what action is required, and how urgently it needs to happen. Please treat that communication seriously and follow the instructions for the specific issue.

Conclusion: Adapt the processes around the software too

Shopware is adapting how we find vulnerabilities, harden the platform, and deliver protection.

Here are the steps the ecosystem can take now:

• Check that your Shopware version is still receiving security support using our release policy.
• Keep a compatible Security Plugin installed, activated, and up to date.
• Agree who receives security notices, assesses whether your shop is affected, and deploys urgent updates.
• If you maintain extensions, review your code for security weaknesses and deliver fixes promptly.