A critical compatibility bug in Shopware Security Plugin 2.0.25 caused affected online stores to return HTTP 500 errors immediately after updating the extension. The problem was reported on November 12, 2026, and confirmed by Shopware developers. In certain Shopware 6.5 installations, the update introduced a fatal Twig error that prevented storefront pages from rendering.
The failure occurs when the updated security plugin attempts to access a Twig function that no longer exists in newer versions of the template engine. As a result, customers may encounter an HTTP 500 Internal Server Error instead of product pages, category listings or checkout screens.
Shopware responded on the same day by releasing Security Plugin 2.0.26, which fixes the confirmed compatibility problem. However, store administrators should understand which versions are affected, how to recognize the error and how to restore their stores without unnecessarily disabling security protections.
What Happened After the Shopware Security Plugin 2.0.25 Update?
On November 12, 2026, an administrator reported that installing and activating the official Shopware Security Plugin version 2.0.25 caused the storefront to stop working.
The problem was documented in Shopware GitHub issue #22897.
The affected environment was running Shopware 6.5.8.9 with Twig 3.20.0 and PHP 8.2.
Before the update, the storefront operated normally with Security Plugin 2.0.24. After installing version 2.0.25, pages using Twig templates with attribute access began returning HTTP 500 errors.
The original report involved a custom storefront theme, but the investigation identified a compatibility problem in the interaction between Shopware, Twig and the security plugin rather than demonstrating that the custom theme itself was defective.
The failure was subsequently reproduced by Shopware developers. Another user independently reported the same error on a different Shopware installation.
Exact Error: Call to Undefined Function twig_get_attribute()
The most important diagnostic indicator is the PHP error generated while Shopware attempts to render a Twig template.
The original report included the following exception:
StorefrontException:
Can not render @BlankeSystems/storefront/page/content/index.html.twig view:
An exception has been thrown during the rendering
of a template:
Call to undefined function twig_get_attribute()The precise template path can vary depending on the active theme and the page being rendered.
The decisive part of the error is:
Call to undefined function twig_get_attribute()This indicates that Shopware is attempting to call a global Twig function that is unavailable in the installed version of Twig.
The resulting HTTP 500 response is a server-side failure. It is not simply a browser rendering problem or a missing CSS or JavaScript resource.
Which Shopware Versions Are Affected?
The confirmed cases involve older Shopware 6.5 releases combined with newer versions of Twig and Security Plugin 2.0.25.
| Component | Confirmed environment 1 | Confirmed environment 2 |
|---|---|---|
| Shopware | 6.5.8.9 | 6.5.8.7 |
| Security Plugin | 2.0.25 | 2.0.25 |
| Twig | 3.20.0 | 3.11.0 |
| PHP | 8.2 | 8.3 |
| Observed result | HTTP 500 | Same Twig compatibility error |
A further analysis of Shopware’s source code identified a potentially affected range from Shopware 6.5.4.0 through 6.5.8.16 when combined with Twig 3.9 or newer.
This range was determined by examining the relevant Shopware code and dependency constraints. It does not mean that every possible version combination was individually tested.
The same analysis indicated that Shopware 6.5.8.17 and later use a different implementation that avoids this particular function call.
Administrators should therefore check the complete combination of Shopware, Twig and Security Plugin versions rather than assuming that every Shopware 6.5 installation is affected.
Why Does Security Plugin 2.0.25 Cause a Fatal Twig Error?
The root cause is a compatibility conflict introduced by a security-related change in the way Shopware processes Twig template attributes.
To understand the failure, it is necessary to examine how the security plugin interacts with the Twig rendering engine.
The Role of GuardCompiler
Security Plugin 2.0.25 introduced changes involving a component named GuardCompiler.
This component modifies how certain compiled Twig operations are processed so that security checks can be applied before template attributes are accessed.
In the affected execution path, calls that would normally use:
CoreExtension::getAttribute()are redirected through:
TemplateContextGuard::getAttribute()The guard is associated with a security fix identified as:
GHSA-59j5-8mv2-2fc5The intention is to preserve security checks around template attribute access.
However, older Shopware versions use a different implementation for retrieving some attributes.
The Problem With sw_get_attribute()
In affected Shopware versions, the security guard can delegate attribute handling to:
sw_get_attribute()For certain values, including arrays rather than Shopware Struct objects, the implementation calls:
twig_get_attribute()This creates the compatibility problem.
The global function twig_get_attribute() is no longer available in Twig 3.9 and later.
Consequently, the affected execution path attempts to call a function that does not exist.
The Complete Failure Sequence
The problematic execution path can be summarized as follows:
Shopware renders a Twig template
|
v
Template accesses an attribute
|
v
Security Plugin GuardCompiler intercepts the call
|
v
TemplateContextGuard::getAttribute()
|
v
sw_get_attribute()
|
v
twig_get_attribute()
|
v
Undefined function
|
v
PHP exception
|
v
HTTP 500 Internal Server ErrorBefore the 2.0.25 update, newer Twig versions could compile attribute access directly through CoreExtension::getAttribute().
The updated security mechanism changed that execution path, exposing an older Shopware implementation that was incompatible with the installed Twig version.
This explains why the same storefront could work with Security Plugin 2.0.24 but fail immediately after installing 2.0.25.
Why Can This Bug Make an Entire Online Store Unavailable?
Twig is a central component of Shopware’s storefront rendering process.
It is used to generate the HTML displayed to customers, including product pages, category listings, navigation elements and checkout interfaces.
If a template attempts to access an attribute through the affected execution path, the rendering process can fail before the page is successfully generated.
When this occurs, the server may return:
HTTP/1.1 500 Internal Server ErrorThe practical consequences depend on which templates are executed.
Product and Category Pages May Become Inaccessible
If affected Twig templates are used throughout the storefront, customers may be unable to view products or navigate categories.
This can interrupt normal shopping activity even though the database and application server remain operational.
Checkout May Become Unavailable
If the same error occurs while rendering the checkout, customers may be unable to complete purchases.
In such a situation, incoming advertising traffic and existing customer sessions may reach an unusable storefront.
The original report confirms an HTTP 500 storefront failure. It does not establish that every affected installation experiences an identical failure on every page.
Store Administration May Also Be Disrupted
Reports on the Shopware community forum described installations where both the storefront and administration became inaccessible after installing the security update.
However, an HTTP 500 error in the administration does not necessarily have the same technical cause as the confirmed twig_get_attribute() problem.
Different PHP exceptions require separate investigation, even when they appear immediately after the same plugin update.
Potential Revenue Loss During Downtime
An unavailable storefront can prevent new orders from being placed.
For stores running paid advertising campaigns, downtime may also result in advertising clicks reaching an error page rather than a functioning product or checkout page.
The incident did not establish that order records were deleted or that customer payment information was compromised.
The confirmed issue is a compatibility-related storefront failure, not a demonstrated database corruption or payment-processing vulnerability.
Shopware Released Security Plugin 2.0.26 to Fix the Error
Shopware developers reproduced the issue on November 12, 2026, and confirmed that the existing test matrix had not covered the affected combination of Shopware and Twig versions.
The team initially announced that a corrected 2.x release would follow.
Later the same day, Shopware confirmed that Security Plugin 2.0.26 had been released specifically to resolve the reported Twig compatibility problem.
The original GitHub issue was subsequently closed as completed.
| Security Plugin version | Status |
|---|---|
| 2.0.24 | Did not trigger the confirmed error in the original test environment |
| 2.0.25 | Introduced the reported Twig compatibility regression |
| 2.0.26 | Released by Shopware to fix the confirmed regression |
For Shopware 6.5 installations affected by the exact twig_get_attribute() exception, updating to Security Plugin 2.0.26 is the manufacturer’s confirmed solution.
Administrators should not confuse this release with a complete Shopware platform upgrade. Security Plugin 2.0.26 belongs to the 2.x extension branch used with Shopware 6.5.
How to Fix Shopware HTTP 500 After Updating the Security Plugin
If a Shopware store stopped working immediately after the Security Plugin update, the recovery process should begin by identifying the actual PHP exception.
Step 1: Confirm the Installed Versions
Check the Shopware core version, Security Plugin version, PHP version and installed Twig package.
On installations with command-line access, the installed Twig version can be checked from the project directory with:
composer show twig/twigThe installed Shopware plugins can be inspected with:
php bin/console plugin:listLook for the plugin named:
SwagPlatformSecurityThese commands should be run from the Shopware project directory using the appropriate PHP environment.
If the Shopware console itself fails, inspect Composer’s installed package information and the deployment records instead.
Step 2: Search the Application Logs for the Twig Exception
Check Shopware application logs, PHP logs and web server error logs.
The Shopware log directory is typically:
var/log/Search for:
twig_get_attribute
StorefrontException
TemplateContextGuard
GuardCompilerFor example, from the project directory:
grep -R "twig_get_attribute" var/log/If the expected application log entry is missing, inspect the configured PHP-FPM and web server logs.
The exact log file locations depend on the operating system, hosting environment and logging configuration.
Step 3: Back Up the Store Before Making Changes
Before deploying another extension update, ensure that a current and restorable backup is available.
The backup should cover the database, application files, configuration and any custom extensions that may affect the update.
For stores deployed through Composer and a continuous integration pipeline, make the change in the deployment source rather than modifying production files independently.
Step 4: Update SwagPlatformSecurity to 2.0.26
The main recovery action is to install the corrected Security Plugin version 2.0.26 using the installation method already employed by the store.
For Shopware installations managed through the administration, use the extension management interface when it is accessible.
For Composer-managed installations, update the appropriate plugin dependency in the project and deploy the resulting package changes through the normal release process.
Shopware’s official Security Plugin documentation describes the supported installation and update approaches.
Do not install a Security Plugin branch intended for a different major Shopware version.
Shopware 6.5 uses the 2.x branch, while newer Shopware platform branches use their corresponding maintained plugin branches.
Step 5: Clear the Shopware Cache
After successfully deploying the corrected plugin, clear the application cache:
php bin/console cache:clearThis allows Shopware to rebuild cached components and templates using the updated code.
In a multi-server environment, verify that all application nodes are running the corrected plugin version and have refreshed their caches.
Step 6: Test the Storefront and Checkout
After the update, test the main storefront functions rather than relying only on the disappearance of the original error.
Verify that:
- The homepage loads successfully.
- Category pages display their products.
- Individual product pages render correctly.
- Product variants can be selected.
- Products can be added to the cart.
- The checkout page loads.
- Customer login and account pages work.
- The administration is accessible.
- Custom theme components render without PHP exceptions.
Where possible, complete a controlled test order using a safe test payment method.
Finally, review the application logs to confirm that the twig_get_attribute() exception no longer occurs.
Should You Disable the Shopware Security Plugin to Restore the Store?
Disabling the entire security plugin is not the preferred solution.
The Shopware Security Plugin provides protection against known vulnerabilities in Shopware’s own code.
Deactivating the extension may remove multiple security protections, even when only one individual fix is responsible for a compatibility problem.
Before version 2.0.26 became available, Shopware developers suggested a temporary workaround for affected installations: disable only the individual security fix identified as:
GHSA-59j5-8mv2-2fc5and clear the cache.
This approach could restore storefront rendering while leaving other plugin security fixes enabled.
However, disabling an individual security fix also removes the protection provided by that fix.
Now that Security Plugin 2.0.26 is available, updating to the corrected version is preferable to leaving a security measure disabled.
If a temporary configuration change was made during incident recovery, verify that the relevant fix is active again after installing the corrected release.
Why Downgrading to Security Plugin 2.0.24 Is Not the Best Long-Term Solution
The original report confirmed that the storefront worked with Security Plugin 2.0.24 and failed with 2.0.25 in the tested environment.
This comparison was useful for identifying the regression.
However, the fact that an older plugin version does not trigger the error does not make it the preferred long-term configuration.
Security Plugin 2.0.25 introduced additional security-related changes. Returning to an older version may leave the installation without protections introduced in the newer release.
Where the exact Twig compatibility problem is confirmed, Security Plugin 2.0.26 provides a more appropriate recovery path because it addresses the regression without requiring administrators to remain on the earlier extension version.
What If Shopware Still Returns HTTP 500 After Updating to 2.0.26?
Not every HTTP 500 error following a Security Plugin update is caused by the same incompatibility.
Administrators should compare the exact exception rather than assuming that every failure is related to twig_get_attribute().
For example, a separate Shopware Community Forum discussion described a Shopware 6.5.2.1 installation that continued to fail after updating to Security Plugin 2.0.26.
That installation produced a different PHP error involving a security fix class derived from AbstractAppLoader and missing abstract method implementations.
This is not the same exception as the confirmed Twig compatibility regression in issue #22897.
If Security Plugin 2.0.26 does not restore an affected store, check:
- The exact PHP exception and stack trace.
- The installed Shopware core version.
- The installed Twig version.
- The active security fixes.
- The plugin’s compatibility with the Shopware installation.
- Whether custom extensions introduce additional conflicts.
- Whether all deployment nodes are using the same plugin version.
A different fatal error requires its own diagnosis and should not automatically be attributed to the resolved twig_get_attribute() issue.
How to Prevent Similar Failures During Shopware Security Updates
Security updates should be installed promptly, but they still require controlled deployment procedures.
The confirmed Shopware incident demonstrates that even a small extension update can introduce a compatibility issue involving a particular combination of core and dependency versions.
Test Updates Against the Actual Dependency Versions
A staging environment should closely match the production system.
Testing only the Shopware core version is not always sufficient. The installed Twig version, PHP runtime, custom theme and other Composer dependencies can influence the outcome.
Where possible, use a staging environment built from the same Composer lock file as production.
Keep Composer Dependencies Consistent
A production installation should not accidentally receive different dependency versions across application nodes or deployments.
Using a controlled dependency lock file helps ensure consistent installation results.
Shopware also maintains the shopware/conflicts package to identify dependency combinations known to be incompatible with particular Shopware versions.
However, compatibility controls do not guarantee that every possible combination of versions has already been tested.
Monitor HTTP 500 Errors After Deployment
After updating a production store, monitor response codes and application errors.
Useful indicators include:
- A sudden increase in HTTP 500 responses.
- New PHP fatal errors in application logs.
- Unexpected failures on product or category pages.
- Checkout errors after the deployment.
- Failed customer account operations.
- Errors appearing only when specific themes or templates are rendered.
Automated availability checks can help detect storefront failures quickly.
However, checking only the homepage may miss errors occurring on product pages, customer accounts or checkout screens.
Have a Recovery Plan Before Updating
Before installing security-related extensions, verify that the previous application state can be restored if an unexpected failure occurs.
The recovery plan should include access to server logs, deployment history, backups and a method for installing corrected extension versions even when the administration is unavailable.
For larger installations, it should also cover multiple application servers and cache consistency.
Does This Error Mean the Shopware Store Has Been Hacked?
No. The confirmed twig_get_attribute() error is a software compatibility problem.
The failure occurs because the updated security plugin follows an execution path that references a function unavailable in newer Twig versions.
An HTTP 500 response alone does not establish that an attacker gained access to the store.
The Security Plugin update was security-related, but the compatibility regression itself is not evidence of a successful attack, data theft or compromised payment information.
If there are separate indicators of unauthorized activity, those should be investigated independently.
Frequently Asked Questions
Why does Shopware return HTTP 500 after updating the Security Plugin?
Security Plugin 2.0.25 introduced a compatibility regression affecting certain Shopware 6.5 installations using Twig 3.9 or later. The affected rendering path attempts to call the unavailable twig_get_attribute() function, causing an exception and HTTP 500 response.
Which Security Plugin version fixes the twig_get_attribute error?
Shopware released Security Plugin 2.0.26 on November 12, 2026, to resolve the confirmed issue.
Is Shopware 6.5.8.9 affected?
Yes. The original confirmed report involved Shopware 6.5.8.9, Twig 3.20.0, PHP 8.2 and Security Plugin 2.0.25.
Does the problem affect all Shopware 6.5 stores?
No. The issue depends on the combination of Shopware core version, Twig version and the affected security plugin code. Not every Shopware 6.5 installation uses the problematic execution path.
Is the problem caused by a custom Shopware theme?
The original exception occurred while rendering a custom theme, but the technical investigation identified a compatibility issue between the security plugin and older Shopware Twig integration code. A custom theme is not necessarily the root cause.
Should I disable SwagPlatformSecurity if my store crashes?
Disabling the entire plugin removes its security protections. For the confirmed Twig regression, the preferred solution is updating to Security Plugin 2.0.26. Temporary disabling of an individual affected security fix was suggested before the corrected version became available, but this reduces the protection provided by that fix.
Will clearing the Shopware cache fix the issue?
Clearing the cache alone does not correct an incompatible function call. It is an important step after deploying the fixed plugin, but the underlying code must first be corrected.
Can the error affect checkout and online sales?
Yes. If the exception occurs while rendering customer-facing storefront or checkout templates, those pages may fail to load. The exact impact depends on which templates are executed in the affected installation.
Does Security Plugin 2.0.26 fix every HTTP 500 error?
No. It fixes the specific Twig compatibility issue confirmed in Shopware GitHub issue #22897. Other PHP exceptions after the update may have different causes.
What Shopware Store Owners Should Do Now
Administrators using Shopware 6.5 should check their installed Security Plugin version, particularly if they experienced an HTTP 500 error immediately after upgrading to 2.0.25.
If the logs contain Call to undefined function twig_get_attribute(), the error matches the compatibility issue confirmed by Shopware developers.
The recommended resolution is to install the corrected Security Plugin 2.0.26, clear the application cache and verify that product pages, the shopping cart, customer accounts and checkout are functioning normally.
Affected stores should also verify that security fixes remain enabled after recovery.
For production e-commerce environments, this incident highlights the importance of maintaining compatible dependency versions, testing security updates against realistic staging environments and monitoring the full purchasing process immediately after deployment.
0 comments