StyleSmuggler-Helper-Scripts

KO | EN

gitlite — search

#awesome-list #svg #json #ai #html #shell #docker #containers #nextjs #github

StyleSmuggler-Helper-Scripts

(★ 9)

Collection of information and scripts around the Magento StyleSmuggler security issue

File Explorer

ZIP Download

- - shellcheck.yml
AGENTS.md
CLAUDE.md
fix-magento-source.sh
LICENSE
README.md
stylesmuggler-helper.sh
stylesmuggler-remote-check.sh

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

> [!IMPORTANT]
> **Adobe has released an official security patch for StyleSmuggler.**
> It **replaces `fix-magento-source.sh`** — apply the official patch
> instead of (or in addition to, if you already ran the community
> mitigation) this script's Composer-based workaround.
> Details: https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146

Three bash scripts to deal with **StyleSmuggler** — a 0-day RCE affecting
Magento / Adobe Commerce.
Ref: https://sansec.io/research/stylesmuggler

- `stylesmuggler-helper.sh` — **detect** an existing compromise and, if
  found, walk through **incident-response cleanup**. Run this directly on
  the **server/hosting environment** (production, staging, or Cloud node)
  you want to check — not on your local machine.
- `fix-magento-source.sh` — **proactively harden** a Magento/Adobe Commerce
  install against the vulnerability while no official Adobe patch exists.
  Run this on your **local development environment** (or wherever you edit
  and commit the Magento source/Composer dependencies) — it patches the
  source code, which you then deploy through your normal release process.
- `stylesmuggler-remote-check.sh` — **remotely** check a shop's public
  GraphQL endpoint for exposure/hardening indicators, given just its base
  URL. Run this from **anywhere with network access to the shop** — it
  never touches the server itself, only sends read-only HTTP requests.

Use all three: run `fix-magento-source.sh` to apply mitigations, run
`stylesmuggler-helper.sh` periodically (and immediately if you suspect an
incident) to check for IoCs, and run `stylesmuggler-remote-check.sh` to spot-
check a shop's public GraphQL exposure from the outside — e.g. before and
after applying the perimeter mitigations.

All scripts run on Linux and macOS (e.g. a developer's Mac driving a local
ddev/Warden Magento environment) — CI runs ShellCheck and a functional smoke
test on `ubuntu-latest` and `macos-latest` on every push. `ps`/`sed`/`netstat`
usage is written to work with both GNU (Linux) and BSD (macOS) userlands.

## `stylesmuggler-helper.sh` — detection & incident-response cleanup

> **Run this on the server environment**, not your local machine — it scans
> the live filesystem, running processes, crontabs, and logs of the host
> it's executed on, so it must run where the (possibly compromised)
> Magento/Adobe Commerce install actually serves traffic.

Scans the local system for known Indicators of Compromise (IoCs):

1. Running processes (kworker/fc-cache/gvfsd-user masquerading implants)
2. Crontabs (current user, `/etc/cron.d`, and — with root/sudo — other users' cron spool files)
3. Filesystem dropper/implant paths in `/tmp` and the user's home directory
4. Magento `var/report` / `var/log` for injected payload traces and related PHP errors
5. Active network sockets connecting to known C2 IPs
6. Web access logs for exploitation request patterns

If run in an interactive terminal and issues are found, it offers a guided,
step-by-step remediation wizard (forensic preservation reminder, cron
cleanup, process termination, file quarantine, Redis session invalidation,
a credential-rotation checklist, and optional nginx/WAF/php.ini hardening
suggestions written to a local file). **Every remediation action asks for
explicit confirmation before it runs**, and nothing is ever applied to
live Magento or webserver configuration automatically.

The script never installs, upgrades, or modifies the Magento application
itself — it only inspects the OS/filesystem/logs and cleans up OS-level
implant artifacts if you confirm each step.

### Usage

```bash
./stylesmuggler-helper.sh [SHOP_DIR] [LOG_DIR]
```

- `SHOP_DIR` — path to the Magento/Adobe Commerce root (default: `.`)
- `LOG_DIR` — path to webserver access logs, file or directory. If omitted,
  it's auto-detected using the `MAGENTO_CLOUD_PROJECT` environment variable
  that Adobe Commerce Cloud sets automatically (it holds the project ID):
  if `/var/log/platform/<project-id>` exists (Pro Staging/Production), that
  path is used; otherwise it falls back to `/var/log` (Dev environments,
  on-prem, local).

Example:

```bash
./stylesmuggler-helper.sh /var/www/magento /var/log/nginx
```

Re-run some checks (cron spool, non-root process scan) as root/sudo to
cover other system users, e.g. the webserver account.

### Checking an Adobe Commerce Cloud (ACCS/Pro) system

On Adobe Commerce Cloud, the writable filesystem lives under `/mnt/var`
(mounted from `/app/var` inside the container) and the application code is
deployed read-only under `/app`. SSH into the environment you want to check
(e.g. `magento-cloud ssh -e <environment>`), then clone and run the helper
directly from there:

```bash
cd /mnt/var
git clone https://github.com/muench-dev/StyleSmuggler.git
cd ./StyleSmuggler
./stylesmuggler-helper.sh /app
```

- `/mnt/var` is writable on Cloud containers, so it's a safe place to clone
  the repo without touching the deployed `/app` code.
- `/app` is passed as `SHOP_DIR` so the script scans the actual deployed
  Magento root.
- `LOG_DIR` (2nd argument) is left out on purpose: the script auto-detects
  it using the `MAGENTO_CLOUD_PROJECT` environment variable that Adobe
  Commerce Cloud sets automatically on every node (it holds the project
  ID) — using `/var/log/platform/<project-id>` on Pro Staging/Production
  when that path exists, and falling back to `/var/log` on Dev
  environments. The script prints which `LOG_DIR` it auto-detected. Pass
  an explicit second argument any time to override this, e.g.
  `./stylesmuggler-helper.sh /app /var/log/platform/<project-id>`.

Repeat this on each environment/node you want to check (and on each web
node if your plan runs more than one), since the scan only covers the
local filesystem, processes, and logs of the container it runs on.

## `fix-magento-source.sh` — proactive hardening / mitigation

> [!NOTE]
> Adobe's official patch (see the notice at the top of this README) now
> replaces this script. It remains here for environments that applied the
> community mitigation before the official patch shipped, or that cannot
> apply the official patch immediately.

> **Run this on your local development environment**, not on a live server
> — it patches the Magento source code and Composer dependencies (via
> `composer require`, `setup:upgrade`, `setup:di:compile`), so it belongs in
> your normal dev workflow, to be committed and deployed like any other
> code change rather than applied directly in production.

Applies the community mitigations for StyleSmuggler documented while no
official Adobe patch exists yet:

1. Installs and enables the `graycoreio/magento2-style-smuggler-patch`
   Composer module against the Magento install (`composer require`,
   `module:enable`, `setup:upgrade`, `setup:di:compile`) — this hardening
   module blocks the `{{block}}` directive in email templates, adds strict
   class validation before instantiation in the grid-row URL generator
   factory, and breaks open PHP tags inside fatal Web API error reports to
   prevent log/report poisoning.
2. Downloads and applies, via `cweagans/composer-patches`, the two real
   source patches Disrex has published for the root cause:
   - `magento/module-email` — the **front door**: the email template preview
     block renders `{{block}}` template directives from an unauthenticated
     request; guarded to admin-area-only, which makes the whole gadget chain
     unreachable. Disrex calls this the stronger of the two.
   - `magento/magento2-base` — the **sink**: the 3 DI-compiler scanner
     classes that `include`/`require_once` a caller-supplied path, guarded
     to CLI-only so `bin/magento setup:di:compile` keeps working.

Both are fetched from a **pinned commit** of
   `disrex-group/stylesmuggler-mitigation` (not the `main` branch, to avoid
   a moving-target supply-chain risk) and printed in full for you to review
   before anything is wired into `composer.json`. Before applying the
   DI-scanner patch, it also runs the compatibility check from the upstream
   README: some third-party modules (e.g.
   `mageplaza/module-admin-permissions`) call `ClassesScanner` from an
   HTTP-reachable admin controller, and guarding it there would break that
   admin screen — if such a reference is found, the script warns and asks a
   separate, explicit confirmation before applying that part of the patch,
   or lets you skip it and keep only the front-door patch. `composer.json`
   wiring is done via `jq` when available (with a `composer.json.bak`
   backup first); otherwise the exact JSON to add by hand is printed.

Applying the patches to an already-installed Magento tree isn't a plain
   `composer install` — `cweagans/composer-patches` 2.x doesn't reapply
   patches to packages that are already installed and match `composer.lock`.
   The script instead runs `composer patches-relock` (regenerates
   `patches.lock.json` from the `extra.patches` change) and
   `composer patches-repatch` (deletes and reinstalls the two patched
   packages so the patch actually takes effect), falling back to
   `composer update magento/module-email magento/magento2-base` for older
   `cweagans/composer-patches` versions that don't have those commands. It
   then runs `composer update --lock` — editing `composer.json`'s `extra`
   key directly makes `composer.lock`'s content-hash stale (Composer hashes
   `extra` too), so without this a later `composer install` — including in
   CI or an Adobe Commerce Cloud deploy — would warn or fail on an
   out-of-date lock file.
3. Writes webserver/WAF/php.ini/OS hardening suggestions (Cloudflare WAF
   rule, nginx query-string filter, optional `/graphql` endpoint block,
   `disable_functions` for PHP, `noexec` mount advice for `/tmp`,
   `/var/tmp`, `/dev/shm`) to a local `stylesmuggler-fix-snippets.txt` file
   for manual review.

**Every state-changing step asks for explicit y/N confirmation first.**
Steps 1–2 actually execute Composer/`bin/magento` commands against the
Magento root once confirmed. Step 3 **never** edits live nginx/php.ini/
fstab configuration or restarts any service — it only ever writes a local
snippet file for you to apply yourself.

This script does not detect or clean up an existing compromise — use
`stylesmuggler-helper.sh` for that. Administrators must also note the
Graycore module is a hardening measure, not a fix for the structural root
cause in the DI compiler, and does not remove any backdoor that may
already be present. Validate on a staging system before production.

### ddev / Warden support

The script auto-detects local dev environments and runs Composer/`bin/magento`
through them instead of directly on the host:

- **ddev** — detected via a `.ddev` directory in `MAGENTO_ROOT`; runs
  `ddev composer ...` and `ddev exec bin/magento ...`.
- **Warden** — detected via `WARDEN_ENV_NAME=` in `MAGENTO_ROOT/.env`; runs
  `warden env exec -T php-fpm composer ...` and
  `warden env exec -T php-fpm bin/magento ...`. Override the service name
  with `WARDEN_PHP_SERVICE` if your project doesn't use `php-fpm`.
- Otherwise falls back to plain **native** `composer`/`bin/magento` on the
  host.

If a project marker is found but the matching CLI (`ddev`/`warden`) isn't on
`PATH`, the script warns and falls back to native. Force a specific mode
with `FIX_MAGENTO_ENV=ddev|warden|native` if detection picks the wrong one.
Every confirmation prompt shows the exact resolved command (e.g.
`Run: ddev composer require ... ?`) before it runs.

### Usage

```bash
./fix-magento-source.sh [MAGENTO_ROOT]
```

- `MAGENTO_ROOT` — path to the Magento/Adobe Commerce root (default: `.`)

Example:

```bash
./fix-magento-source.sh /var/www/magento

# Force a mode instead of auto-detecting:
FIX_MAGENTO_ENV=warden WARDEN_PHP_SERVICE=php ./fix-magento-source.sh /var/www/magento
```

## `stylesmuggler-remote-check.sh` — remote GraphQL exposure check

> **Run this from anywhere with network access to the shop** — it only
> sends a handful of read-only HTTP requests to the shop's public base URL
> and its `/graphql` endpoint; it never logs into or touches the server
> itself.

Sansec's writeup discloses IoCs (e.g. `POST /graphql?styles[...]=...` as an
access-log signature) but does **not** publish the full request/mutation
needed to actually trigger the underlying DI-compiler gadget chain, and no
official Adobe patch/CVE existed while this script was written. That means
there is **no reliable way to remotely confirm or rule out the RCE itself**
from outside the server.

What the script does instead is check **exposure and mitigation-status**
indicators — things the community mitigations in `fix-magento-source.sh`
and `stylesmuggler-hardening.txt` either reduce or block:

1. Whether the shop and its `/graphql` endpoint are reachable at all
2. Whether GraphQL introspection is enabled (widens the attack surface)
3. Whether the published `styles[...]` query-string attack signature is
   filtered at the edge (WAF/nginx) or passes straight through — using only
   an inert marker value, never a template/code payload. Since backends
   disagree on what a plain, unfiltered GraphQL request returns (`200`,
   `400`, `501`, ...), this compares the probe's response against a plain
   baseline request instead of a fixed list of "blocked" status codes: an
   identical status means nothing filtered this signature, a different one
   means something rejected it specifically (most likely a WAF/nginx rule,
   though a strict request parser could produce the same effect)
4. Whether `/graphql` has been disabled entirely at the webserver (the
   strongest documented mitigation for non-headless storefronts)
5. Whether `/paypal/transparent/response/` (used in the published attack
   chain's second stage) is reachable — informational only, since it's
   normal Magento functionality on stores with PayPal enabled, not itself a
   vulnerability

A "no risk indicators found" result is **not** proof the shop is
unaffected — it only means these specific exposure/mitigation checks found
no issue. It doesn't replace `stylesmuggler-helper.sh` (local IoC/compromise
scan) or `fix-magento-source.sh` (source-level mitigation), and it never
sends any payload capable of triggering code execution.

### Usage

```bash
./stylesmuggler-remote-check.sh <SHOP_BASE_URL>
```

- `SHOP_BASE_URL` — the shop's public base URL (scheme optional, defaults to
  `https://` if omitted)

Environment overrides:

- `STYLESMUGGLER_TIMEOUT` — per-request curl timeout in seconds (default `10`)
- `STYLESMUGGLER_INSECURE=1` — pass `curl -k` to skip TLS certificate verification

Example:

```bash
./stylesmuggler-remote-check.sh https://www.example.com
```

Exit codes: `0` no risk indicators found, `1` one or more found, `2` usage
error (missing URL), `3` `curl` not found, `4` shop unreachable.

## Credits

Research and prior art this project builds on:

- [Sansec](https://sansec.io/research/stylesmuggler) — original StyleSmuggler
  0-day writeup, and the
  [chronyd-variant follow-up](https://sansec.io/research/stylesmuggler-0day#the-chronyd-variant).
- [disrex-group/stylesmuggler-mitigation](https://github.com/disrex-group/stylesmuggler-mitigation) —
  independent incident-response IoCs/mitigation writeup; source of the two
  real patches `fix-magento-source.sh` applies (`magento/module-email`,
  `magento/magento2-base`) and of several IoCs cross-referenced into
  `stylesmuggler-helper.sh`.

Third-party software these scripts install, wire up, or detect:

- [graycoreio/magento2-style-smuggler-patch](https://github.com/graycoreio/magento2-style-smuggler-patch) —
  Composer hardening module `fix-magento-source.sh` installs and enables.
- [cweagans/composer-patches](https://github.com/cweagans/composer-patches) —
  Composer plugin used to apply the Disrex source patches.
- [jq](https://jqlang.org/) — used to wire patch config into `composer.json`
  when available.
- [ShellCheck](https://www.shellcheck.net/) (via
  [ludeeus/action-shellcheck](https://github.com/ludeeus/action-shellcheck))
  and [GitHub Actions](https://github.com/features/actions) — CI linting and
  smoke tests on every push.

## Disclaimer

Both scripts are provided **as is, without warranty of any kind**. Any
cleanup, remediation, or hardening action you perform is entirely **at
your own risk** — always review the findings and each confirmation
prompt carefully before proceeding.

StyleSmuggler-Helper-Scripts

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

StyleSmuggler-Helper-Scripts

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README