Add StyleSmuggler vulnerability (CVE-2026-75650) page

docs/best-practices/security/how-to-deal-with-the-stylesmuggler-vulnerability-cve-2026-75650-on-hypernode.md

@@ -0,0 +1,166 @@
+---
+myst:
+  html_meta:
+    description: StyleSmuggler (CVE-2026-75650) is an unauthenticated remote code
+      execution vulnerability in Magento and Adobe Commerce. Learn how Hypernode protects
+      your shop, how to fix it, and what to do if your shop was compromised.
+    title: How to Deal with the StyleSmuggler Vulnerability (CVE-2026-75650) on Hypernode
+      | Security | Hypernode
+---
+
+# How to Deal with the StyleSmuggler Vulnerability (CVE-2026-75650) on Hypernode
+
+StyleSmuggler is an unauthenticated remote code execution vulnerability in Magento Open Source and Adobe Commerce, tracked as CVE-2026-75650 and scored CVSS 10.0. This article explains how the vulnerability works, what Hypernode does to protect your shop, how to fix it, and what to do if your shop was compromised.
+
+For a full analysis of the attacks, the backdoors and a complete list of indicators of compromise, see [StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack](https://sansec.io/research/stylesmuggler-0day) by Sansec.
+
+## What Is StyleSmuggler?
+
+Sansec saw the first exploitation on 4 September 2026 at 22:20 UTC and published the vulnerability on 5 September 2026. Adobe released security bulletin APSB26-146 and hotfix VULN-39341 on 7 September 2026. CISA added it to its Known Exploited Vulnerabilities list on 8 September 2026.
+
+The vulnerability affects:
+
+- Magento Open Source and Adobe Commerce 2.4.4 to 2.4.9
+- Adobe Commerce B2B 1.3.3 to 1.5.3
+
+Stores with the July and August 2026 patches installed were still compromised before the hotfix was released. Sansec reproduced the attack on clean installations of Magento 2.4.7, 2.4.8 and 2.4.9. The first victim ran 2.4.6-p15 with the July and August 2026 patches applied. Your current patch level is therefore no defence without the hotfix.
+
+### How the Attack Works
+
+StyleSmuggler injects malicious code into Magento's template system. By using the `styles` properties, it evades existing safeguards. The attack works in two stages:
+
+1. The attacker injects PHP code into a file that Magento writes, such as a log file or a failure report. For example, a request to `/paypal/transparent/response/` with PHP code in the query string makes Magento write the whole request into a report in `var/report/`.
+1. The attacker then makes Magento execute the poisoned file. This happens by triggering Magento's "Payment Transaction Failed Reminder" email, or directly through a GraphQL request with `styles` parameters that point to the poisoned file.
+
+Nobody needs to open the email, because the malicious code runs while Magento renders it. The attack can also succeed when email delivery fails.
+
+Observed payloads include a Rust backdoor and a PHP web shell. The Rust backdoor runs as a background process disguised as `[kworker/u:8:0]`, `fc-cache` or `chronyd`.
+
+## What Hypernode Does
+
+Every Hypernode has the NGINX configuration file `server.block_stylesmuggler.conf`, which is provisioned automatically. It blocks requests to `/paypal/transparent/response/` and GraphQL requests that contain styles.
+
+```{important}
+This configuration complements the Adobe hotfix, but does not replace it. Keep it active after you have installed the hotfix.
+```
+
+## How to Fix the Vulnerability
+
+Apply hotfix VULN-39341. The fix ships as a hotfix, not as a full release. Download `VULN-39341-composer-patches.zip` from `repo.magento.com` and apply it as a Composer patch. For more information about installing patches, see [How to Apply Magento Patches](how-to-apply-magento-patches.md).
+
+You can check whether the hotfix is applied with the following command from your Magento root:
+
+```bash
+vendor/bin/magento-patches -n status | grep "39341\|Status"
+```
+
+Adobe tested the hotfix against the `2026-aug` releases. Older versions in the affected release lines are vulnerable too, but the hotfix is not verified for them.
+
+```{warning}
+BlockStrap (CVE-2026-103849) is a CVSS 10.0 bypass of the StyleSmuggler hotfix. Adobe fixed it in security bulletin APSB26-153 on 13 October 2026. Applying the StyleSmuggler hotfix alone does not protect your shop against BlockStrap, so also install the fix from APSB26-153.
+```
+
+### Unsupported Magento Versions
+
+Adobe does not publish a fix for the 2.2 and 2.3 release lines, or for 2.4.0 to 2.4.3, because these versions are out of support. Scandiweb has backported the fix to 41 older releases, from 2.2.0 up to 2.4.3-p3. Sansec has not reviewed these patches, so test them on a staging environment first.
+
+```{warning}
+Attacks started three days before the hotfix existed. Having the hotfix installed does not prove that your shop was never compromised. Scan your shop before you assume it is clean.
+```
+
+## How to Check Your Shop
+
+Hypernode does not scan customer installations. Use the checks below and the [indicators of compromise](https://sansec.io/research/stylesmuggler-0day#indicators-of-compromise) in Sansec's article to check your shop. Run the commands from your Magento root, for example `/data/web/magento2`.
+
+### Check for the Backdoor Process
+
+A strong sign of compromise is a malicious background process disguised as `[kworker/u:8:0]`, `fc-cache` or `chronyd`. Sansec recommends the following checks:
+
+```bash
+crontab -l | grep -i gvfsd
+ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
+ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
+grep -r 'crontab command not allowed' /var/log/
+grep -ril 'x_trace_' var/report/
+```
+
+Processes named `kworker` or `chronyd` also exist on a normal system, but they do not run as the `app` user. Check the user of any process you find.
+
+Also check your crontab for entries that you did not add, such as:
+
+```text
+*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
+13,43 * * * * <home>/.cache/fontconfig/fc-cache >/dev/null 2>&1
+57,27 * * * * /tmp/.chrony-<8hex>/chronyd >/dev/null 2>&1
+```
+
+```{note}
+Some versions of the backdoor restart themselves without a cron entry. An empty crontab does not prove that your Hypernode is clean.
+```
+
+### Check for Web Shells
+
+A second attacker uses StyleSmuggler to place a PHP web shell in the product image cache, for example `pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php`. Removing the background process is therefore not enough. Check for PHP files in the media directory:
+
+```bash
+find -L pub/media -type f -name '*.php'
+```
+
+### Check Your Logs and Configuration
+
+The Magento exception log keeps traces of the attack, even after your NGINX logs have rotated. Each attack attempt writes a `Laminas\Loader\Exception\InvalidArgumentException` to the log. PHP code in the `Store` header shows up as `Requested store is not found (<?`. Search for these lines with:
+
+```bash
+grep -aF 'Laminas\Loader\Exception\InvalidArgumentException' var/log/exception.log
+grep -aF 'Requested store is not found (<?' var/log/exception.log
+```
+
+Sansec also found secondary backdoors on compromised shops:
+
+- A remote file include in `vendor/magento/framework/App/View.php`, triggered by the cookie `gl_google_advisor_824808`.
+- A skimmer in the HTML head of all store views, stored in the `design/head/includes` configuration. You can find it in the Magento admin under **Content > Design > Configuration**, in the **HTML Head > Scripts and Style Sheets** field.
+
+To check `View.php` for the remote file include, run:
+
+```bash
+grep -n 'gl_google_advisor' vendor/magento/framework/App/View.php
+```
+
+Unexpected bursts of "Payment Transaction Failed Reminder" emails are also a reason to investigate. Keep in mind that legitimate declined payments send the same email, and that patched shops can still receive these emails when attackers send requests.
+
+### Scan Your Shop with Sansec
+
+Manual checks do not always find all malware, because attackers often hide their code. A scan with [Sansec eComscan](https://sansec.io/ecomscan) helps you find malware, backdoors, and known vulnerabilities in your shop. eComscan comes preinstalled on every Hypernode. To start a scan, run the following command:
+
+```bash
+ecomscan /data/web/magento2
+```
+
+If your shop lives in a different folder, change the path accordingly. See [How to Set Up Sansec eComscan on Hypernode](../../hypernode-platform/tools/how-to-set-up-sansec-ecomscan-on-hypernode.md) for more information.
+
+### If You Find Signs of Compromise
+
+If you find signs of compromise, rotate the Magento encryption key and every credential that the key protected. Adobe recommends rotating:
+
+- Admin passwords
+- REST, SOAP and GraphQL integration tokens
+- OAuth client secrets
+- Payment gateway API credentials
+- Database credentials
+- SSH and deploy keys
+- API keys of third-party extensions
+
+Rotate these credentials at the source, not only inside Magento. For example, create a new API key in the dashboard of your payment provider instead of only changing the key in the Magento admin. Rotating the encryption key on its own does not invalidate anything that an attacker already read.
+
+The database password is managed by the platform, but you can change it yourself with `ALTER USER`. See [How to Use MySQL on Hypernode](../../hypernode-platform/mysql/how-to-use-mysql-on-hypernode.md).
+
+See [How to Recover a Hacked Magento Shop](how-to-recover-a-hacked-magento-shop.md) for the general recovery steps.
+
+## Keep Your Logs
+
+The NGINX logs in `/var/log/nginx` rotate, and Hypernode backups only cover `/data/web` and the database. They do not include `/var/log/nginx`. If you need your logs for an investigation, archive them yourself, for example:
+
+```bash
+mkdir -p /data/web/log-archive
+cp -a /var/log/nginx/. /data/web/log-archive/
+```