WP-LIT-MCP/docs/superpowers/notes/2026-10-19-etappe-4e-security-audit.md

# Etappe 4 (Designsystem: Presets, Zuweisen, Farben, Variablen, Theme-Optionen, Schriften, Schleifen): security audit

- **Scope:** branch etappe-4, `d391cb5^..5220876` (HEAD, 153 commits; `d391cb5` is the Etappe 4 spec, so this is the whole Etappe 4 and not only `d73144a^..HEAD`, which starts at plan 4c and would miss 4a/4b). 177 `src/` files changed. Focus per spec §12 and plan task 8:
  - (a) preset `attrs`/`from_node`;
  - (b) font upload and `RemoteFileFetcher`;
  - (c) mass writes (`PageRewriter`, `lit/divi-presets-assign`, `lit/divi-design-detach`, P8/P8a, `HARD_CAP`, `post_ids`);
  - (d) loop options (type boundary, S29/S30 for `loop_*_meta_key_`, X1 context, `StoredNodeGuard`, move warning, Z2);
  - (e) snapshot restore (rights per area, `MAX_BYTES`, FIFO, `DesignLock`, ID parsing, restoring stored data);
  - (f) theme option whitelist and sanitizers, `et_update_option`, color and variable adapters, `ItemKeys`/`GroupKeys`, rights in `permission()` and `execute()`, release gate, error oracles.
- **Environment:** DDEV (WordPress 7.1.3, PHP 8.4, Divi 5.15.1), single site, one user (`administrator`), `DISALLOW_UNFILTERED_HTML` undefined, `et_pb_role_settings` empty (Divi defaults). Plugins `postlos` and `asynclistry` inactive before and after (left as found).
- **Method:**
  - Read every new or changed `src/` file of the range in five slices (loops/dynamic content, fonts/fetch, presets/rewriter, snapshots/options/colors/variables, registrar/gate) and traced each write route to its checks.
  - Read the Divi 5.15.1 code wherever the plugin relies on Divi behaviour: `LoopUtils` (query args, `parse_and_duplicate_loop_blocks`, `_create_duplicated_block`, no-results path), `DynamicContentLoopOptions`, `DynamicContentOptionLoopPostMetaKey`, `DynamicContentACFUtils` (user meta), `DynamicData`/`DynamicContentUtils` (loop_id passing), `BlockParser` (global layout expansion), `GlobalData` (colors, variables, sanitizers), `FrontEnd/Module/Style.php` (variable CSS output), `epanel/custom_functions.php` (`et_update_option`), `PageResource`, `LoopPresetAttrsMap`, `GlobalPreset::prepare_data`, font upload (`et_pb_add_font`, `check_filetype_and_ext_font`); core `class-wp-query.php` (private status handling), `option.php` (`add_option`), Requests redirect hooks.
  - Ran read-only `wp eval-file` probes. Probe files were deleted afterwards. Covered: `et_divi` layout and key count, Divi role defaults for an in-memory editor, snapshot counts, the live loop option registry (34 options), `RemoteFileFetcher::allows()` against 20 host tricks, and `LoopUtils::parse_and_duplicate_loop_blocks` on in-memory block markup with an in-memory `get_post_metadata` marker filter (M1, L2).
  - Simulated roles with in-memory `WP_User` objects (never saved): editor without `edit_theme_options`, administrator without `unfiltered_html`, without `upload_files`, without the Divi role options `custom_fonts_management`/`variables_manager`/`theme_customizer`.
  - Nothing was written to the site. md5 before and after, identical: `et_divi` 771d6532…, `et_divi_global_variables` 191a4ce9…, `et_uploaded_fonts` a2072c8a… (empty), `et_divi_builder_global_presets_d5` 53586deb…, content hash of all pages/posts/library/TB posts f28463a0…; the `lit_mcp_snapshots_*` options unchanged. `git status` clean except this note.
  - `vendor/bin/phpunit`: 3449 tests, 21498 assertions, OK.

**Result:** no Critical or High findings. One Medium, nine Low, ten Info.
- M1 is the one finding that defeats the type boundary of the Global Constraints silently: an empty inner loop hands its `loop_post_meta_*` content to an outer term/user loop.
- The ruling Z2 (two-call route stays a warning) is acceptable only together with M1 and L2: today the warning is wrong for alias/case query types (L2), and M1 reaches the same result with no warning at all.
- Ruling X7(d) (presets enabling loops) turned out harmless on render: Divi's loop pass reads raw block attrs, never presets. A preset-based loop switch is therefore not a finding.
- W13 items hold as recorded except two: the `et_update_option` lost update also happens between two LIT tools (L5), and `DesignLock` is not atomic at all, not only racy on takeover (L6).

---

## Findings (most severe first)

### M1 – Medium (type boundary bypass): an empty inner loop lets the outer loop of another kind resolve `loop_post_meta_*`, with no refusal and no warning

**Where**
- `src/Integrations/Divi/Compose/LoopContext.php:171-181` (`fromChain()`: the innermost enabled loop wins) and `src/Integrations/Divi/Compose/DynamicContentRules.php:142-165` (checks only that innermost scope).
- Divi `includes/builder-5/server/Packages/Module/Options/Loop/LoopUtils.php:4451-4456`: a loop with no results returns its block unchanged, still holding its `$variable(…)$` references.
- `LoopUtils.php:4572-4598`: the outer loop then runs `replace_loop_variables_in_attrs` / `process_loop_block_inner_blocks` with its own `query_type`/`query_item` over the nested block.
- `DynamicContentLoopOptions.php:150-158`: post meta is read with `object_id = loop_id`, which is the term (or user) ID.

**Scenario**
1. A page has a term loop (built in the Visual Builder, or switched on through `attrs`, X7a).
2. Call 1: `lit-divi-insert` puts a Text module inside it with `attrs` `module.advanced.loop` = `{enable: on, queryType: post_types}` and a query that never matches (`includeSpecificPosts: [999999]`, a large offset, a type without posts). No loop content is in the call, so it passes.
3. Call 2: `lit-divi-update` sets the module's text to `loop_post_meta_key_manual_custom_field` with any `loop_meta_key` that passes S29/S30 (no leading `_`). The node's own scope is post, so `fits()` holds and no warning is produced.
4. On the frontend the inner loop has no results; the outer term loop resolves the variable: the meta of the post whose ID equals each term ID, whatever its status or type (drafts, private posts, ACF fields of other types).
5. The account needs only `edit_post` on the page and dynamic-content rights. It is the result the Global Constraints call "keine Komfortmeldung", and unlike Z2 nothing tells the user.

**Evidence:** probe (in memory): `LoopUtils::parse_and_duplicate_loop_blocks` inside `the_content` on markup "category term loop > post loop with no hits > text with `loop_post_meta_key_manual_custom_field`", with a `get_post_metadata` filter that marks reads. The inner block kept `__loop_no_results: true`, and the text resolved to the marker for post 1 (= term ID 1). A stack trace showed the read coming from the outer loop's `_create_duplicated_block` (`:4591`).

**Fix (smallest)**
- For meta-key options only (`str_contains($name, '_meta_key_')`), require every enabled loop in the ancestor chain to have the option's kind, not only the innermost one.
- `LoopContext::fromChain()` collects the kinds of all enabled ancestors-or-self into `LoopScope` (e.g. `kinds(): list<string>`); `LoopScope::fits()` checks meta options against all of them, other `loop_*` options keep the innermost rule (their Divi resolvers check `instanceof WP_Post`/`WP_Term`/`WP_User` and return '' for a foreign object, `LoopUtils.php:3162+`, `3553+`, `3599+`).
- The same chain rule must hold in the update/move warnings (`DiviWriteAbility::loopWarning()`).
- Tests: post meta option in a post loop nested in a term loop is refused on insert and update; in a post loop nested in a post loop it is accepted.

### L1 – Low (disclosure, Divi parity): loop settings through `attrs` let any account with `edit_post` publish private posts of others and user e-mails/logins

**Where**
- `src/Integrations/Divi/Compose/ValueCleaner.php:63-64`: `module.advanced.loop` is not in the builder-only paths, so any writer may set it (X7a; test `DiviLoopWriteTest.php:206-228`).
- Divi `LoopUtils.php:1005-1037`: an empty `subTypes`, or one whose types are all invalid, falls back to `post_type = any`; `any` or `attachment` sets `post_status = [publish, inherit, private]`.
- Core `wp-includes/class-wp-query.php:2685-2687`: without `perm => readable`, explicit `private` is merged into the visible statuses for every visitor. Divi never sets `perm`.
- Divi `LoopUtils.php:922-990`: the user query has no capability check, `role__in` is free.

**Scenario**
1. An author with dynamic-content rights builds a post loop with empty `subTypes` on their own page and uses `loop_post_title`/`loop_post_excerpt`. The published page lists other authors' private posts, although the author lacks `read_private_posts`.
2. Or a user loop for role `administrator` with `loop_user_email`/`loop_user_username`: the page publishes admin e-mails and logins; `list_users` is bypassed. A contributor sees the same in preview.
3. The Visual Builder allows the same to any account with builder access, so this is Divi parity. LIT adds no new effect but opens it to every MCP account with `edit_post`, while the guide says "Abfrage und Anzahl gehören in den Divi-Builder".

**Evidence:** by reading Divi and core (paths above). No private posts or second account exist on DDEV, so no end-to-end probe was run.

**Fix (product decision, behaviour change)**
- Option A (one line, also closes step 2 of M1 and the Z2 update route for lower roles): add `advanced\.loop` to `ValueCleaner::BUILDER_ONLY` (needs `unfiltered_html`), like the other builder-only paths.
- Option B (narrower): refuse a loop with `queryType` `user_roles` without `list_users`, and a post loop whose `subTypes` is empty, `any` or contains `attachment` without `read_private_posts`.
- Recommendation: B, because it keeps loop editing for editors and closes only the two disclosures.

### L2 – Low (wrong warning, normalisation): `LoopScope` reads `queryType` raw, but Divi `sanitize_key()`s it and knows the aliases `terms`/`users`

**Where**
- `src/Integrations/Divi/Compose/LoopScope.php:32-38`, `:76-79`; `LoopContext.php:162-165`.
- Divi `LoopUtils.php:729-731` (`sanitize_key`), `:881-898` (`users` runs the user query, `terms` the terms query), `:4111-4128` (loop_id = term_id / user ID).
- `src/Integrations/Divi/Pages/DiviWriteAbility.php:141-160` (warning text), `DiviUpdateAbility.php:207` (none → unsupported: both kinds null, no warning).

**Scenario**
1. For LIT, `"Post_Taxonomies"`, `" post_taxonomies"`, `"terms"` and `"users"` are unsupported, so new `loop_*` content under them is refused (fail closed, good).
2. Z2 route: post loop with `loop_post_meta_*` children, then `lit-divi-update` sets `queryType` to `terms` or `Post_Taxonomies`. The warning says the content is "jetzt außerhalb jeder Divi-Schleife; Divi zeigt sie dort leer".
3. Divi in fact runs a term loop and prints post meta by term ID. The warning ruling Z2 relies on misleads the user into thinking the change is harmless.

**Evidence:** probes "queryType `terms`, flat" and "`Post_Taxonomies` > empty post loop" both resolved the post 1 marker (term ID 1).

**Fix**
- In `LoopContext::ownScope()`, normalise like `sanitize_key`: `preg_replace('/[^a-z0-9_\-]/', '', strtolower($q))`.
- Add `'terms' => TERM` and `'users' => USER` to `LoopScope::KINDS`.
- In the update/move warning, word an unsupported target as "kann Daten eines anderen Objekts zeigen", not "leer".
- Tests: `Post_Taxonomies` and `terms` are term scope; the update warning names the term kind.

### L3 – Low (type boundary, no check or warning): global instances and copies carry `loop_*` content across loop kinds

**Where**
- `src/Integrations/Divi/Library/LibraryInsertAbility.php:152-163`: in mode `global`, `StoredNodeGuard` sees only the instance's local attrs; the entry content is referenced and Divi expands it before the loop pass (`BlockParser.php:917-924`, then `:947`).
- `src/Integrations/Divi/Compose/StoredNodeGuard.php:64-66`: no checks at all for `unfiltered_html` accounts.
- `DiviNodeCopyAbility.php:172`, `DiviMoveAbility.php:93`: `LoopContext::optionsIn()` skips opaque nodes (`LoopContext.php:192-194`), so moving a global instance never warns.

**Scenario**
1. A library entry holds `loop_post_meta_key_*` (built in the VB, or saved by an `unfiltered_html` account with `lit/library-save`).
2. Any account with library and page rights inserts it as a global instance into a term loop: post meta by term ID, no warning.
3. `unfiltered_html` accounts can also `lit/divi-node-copy` or `lit/library-insert` (copy mode) loop content into any loop kind, again without the warning that move and update give.

**Fix**
- In `library-insert` (global and copy) and `node-copy`, collect `optionsIn()` of the content that will render (entry blocks or the copy) for `_meta_key_` options and compare with the target's `loopAt()` under M1's chain rule; refuse, or at least add `loopWarning()`, for every account including `unfiltered_html`.
- In move, enter global instances through their entry, or warn whenever an opaque global instance changes loop kind.

### L4 – Low (authorization, P8/P8a): `lit/divi-design-restore` never computes affected pages, so it skips `blocked_ids` and `in_use`

**Where**
- `PresetRestorePlanner.php:64-72`, `ColorRestorePlanner.php:67`, `VariableRestorePlanner.php:54-60`, `ThemeOptionsRestorePlanner.php:62-69` build `DesignPlan(..., usages: null)`.
- So `DesignChange::blocked()` (`DesignChange.php:200-219`) is always null on restore, and the dry run shows `affected: []`.
- Compare the set tools, which run `ReferenceUsageQuery`: `DiviColorsSetAbility.php:202-218`, `DiviVariablesSetAbility.php:179-195`, `DiviPresetsDeleteAbility.php:174-176` (`in_use`), `:196`. Spec §4 step 4 requires `affected`/`blocked_ids` for every design write tool.

**Scenario**
1. An account with `edit_theme_options` and Visual Builder rights lacks `edit_post` on live page X, which uses color C.
2. `lit/divi-colors-set` on C is refused (P8a).
3. The same account restores an older colors snapshot in which C had another value or did not exist: page X changes without a check. The same works for variables, and for presets (restore removes presets in use without `in_use`).
4. Limits: only earlier states are reachable, the account is administrator-level, and Divi's builder lets it change globals anyway.

**Fix:** in each planner except theme options, collect IDs whose diff action is `changed`, `removed` or `deactivated` and pass `$usages->reportFor(new ReferenceUsageQuery($ids))` (presets: `PresetUsageQuery::withGroups`) as the fourth `DesignPlan` argument; inject `GlobalUsages` through the constructors (`DiviIntegration`). Keep the preset orphan warning (spec §5) but let P8a block. Test: a colors restore that changes a color used on an uneditable live page answers `forbidden` with `blocked_ids`.

### L5 – Low (integrity, W13 extended): colors and theme options take different locks but both rewrite the whole `et_divi` array from Divi's request global

**Where**
- Divi `GlobalData::set_global_colors()` (`GlobalData.php:682-727`) and `ThemeOptionsAdapter::write()` (`ThemeOptionsAdapter.php:398-403`) both end in `et_update_option()`, which writes `$GLOBALS['et_theme_options']`, loaded once per request (`epanel/custom_functions.php:276-312`). Probe: `et_divi` has 153 keys, `et_global_data` lives inside it.
- `DesignLock.php:184-191`: `lit_mcp_lock_colors` and `lit_mcp_lock_theme_options` are different locks; each `design_rev` covers only its own keys.

**Scenario:** a confirmed `lit/divi-colors-set` and a confirmed `lit/divi-theme-options-update` overlap, or the theme options request loaded `et_divi` before the colors write. The later `et_update_option` writes its stale copy back and silently reverts the global and customizer colors. Both read-backs pass because each checks only its own keys; the colors snapshot and log describe a state that is gone. Same principal, integrity only.

**Fix:** map `colors` and `theme_options` to one lock name in `DesignLock::option()`, and under the lock refresh `$GLOBALS['et_theme_options'] = get_option('et_divi');` before writing (`ThemeOptionsAdapter::write()`, `GlobalColorsAdapter::save()`).

### L6 – Low (concurrency): `DesignLock::acquire()` is not atomic, and a stale takeover lets the old holder release the new holder's lock

**Where**
- `DesignLock.php:172-176` (docblock "add_option() is atomic") and `:193-207`.
- Core `add_option()` (`wp-includes/option.php:1119-1125`, `:1142`) checks with `get_option` first and then runs `INSERT … ON DUPLICATE KEY UPDATE`; two concurrent requests can both get `true`.
- The plugin already knows the safe pattern: `src/Integrations/Divi/Release/DiviCheckRoute.php:19-22` (`INSERT IGNORE` plus compare-and-swap).
- Stale takeover after 120 s: a long confirmed run (`PageRewriter` with 50 pages) loses its lock to B; A's `finally release()` (`DesignChange.php:97-99`) deletes B's lock, so C enters too.

**Scenario:** two confirmed changes of one area both pass `design_rev` and write; last write wins, and snapshots and change log disagree with the stored state. Same principal, integrity only. This also widens the recorded `attachLog`/RMW and takeover items.

**Fix:** reuse `DiviCheckRoute`'s pattern: `INSERT IGNORE` with a token `time() . ':' . wp_generate_password(8, false)`, success only on `rows_affected === 1`; take over a stale lock with `UPDATE … WHERE option_value = <read value>`; release only while the token still matches.

### L7 – Low (CSS injection without `unfiltered_html`): image variable values can leave the `:root` rule

**Where**
- `src/Integrations/Divi/Design/VariableValue.php:36` (`WEB_URL = /^https?:\/\/[^\s<>"]+$/iD`) allows `; { } ( ) '`.
- Divi `sanitize_global_variables_data` applies `sanitize_text_field` to images (`GlobalData.php:836-878`), which keeps them.
- Divi `FrontEnd/Module/Style.php:1503-1505` wraps images as `"url({$result})"` without escaping, inside `:root{--gvid-…: …;}`.
- `numbers` and `fonts` already exclude `;{}<>` (`VariableValue.php:62`, `:101`); `images` is the gap.

**Scenario:** an administrator without `unfiltered_html` (multisite site admin, or `DISALLOW_UNFILTERED_HTML`) holding `variables_manager` sets an image variable to `https://x.test/a.png);}body{display:none}a{b:url(x`. Every page that uses the variable gets the injected CSS (hide content, overlays, tracking `url()`). No `<`, so no `</style>` and no script. Spec §4 step 2 reserves raw CSS for `unfiltered_html`. Divi's own variable manager accepts the same value (parity), hence Low.

**Evidence:** `preg_match(WEB_URL, 'https://x.test/a.png);}body{display:none}a{b:url(x')` returns 1; the Divi output line was read.

**Fix:** `WEB_URL = '/^https?:\/\/[^\s<>"\'(){};\\\\]+$/iD'` (and the same for a `/`-relative branch if images accept it). Test: the value above is refused.

### L8 – Low (SSRF, transport): the IPv4-only rule and the redirect checks around cURL do not apply to the fsockopen transport

**Where:** `src/Integrations/Media/RemoteFileFetcher.php:59-64`, `:72`. The `http_api_curl` hook does not fire on the Requests fsockopen transport; `PublicAddress::dnsResolver()` and `wp_http_validate_url` check IPv4 only.

**Scenario:** on a host without ext-curl, `stream_socket_client` may connect over AAAA. A name with a public A record and an AAAA record of `::1` or `fd00::…` reaches an internal IPv6 target (fonts: blind oracle only; media import: an image/PDF answer becomes a readable attachment). Needs a server without cURL, which is rare; DDEV has cURL.

**Fix:** in `fetch()`, return `failed(…)` when `! function_exists('curl_init')`, or restrict this request to cURL with a scoped `http_api_transports` filter (`fn () => ['curl']`).

### L9 – Low (DoS): the page rewriter parses every candidate post on each dry run and confirm, with no cap on drafts

**Where**
- `src/Integrations/Divi/Library/GlobalUsages.php:101-116` (`rowsFor()`: up to `PARSE_CAP` 5000 parsed, the rest appended).
- `src/Integrations/Divi/Design/PageRewriter.php:184-216` (`changes()`: `loadWritable()`, parse and `TreeRewrite` for every row, for `preview()` and `apply()`, beyond `PAGE_LIMIT` 50 because the remainder is counted); `:89`, `:140` (`reportFor()` first, so candidates are scanned twice).
- `HARD_CAP` (2000) counts live posts only.

**Scenario:** a site with thousands of drafts holding `divi/text`; every `lit/divi-presets-assign module=text` dry run parses them all, up to `max_execution_time`. Memory stays bounded by chunks of 50. A timeout during `apply()` keeps the posts saved so far (each with a revision) but returns no `partial_write`. Administrator-level actor, effect ends with the requests.

**Fix:** stop the in-memory rewrite after `PAGE_LIMIT` changed posts plus a bounded counting window (e.g. 500 candidates) and report `remaining` as "mindestens N"; or refuse above a total candidate cap (all statuses) unless `post_ids` is given. Test: 600 candidate rows load at most `PAGE_LIMIT` plus the window.

---

## Info / hardening

### I1 – Preset-side variable detach inlines `before`/`after` without the marker check of the page-side detach
- `PresetBook.php:366-378` (`resolved()` concatenates affixes raw) vs `VariableDetachRewrite::hasUnsafeAffix()`/`unsafe()` (`VariableDetachRewrite.php:41-45`, `120-147`).
- `markupOutside([])` (`DiviDesignDetachAbility.php:429`) and Divi's `prepare_data()` catch `<`/`>`, but a `$variable(…)$` stored in an affix by an `unfiltered_html` account becomes a live, never-canonicalised reference once inlined. Fix (about 5 lines): skip or refuse a reference whose affixes are `unsafe($text, markupAllowed: true)` and list it in the "eingebettet" note.

### I2 – A detached variable value is inlined without cleaning for the target field type
- `VariableDetachRewrite::replacement()` (`:51-61`); only `<`/`>` and markers are checked (`DiviDesignDetachAbility.php:277-291`). A strings value `javascript:…` lands raw in a link field. Divi escapes `href`/`src` with `esc_url` on render (`HTMLUtility.php:791-793`, `1054-1068`), so not exploitable. Optional: `ValueSanitizer::url()` when `kindAt()` is Url.

### I3 – For `unfiltered_html` accounts, `from_node` copies `loop_*`/`custom_meta_*` references unchecked into a preset
- `PresetComposer.php:75-82`; `StoredNodeGuard::problems()` returns `[]` for them (`StoredNodeGuard.php:64-66`). The `attrs` path refuses every `loop_*` (no scope). A preset can then carry a loop reference into modules of any loop kind. Administrator actor. Optional: run the taken attrs through the composition's `references()` for the loop rule regardless of `unfiltered_html`.

### I4 – Read tools check rights only in `permission()`
- `DiviPresetGetAbility.php:104-109`, `DiviDesignSystemAbility`, `DiviDesignSnapshotsAbility`. `AbilityRegistrar.php:66-82` always runs `permission_callback` first, so unreachable; inconsistent with the write tools and `DiviThemeOptionsGetAbility.php:114-118`.

### I5 – Shortcodes and custom-field conditions inside term/user/menu loops run against the post with the term/user ID
- Divi `LoopUtils.php:4507-4510` (`__loop_post_id` = term/user ID), `DynamicContentUtils.php:669-690`, `ModuleElements.php:1718-1771` (`override_post_data()` → `get_post(term_id)`), `Conditions.php:928-940`. `[acf]`, `[pods field=…]` and similar in a text module in a term loop read the unrelated post. Outside the `loop_*` check and Divi behaviour; document in the guide. Optional: refuse shortcodes under a non-post loop without `unfiltered_html`.

### I6 – Font dry run reveals whether a host name resolves privately
- `DiviFontsUploadAbility.php:216` ("nur öffentlich erreichbare http(s)-Adressen") vs "nicht abrufbar": internal DNS enumeration for an administrator-level principal. Media import behaved so before Etappe 4.

### I7 – Font confirm is not bound to the dry run
- Confirm downloads again (`DiviFontsUploadAbility.php:288` ff., `download()` `:320`) without comparing the SHA-256 shown in the dry run. The content is re-checked, so nothing unsafe gets in. Optional `expected_sha256` input.

### I8 – Font download time and leftovers
- Up to 4 files × 5 MB × 30 s (`TIMEOUT`, `:24`), both in dry run and confirm; a slow server holds a worker about 120 s per call. If PHP is killed mid-download, `wp_tempnam` files stay (cleanup only in `finally`). Administrator-only.

### I9 – Lost update on `et_uploaded_fonts`
- `font_add` reads and writes the whole option without a lock (fonts have no pipeline, A2). Concurrent uploads, or an upload next to a Divi UI upload, can drop an entry and leave orphan files in `et-fonts`. Same class as W13.

### I10 – `numbers` variables accept `url(https://…)`
- No breakout (`esc_html`'d, `;{}<>` excluded), but a tracking request from every page is possible. Acceptable.

---

## Deferred items re-checked

| Item | Verdict |
|---|---|
| W13 lost update of `et_update_option` | Confirmed, and wider than recorded: also between `colors-set` and `theme-options-update` (L5). **Zu beheben** (L5); against Divi's own saves acceptable. |
| W13 `body_header_style` | One of italic/uppercase/underline only; Divi can combine. Functional, not security. **Akzeptabel.** |
| W13 missing range check in Divi | `ThemeOptionSpec::check()` enforces min/max/step/choices before Divi's sanitizer; a sanitizer change is an error (`DiviThemeOptionsUpdateAbility.php:183-193`). **Akzeptabel.** |
| W13 `font_add` partial success | `FontInstaller::install()` (`:402-450`) compares the formats Divi stored (`FontInstaller.php:122-124`) and calls `font_remove($name)` on a shortfall; the name rules guarantee Divi's stripped name equals `$name`; a failed removal is `WriteFailed::partial` with a hint. **Akzeptabel.** |
| W13 `remove_static_resources` only with a logged-in user | Divi checks `et_core_security_check_passed('edit_posts')` (`PageResource.php:1404`); MCP requests are always authenticated. Only CLI/cron would miss the CSS clear. **Akzeptabel.** |
| W13 tablet/phone 14/30 quirk | Display defaults and inheritance only. **Akzeptabel.** |
| W13 DNS-rebinding window between `allows()` and cURL | Confirmed (`RemoteFileFetcher.php:37-42` vs `:51-84`, redirects `:67-71`; nothing pins the checked IP; ports 80/443/8080). For fonts a blind boolean oracle only (magic bytes + finfo, nothing stored): Low. For media import (authors with `upload_files`) an internal image/PDF answer becomes a readable attachment; that is the 3a/3b "DNS pinning" item, carried over unchanged. **Zu beheben** (about 15 lines): resolve once in `fetch()`, check, and pin with `CURLOPT_RESOLVE` in the existing `http_api_curl` hook, redirect hosts likewise. |
| W13 schema errors without lit field paths | UX only; `ThemeOptionSpec` errors carry `set.<key>`. **Akzeptabel.** |
| Ruling R9 (rewriters without `unfiltered_html`) | No client string enters page content: assign writes preset IDs through `PresetAssignment` → `keepsId`, preset detach removes IDs, variable detach refuses `<`/`>`/markers and unsafe affixes per block without `unfiltered_html`. `DiviSaver`'s kses window keeps existing markup byte-identical. **Akzeptabel.** |
| P8a with `post_ids` | Only named posts are rewritten (`PageRewriter.php:187-189`), each through `loadWritable()` (`edit_post`, Library/TB access and group gate); a named library entry gets its own usage report (`:282-292`). **Akzeptabel.** |
| `SnapshotStore::attachLog` without error check, RMW without lock | Inside the area lock, but the lock is not atomic (L6). Worst case a missing `log_id` link. **Akzeptabel**, resolves with L6. |
| `DesignLock` takeover race | Worse than recorded: `acquire()` itself is not atomic (L6). **Zu beheben** (L6). |
| X7(a) loops switchable through `attrs` | Holds as designed for the type boundary, but enables L1 (private posts, user data). **Produktentscheidung** (L1, options A/B). |
| X7(b) global modules without context | `loop_*` in library entries is refused (no scope). The inbound direction via global instances is L3. **Akzeptabel** for entry edits; L3 zu beheben. |
| X7(c) copying fail closed | Holds for accounts without `unfiltered_html` (`StoredNodeGuard` composes with scope none, every `loop_*` refused). `unfiltered_html` accounts get no check and no warning (L3). **Akzeptabel** with L3. |
| X7(d) presets with loop | No render effect: `LoopUtils::parse_and_duplicate_loop_blocks` parses the raw document with `WP_Block_Parser` and reads raw `attrs` (`LoopUtils.php:4219-4229`, `718-733`); presets never start, stop or retype a loop on the frontend. X1 matches Divi's render. **Akzeptabel** (fail-closed limit only). |
| X7(e) ACF repeater fields | `loop_acf_*` has no kind, `repeater_*` is unsupported, all refused. **Akzeptabel.** |
| Ruling Z2 (two-call route stays a warning) | Impact: non-protected post meta of posts whose IDs equal term/user IDs. Acceptable as Low **only** while the warning is accurate and no silent route exists; today L2 makes the warning wrong and M1 is silent. Recommendation: fix M1 and L2; for `_meta_key_` options refuse (instead of warn) on update/move, ordinary loop editing stays possible. |
| Mirror `customizer-typography` | Fingerprints all of `et_divi_customizer_theme_settings`; any customizer edit locks ThemeOptionRead/Write (fail closed, noisy). **Akzeptabel** as documented shortcut. |
| Ledger lead: `LoopContext::of` skips an opaque node's own loop | Used only by dynamic-sources (a listing); write tools never write onto opaque blocks; `loopAt()` does not skip. Info. **Akzeptabel.** |
| Ledger lead: `kindOfOption` defaults to POST | `loopFieldsFor` needs both `fits()` and a map entry from `loopFields(kind)` (Divi group; meta options by name, matching Divi's own prefix rule, `DynamicContentOptionLoopPostMetaKey.php:334-345`). An unknown name never passes. **Akzeptabel.** |
| Ledger lead: user meta via manual `loop_meta_key` in user loops | Divi's user branch of `get_meta_value_by_type()` requires the **viewer** to hold `manage_users` (non-ACF) or `list_users` (ACF) (`DynamicContentACFUtils.php`). No visitor leak. **Akzeptabel**, documented as parity; the real user exposure is L1. |
| Ledger lead: Divi passes `loop_id`/`loop_query_type`/`loop_object` to every content variable | Non-loop options resolve `post_id` from `$value['post_id'] ?? get_dynamic_content_post_id()` (the page); `VariableRef::canonical()` allows only `name`/`settings`, so `post_id` cannot be injected. Of the non-loop resolvers only the repeater branch of `DynamicContentOptionPostMetaKey` and `get_archive_term_thumbnail_id` (returns 0) read loop data. No crossing; the real crossings are M1 and I5. **Akzeptabel.** |
| Ledger lead: none → unsupported loop switch without warning | Confirmed, but no `loop_*` content can exist under none. The real gap is L2. **Akzeptabel** with L2. |

---

## Areas checked and found sound

- **Rights matrix** (`permission()` and `execute()` both check, unless noted in I4):

  | Tool | Checks | Divi features |
  |---|---|---|
  | `lit/divi-colors-set` | `DesignRights::colors`: `edit_theme_options`, Visual Builder | DesignRead, ColorWrite |
  | `lit/divi-variables-set` | `edit_theme_options`, Visual Builder, `variables_manager` | DesignRead, VariableWrite |
  | `lit/divi-presets-set`, `-delete`, `-assign` | `DesignRights::presets` (`edit_theme_options`, Visual Builder); `markupOutside()` without `unfiltered_html` | assign/detach also PageRead/Write, Library, Theme Builder |
  | `lit/divi-design-detach` | rights per preset or variable | as above |
  | `lit/divi-theme-options-update` | `edit_theme_options`, `theme_customizer` | ThemeOptionRead, ThemeOptionWrite |
  | `lit/divi-theme-options-get` | `edit_posts` | ThemeOptionRead |
  | `lit/divi-design-restore` | the area planner's rights; an invalid ID needs all areas' rights | per area, or all |
  | `lit/divi-design-snapshots` | `edit_theme_options` (`permission()` only) | none |
  | `lit-divi-design-system`, `lit/divi-preset-get` | `edit_posts` (`permission()` only) | DesignRead (+ Catalog) |
  | `lit/divi-fonts-upload` | `upload_files`, `edit_theme_options`, `custom_fonts_management`, fail closed without Divi | FontUpload |

  `AbilityRegistrar` runs access, OAuth, the guards (`DiviFeatureGate`) and then `permission()` in `permission_callback`, and the guards again in `execute_callback`. `DesignChange::apply()` asserts the feature before the snapshot, each adapter again before writing, `FontInstaller::install()` before any write. In-memory editor: refused everywhere for lack of `edit_theme_options`, although Divi's defaults grant `theme_customizer`, `variables_manager` and `custom_fonts_management`.
- **Preset attrs (XSS):** `set`/`attrs` go through `Composer::update()` (ValueCleaner S7/S26, URL/HTML rules); `from_node` through `StoredNodeGuard` on the whole subtree; every path must be a Divi preset attribute, so text, links and images are refused (`PresetComposer.php:94-102`). A changed preset holding markup is refused without `unfiltered_html` (`DiviPresetsSetAbility.php:541`, same in delete/detach). Divi's `prepare_data()` sanitizes again (`DesignSystemWriter.php:103`). CSS values without `<` cannot leave the `<style>` block.
- **Mass writes:** usages and P8 in presets-set/delete with `withGroups`; delete refuses `in_use` on explicit usages including drafts; TB layouts need ThemeBuilderAccess (hidden ones read as not found and are never named); blocked library entries refuse (P8a), site-wide entries and layouts without revisions are skipped; `read_post` before naming, one `NO_CHANGE` text for every reason (`PageRewriter.php:60-61`, `230-241`); global instances opaque, only listed in `skipped`. `Serializer` escapes `--` and `<`, so an inlined value cannot close the block comment.
- **`ItemKeys`/`GroupKeys`:** `strval` on numeric keys; groups resolved only against Divi's groupId paths; `PresetBook` casts IDs to string at every lookup and writes with `array_values`; `PresetDiff` merges key lists only. No renumbering of option arrays found.
- **Loop type boundary (bypass attempts, all held):** control characters (stripped by `ControlChars` before `canonical`), case or leading space in names (not `loop_`-prefixed → unknown), JSON `\u` escapes (decoded before the checks), `{{loop:…}}` (through `Placeholders` → `canonical`), same-call loop attrs (Insert refuses on the composed blocks, `DiviInsertAbility.php:107`; Update re-composes in the new scope, `DiviUpdateAbility.php:240-246`), tablet/hover/`true` enable (neither LIT nor Divi counts them), integer/bool `queryType` (unsupported → refused), `loop_position` (changes only `loop_object`; post meta uses `loop_id`, term/user branches check `instanceof`). S29/S30 cover `select_loop_meta_key` and `loop_meta_key`; prefix stripping matches Divi's `get_meta_key_from_name`. Registry unavailable → default map → every `loop_*` refused. Live registry: 34 loop options, groups as assumed, `enable_html` refused.
- **Theme options:** 20 typography and layout keys, no custom CSS or head code; unknown keys refused at write (`ThemeOptionsAdapter.php:393-396`); font names without `<>"'\`` and control characters, exact Divi font required (`FontCheck`).
- **Colors and variables:** colors only hex, keywords or functions without `( ) ;` or quotes; string variables rendered through `wp_kses_post` (`DynamicContentGlobalVariableOptions.php:149-153`); fonts and numbers without breakout characters (images: L7).
- **Snapshots:** strict ID regex `^(colors|variables|presets|theme_options)-\d{8}T\d{6}Z-[0-9a-f]{6}$/D`; area taken from the ID, lookup by area and `===`; not found says nothing about other areas. `MAX_BYTES` 2 MB (413 before writing), FIFO 20, `TOTAL_BYTES` 8 MB keeping the newest, not autoloaded. The list shows `user_id`, `ability`, `log_id`, never `data`; data appears only as a restore diff behind the area's rights. Stored data is not re-validated on restore, but it is written only by `SnapshotStore::save()` from Divi's own inventory and no tool writes `lit_mcp_snapshots_*` (excluded from the settings whitelist), so changing it needs database or option access; partial re-checks still run (presets `markupOutside` both ways, Divi colors/variables sanitizers and `validate_global_variable_ids`, theme option whitelist). Rollback restores the snapshot on failure; a failed restore becomes `partial_write` naming the snapshot.
- **Font upload:** `allows()` denied `2130706433`, `0x7f.1`, `017700000001`, `127.1`, `[::ffff:127.0.0.1]`, `[::ffff:7f00:1]`, `localhost`, `localhost.`, `0`, `[::]`, `[fd00::1]`, `169.254.169.254`, `[64:ff9b::a9fe:a9fe]`, port 22, `ftp://`, `user:pw@`, the site's own host and public IPv6 literals (cURL is IPv4-only). Redirect hook name matches `WP_HTTP_Requests_Hooks::dispatch`; relative locations are absolutised first; both hooks removed in `finally`. Size `limit_response_size = max+1`, `max = min(upload limit, 5 MB)`, at most 4 files, empty files refused. Type: own magic bytes (`FontSignature`) must equal the format, then Divi's finfo check (fails closed without fileinfo), then `wp_handle_upload` with `test_type`. Name `[A-Za-z0-9 _-]`, length per Divi, case-insensitive collision check against Google, web-safe and uploaded fonts before any download; `sanitize_file_name`, Divi's `upload_dir_font`, `wp_unique_filename`: no traversal. Temp files deleted in `finally` on every path. Network reasons go to the log only (URL without credentials, query, fragment). The media import extraction behaves as before Etappe 4.

## Status nach der Fix-Welle (2026-10-20)

Basis: Audit-HEAD `5220876`, Stand danach `8ff3b16` (`composer test`: 3499 Tests grün, `composer lint` sauber; Smokes `divi-loop`, `divi-colors-variables`, `divi-theme-fonts`, `divi-presets` grün).

| Befund | Status |
|---|---|
| M1 | behoben in `522fc8f` (Kettenregel für `_meta_key_`-Optionen), `3a89b15` (Warnung nur bei Inhalten, die vorher passten), `8be2f5e` (Update: Composer und Zweitdurchlauf nach der ganzen Kette, vom Gesamtreview als umgehbar gefunden), `71ffbdb` (Warnung nennt die Kette) |
| L1 | Produktentscheidung Option B, behoben in `4a8a889`, `71c2e03` (Prüfung auf dem bereinigten Wert), `6e84138` (`queryType: null` wie Divi) |
| L2 | behoben in `522fc8f` |
| L3 | **offen**: globale Instanzen und Kopien (`unfiltered_html`) tragen `loop_*`-Inhalt über Schleifen-Arten ohne Prüfung. Eigener kleiner Plan nötig; bis dahin als Grenze zu behandeln. |
| L4 | behoben in `bd80ab1`, `bb54870` (Restore berechnet Fundstellen; P8a `blocked_ids`, `affected` im Probelauf). Bewusst kein `in_use` bei Presets (Spec §5: verwaiste Presets erlaubt, Warnung bleibt). |
| L5 | behoben in `b59a0c0`, `1b3ef55`, `c4ee195`, `99c7aab`, `f754772` (ein Lock für Farben und Theme-Optionen; unter der Sperre Divis Laufzeit-Caches verwerfen, gegen echtes Divi für Farben, Variablen und Presets nachgewiesen; Uninstaller räumt alte Lock-Namen) |
| L6 | behoben in `b59a0c0` |
| L7 | behoben in `06b798a` |
| L8 | teilweise behoben in `20e0216` (kein Abruf ohne cURL). Rest: bei https mit einem cURL ohne SSL kann Requests auf fsockopen ausweichen; selten, **bewusst belassen**. |
| L9 | **bewusst belassen**: Administrator-Niveau, Wirkung endet mit dem Request; ein Cap ändert das Verhalten und ist eine eigene Entscheidung. |
| I1–I10 | unverändert (Hinweise, kein Fix in dieser Welle) |

Rest-Risiken aus „Deferred items re-checked": DNS-Rebinding behoben in `20e0216` (`CURLOPT_RESOLVE`, auch für Weiterleitungsziele); `DesignLock`-Übernahmerennen behoben (L6); Lost Update zwischen Farben und Theme-Optionen behoben (L5); alle übrigen Punkte wie oben als „Akzeptabel" bewertet. Ruling Z2 (Zwei-Aufruf-Weg nur Warnung) hält jetzt, weil M1 und L2 geschlossen sind.

Re-Reviews: Opus-Re-Review (Wellen 1+2) fand L1-Umgehung und unvollständiges L5; Sonnet-Verifikation fand die `queryType: null`-Regression und das Cache-Problem bei Farben/Variablen/Presets. Beide Funde sind behoben. Die Commits `6e84138` und `99c7aab` hat das Gesamtreview gelesen, ohne Befund; L5 ist zusätzlich per Probe gegen echtes Divi belegt. Das Gesamtreview fand außerdem die Umgehung von M1 im Update (behoben in `8be2f5e`).