In short: The Shopware 6 vulnerability that many merchants are searching for right now is really a flaw in PHP. Shopware updates do not close it. You need patched PHP with a restart of all processes, and afterwards you should check .env, custom/plugins, the public directory and the API integrations.
What PHP2Shell means for Shopware 6
Shopware 6 is built on the PHP framework Symfony and usually runs with PHP-FPM behind Nginx or Apache. The flaws CVE-2026-109618 and CVE-2026-109619 affect exactly this operating mode. According to the PHP team, they allow remote code execution without logging in to the shop.
An attacker with code execution on the server reaches everything the shop itself can access: customer data, orders, invoice documents, credentials for merchandise management and payment providers. We explain the technical background under What is PHP2Shell?.
Checking the Shopware 6 vulnerability: which PHP is really running?
Shopware 6 is largely maintained from the command line, for example with bin/console. This invites a mistake: php -v shows the version of the command-line PHP, not necessarily that of PHP-FPM, which handles the shop requests. On many servers, several PHP versions are installed in parallel.
Reliable sources are the entry in the hosting panel for the specific domain and the host's confirmation of the package status. Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; backports can carry older numbers. Which PHP versions your Shopware version supports can be found in the system requirements in the documentation on shopware.com. How to check for yourself is described under Checking the PHP version and patch level correctly.
One point is often overlooked with Shopware 6: many shops process the message queue and scheduled tasks via permanently running background processes, for example bin/console messenger:consume under a process manager. These processes load PHP once at startup. After the update, not only PHP-FPM but also these workers must therefore be restarted. Otherwise part of the shop keeps working with the old, vulnerable PHP in memory.
Directories and files you should know
| Location | Content | Why it matters |
|---|---|---|
.env, .env.local |
Database credentials, APP_SECRET, other keys |
Renew if you suspect an incident |
public/ |
Document root with index.php, media, theme files |
Additional PHP files are suspicious |
public/theme/ |
Compiled JavaScript and CSS files of the storefront | Place for injected skimmers |
custom/plugins/, custom/apps/ |
Extensions | Modified plugin code |
files/ |
Private files such as invoices and delivery notes | Personal data |
var/log/ |
Shop logs | Secure the traces |
Harmless first checks:
# Show installed plugins with version and status
bin/console plugin:list
# List PHP files in the public directory
find public -type f -name "*.php"
# Show known vulnerabilities in Composer dependencies
composer audit
Only a few, known PHP files should be in the public/ folder. Anything unknown should be secured and examined, not deleted immediately.
In the administration, under Settings > System, check the sections "Users & permissions" and "Integrations". Unknown users or API integrations are a backdoor that every file scan misses.
Admin access, plugins and apps as a risk
By default, the administration is located at /admin. Protect it with personal accounts, strong authentication and, if possible, an access restriction to known networks. Integrations for merchandise management, marketplaces or shipping providers should only have the permissions they really need.
Plugins from the store and custom developments bring their own PHP code, and apps additionally bring webhooks to external servers. The more extensions, the larger the attack surface and the more laborious every PHP upgrade. Remove plugins that are no longer used completely.
What a Shopware update can and cannot do
An update of Shopware or of a plugin closes known bugs in that code. It cannot:
- patch PHP on the server,
- restart old PHP-FPM processes,
- safely remove foreign files in
public/or manipulated theme files, - delete foreign users or integrations,
- prove that nothing happened before the patch.
After a PHP update to a new major version, you should regenerate the cache and theme and check the shop in a test environment. On request, our PHP patch service handles the PHP switch with documentation.
Larger merchants often run Shopware 6 on several app servers. In that case every server must be patched and restarted, including those that only process background tasks. If a service provider operates the shop as a managed platform, they should confirm the status of all nodes to you.
How does PHP SOS help?
- We establish which PHP your shop actually uses via FPM and clarify the patch and restart with your host or agency.
- We secure logs from 20 October 2026 onward, the database and the files.
- We check
public/, compiled theme files, plugins, users and integrations for anomalies. - If we find something, we clean up the shop together with your agency and renew keys and access credentials in an orderly way.
Frequently asked questions
Is Shopware 6 itself affected by PHP2Shell?
The flaws are in PHP, not in the Shopware code. Every Shopware 6 shop on unpatched PHP is therefore potentially vulnerable, regardless of the Shopware version. A Shopware update changes nothing about that.
Which file in Shopware 6 is particularly critical after an attack?
The .env or .env.local file with the database credentials and APP_SECRET. Anyone who could read it knows your access credentials. If you suspect an incident, these values should be renewed, in coordination with your agency.
What are integrations in Shopware 6 and why check them?
Integrations are API accesses for external systems such as merchandise management or marketplaces. A foreign integration with administrator rights allows full access to the shop via the API without any file lying on the server.