diff --git a/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.46.png b/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.46.png
new file mode 100644
index 00000000..9dc8de08
Binary files /dev/null and b/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.46.png differ
diff --git a/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.57.png b/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.57.png
new file mode 100644
index 00000000..446db311
Binary files /dev/null and b/dev/frontend/booking/Bildschirmfoto 2026-07-07 um 14.09.57.png differ
diff --git a/dev/optimize/optimize-14-07-2026.md b/dev/optimize/optimize-14-07-2026.md
new file mode 100644
index 00000000..6d56492a
--- /dev/null
+++ b/dev/optimize/optimize-14-07-2026.md
@@ -0,0 +1,519 @@
+# Security- & Code-Audit Pressekonto — 14.07.2026
+
+Vollständiger Audit des Presseportals (Hub `pressekonto` + zwei Spokes `presseecho`/`businessportal24` + Admin- und Kundenbereich).
+Stack: Laravel 12.57, PHP 8.4, Livewire 4 / Volt 1 / Flux Pro 2, Fortify 1, Sanctum 4, Cashier 16, Spatie Permission 6, mews/purifier 3.
+Jeder Befund ist gegen den tatsächlichen Code verifiziert; Datei:Zeile ist angegeben. Unsichere Einschätzungen sind als **„Zu verifizieren"** markiert.
+
+---
+
+## 0. Architektur-Zusammenfassung (Bestandsaufnahme)
+
+**Domain-/Theme-Modell (sehr sauber gelöst).** `ThemeServiceProvider` löst den Host einmalig zu einem Theme auf und delegiert Asset-/Vite-/URL-Verdrahtung an `App\Support\DomainAssetContext`. Beide öffentlichen Spokes teilen sich `view_prefix = 'web'` und `assets_dir = 'build/web'` (`config/domains.php`) — **ein** View-Baum, **ein** JS/CSS-Build. Die Themes unterscheiden sich nur über CSS-Token-Werte (`resources/css/web/theme-*.css`). Die vermutete „doppelte Frontend"-Problematik ist damit weitgehend bereits gelöst (Details in Abschnitt 4).
+
+**Routing.** `bootstrap/app.php` lädt `routes/domains.php` als Web-Einstieg. Der Portal-Host (`pressekonto`) bindet `auth.php` + `admin.php` + `customer.php`; `web.php` (öffentliche Spoke-Inhalte, host-agnostisch, mit `/{edition}`-Präfix de/en) und `legal.php` werden für alle Domains geladen. API: `routes/api.php` (Sanctum, `Api\V1\*`) + `routes/legacy-api.php` (Bestands-Integrationen `/service/*`).
+
+**Trennung User/Admin/Customer.** Zwei Gates: `access-admin` (Rollen admin **und** editor, oder super_admin), `access-customer` (admin/editor/customer). Admin-Routen hängen an `EnsureUserIsAdmin` + `BlockAdminDuringImpersonation`; Kundenbereich `/admin/me/*` an `EnsureUserIsCustomer`. Beide sind als `addPersistentMiddleware` registriert, greifen also auch auf `/livewire/update`-Folge-Requests — die **Panel-Trennung ist dicht**. Feingranulare Permissions (`users:manage`, `roles:manage`, `press-releases:publish` …) existieren über Spatie, werden aber **innerhalb** des Admin-Panels nicht überall erzwungen (siehe K1/H2).
+
+**Domänenmodell.** 50+ Models. Kern: `PressRelease` (Status-Maschine Draft→Review→Published/Depublished, KI-Klassifizierung/Scoring via Queue-Jobs), `Company`/`Contact` (CRM + öffentliche Newsrooms), Billing (`CreditWallet`/`CreditTransaction`/`CreditTopup`, `Invoice`, Cashier-Subscriptions, Stripe-Webhooks), Legacy-Import (`Legacy*`-Models + Legacy-API-Parität).
+
+**Testbestand.** ~176 Testdateien über Auth, Billing, API, Publishing, IDOR/Ownership — überdurchschnittlich breit.
+
+**Unklar / nicht erschöpfend gelesen:** jede einzelne Admin-Livewire-Komponente wurde teils stichprobenartig geprüft; der vollständige `app/Services/*`-Baum (gut faktorisiert). Als „Zu verifizieren" gekennzeichnete Punkte vor einem Fix bestätigen.
+
+---
+
+## 1. Executive Summary
+
+Der Gesamtzustand ist **gut bis sehr gut**: durchdachtes Theme-/Domain-System, dünne Controller mit Business-Logik in Services, kundenseitig durchweg sauberer IDOR-Schutz über Ownership-Scopes (`accessibleBy`) und Policies, HTMLPurifier für fremden PM-Content (doppelt: beim Speichern und beim Rendern), atomares Wallet-/Rechnungsnummern-Handling, breite Testabdeckung und eine performance-bewusste Read-Schicht.
+
+Es gibt jedoch **zwei kritische** und mehrere hohe Befunde, die vor einem Produktivbetrieb behoben werden müssen. Das schwerwiegendste ist eine **Rechteausweitung**: Die Benutzer- und Rollenverwaltung ist nur durch das grobe `access-admin`-Gate geschützt, das die Rolle `editor` einschließt — ein `editor` kann über die Verwaltungsmasken `is_super_admin = true` setzen, sich die Rolle `admin` zuweisen oder einer Rolle beliebige Permissions geben und damit die volle Kontrolle übernehmen, obwohl `users:manage`/`roles:manage` ihm bewusst vorenthalten sind. Dasselbe Gate lässt einen `editor` auch alle destruktiven Admin-CRUD-Aktionen (Firmen/PMs löschen, publizieren) ausführen. Zweitens liegen **echte Produktions-Secrets im Klartext in `.env`** (Live-OpenAI-Key, Google-OAuth-Secret, Mail-Passwort); die Datei ist zwar korrekt gitignored, die Secrets sind aber zu rotieren.
+
+Hoch eingestuft sind zudem eine **Impersonation ohne Rangprüfung** (ein Admin kann einen Super-Admin übernehmen und in dessen Namen ein persistentes API-Token erzeugen), eine **Doppel-Gutschrift bei gleichzeitigem Stripe-Webhook-Retry** (echtes Geld), ein **`javascript:`-Link aus dem anonymen Kontaktformular**, der im Admin-Backend ausgeführt wird, das ungeschützte Vertrauen in alle Proxies inkl. `X-Forwarded-Host` (Host-Header-Injection) sowie veraltete Abhängigkeiten mit HIGH-CVEs. Die Performance- und Duplikations-Findings sind inkrementelle Härtung.
+
+---
+
+## 2. Befunde (sortiert nach Schweregrad)
+
+| # | Schweregrad | Kategorie | Datei:Zeile | Beschreibung | Empfohlener Fix |
+|---|---|---|---|---|---|
+| K1 | **Kritisch** ✅ behoben | Broken Access Control / Mass Assignment | `resources/views/livewire/admin/users/edit.blade.php:422,425` · `create.blade.php:127,131` · `admin/roles/edit.blade.php:67` · `roles/create.blade.php` | `editor` (via `access-admin`-Gate) kann auf User-/Rollen-Masken `is_super_admin=true` setzen, sich Rolle `admin` zuweisen oder einer Rolle Permissions geben — keine `users:manage`/`roles:manage`-Prüfung. Volle Eskalation. | In `mount()` + jeder Schreibmethode `abort_unless(...->can('users:manage'/'roles:manage'),403)`; `is_super_admin`/Admin-Rolle nur für Super-Admins. **→ Umgesetzt, siehe Abschnitt 7.** |
+| K2 | **Kritisch** | Secrets | `.env` (OPENAI_API_KEY, GOOGLE_CLIENT_SECRET, MAIL_PASSWORD) | Echte Live-Secrets im Klartext (`sk-proj-…`, `GOCSPX-…`). `.env` ist gitignored (gut), Secrets aber als kompromittiert zu behandeln. | Secrets **rotieren**; auskommentierte Live-Credentials entfernen; Secret-Manager/Deploy-Env statt Datei. |
+| H1 | **Hoch** ✅ behoben | Autorisierung / Impersonation | `app/Actions/Admin/UserImpersonation.php:26-29` | `canBeImpersonated()` erlaubt jedes Ziel mit `canAccessCustomer()` — inkl. Admins/Super-Admins. Impersonierter Kundenbereich erlaubt **API-Token-Erstellung** → persistenter Zugriff nach Verlassen. | Rangprüfung: Ziel darf nicht `canAccessAdmin()`/`is_super_admin` sein; ggf. Token-Erstellung während Impersonation sperren. |
+| H2 | **Hoch** ✅ behoben | Broken Access Control (systemisch) | `admin/companies/edit.blade.php:187` · `press-releases/index.blade.php:220,244,259` · `edit.blade.php:337` · `categories/edit.blade.php:134` u. a. | Destruktive/publizierende Admin-CRUD-Aktionen sind nur `access-admin`-gated, prüfen keine spezifische Permission. `editor` kann Firmen/PMs löschen, publizieren (`press-releases:publish` wird nicht aufgerufen). **Zu verifizieren**, ob `editor` gewollt Vollzugriff hat. | Zielrechte je Aktion definieren, per `authorize('...')`/`can:`-Route erzwingen; Publish konsistent gegen `press-releases:publish`. |
+| H3 | **Hoch** ✅ behoben | XSS (Stored, javascript-URI) | `app/Http/Controllers/Web/ContactController.php:40` → `resources/views/livewire/admin/contact-messages/show.blade.php:166` | `page_url` aus anonymem Kontaktformular nur `string` validiert (keine `url`-Regel), im Backend als `` ausgegeben. `javascript:`-URL läuft beim Admin-Klick im Admin-Kontext. | `'page_url' => ['nullable','url:http,https','max:500']`; defensiv beim Rendern nur http/https-Links klickbar machen. |
+| H4 | **Hoch** ✅ behoben | Race Condition / Payments | `app/Services/Billing/CreditTopupService.php:70-91` | Idempotenz-Guard (`credited_at !== null`) liegt **außerhalb** der Transaktion, kein Row-Lock, keine Unique auf `credit_transactions.reference`. Zwei gleichzeitige Webhook-Zustellungen → **doppelte Gutschrift**. | Guard in Transaktion + `lockForUpdate()`; oder Unique-Index auf `(reference_type,reference_id,type)`. |
+| H5 | **Hoch** ✅ behoben | Host-Header-Injection | `bootstrap/app.php:79-85` | `trustProxies(at:'*')` inkl. `X-Forwarded-Host`, **keine** `trustHosts`-Whitelist. Client bestimmt Host für URL-Generierung → vergiftbare Reset-/Verify-/signierte Links, Cache-Poisoning. | `->trustHosts(at:[...Domains])`; Proxy-Vertrauen auf bekanntes Subnetz statt `*`. |
+| H6 | **Hoch** ✅ behoben | CVEs / veraltete Packages | `composer.lock` | `composer audit`: 19 Advisories, u. a. **HIGH** `symfony/http-kernel` (HEAD-Bypass CVE-2026-45075), `symfony/mime` (E-Mail-Injection CVE-2026-45067), `laravel/framework <12.60` (CRLF im email-Rule). Projekt ist 12.57 → betroffen. | `composer update` auf gepatchte Minor-Versionen; danach `composer audit` erneut. |
+| H7 | **Hoch** ✅ behoben | Performance / Caching | `app/Support/CategoryNavigation.php:35-53` | Navigations-Chrome (Header/Footer/Branchenindex/Suche) rechnet pro Request ≥2 uncached Count-Aggregate über das **gesamte** Archiv — auf **jeder** Web-Seite. | `Cache::remember()` keyed `portal.language.limit`, ~300s (analog `TickerData`). |
+| M1 | Mittel ✅ behoben | Authentifizierung / 2FA | `app/Http/Controllers/Auth/MagicLinkConsumeController.php:53` | Magic-Link loggt direkt ein, umgeht aktiviertes 2FA (regulärer Login leitet korrekt in die Challenge). | Bei `hasEnabledTwoFactorAuthentication()` auch nach Magic-Link in die 2FA-Challenge. |
+| M2 | Mittel ✅ behoben | Race Condition / Logic | `app/Services/PressRelease/PressReleaseService.php:243-277` | `consumePublishSlot()` liest Quota ungelockt, `publish()` nicht in Transaktion → Quota-Überkonsum bei gleichzeitigem Publish (Scheduler + Admin); Slot-Verbrauch ohne Publish bei Teilfehler. | `publish()` in `DB::transaction` + `lockForUpdate` auf User-Zeile vor Read-Modify-Write. |
+| M3 | Mittel ✅ behoben | Race Condition | `app/Models/Concerns/HasUniqueSlug.php:39-50` · `Api/V1/PressReleaseController.php:250-269` | Slug-Check-then-insert ohne Lock. Unique-Index verhindert Duplikat, aber zweite gleichzeitige Einreichung → unbehandelte `QueryException` (HTTP 500) statt `-2`-Suffix. | Unique-Violation beim `save()` fangen + neu generieren/retry. |
+| M4 | Mittel ✅ behoben | File Upload / Zugriff | `app/Services/PressRelease/PressReleaseAttachmentStorage.php:17-19` · `app/Services/Image/ImageService.php:85` | Medien von **Entwürfen/abgelehnten/Embargo-PMs** liegen auf der `public`-Disk → ohne Auth per URL abrufbar (UUID mildert, verhindert Leak via Referer/Logs nicht). | Vertrauliche Stadien auf `local`-Disk + kontrollierte Auslieferungsroute; Bestandsmedien per Deploy-Kommando migrieren. |
+| M5 | Mittel ✅ behoben | File Upload (Defense-in-depth) | `app/Services/PressRelease/PressReleaseAttachmentStorage.php:96-107` | Storage-Schicht prüft nur (Client-)Extension; `ALLOWED_MIMES` (Z. 28-39) ungenutzt. Vorgelagerte Livewire-`mimes:`-Regel mildert; API-Pfad könnte Prüfung umgehen. | In `assertValidUpload()` zusätzlich `in_array($upload->getMimeType(), self::ALLOWED_MIMES, true)`. |
+| M6 | Mittel ✅ behoben | XSS (Defense-in-depth) | `app/Http/Controllers/Api/V1/PressReleaseController.php:47,105` | API speichert `text` **ungefiltert** (Livewire-Pfade sanitizen vor Persistenz). Ausgabe fängt es aktuell via `renderedText()` ab; jeder künftige Roh-Sink (RSS/Export/Mail) → Stored-XSS. | Vor `create()`/`fill()`: `app(PressReleaseHtmlSanitizer::class)->clean($validated['text'])`. |
+| M7 | Mittel ✅ behoben | Logic / Datenintegrität | `app/Http/Controllers/Api/V1/NewsletterSubscriptionController.php:17-33` | `updateOrCreate` auf `(portal,email)` setzt immer `is_confirmed=false` + überschreibt `user_id`/`ip`. Bestätigter Abonnent wird still ent-bestätigt; fremder API-User übernimmt Ownership. | Bereits bestätigte Datensätze nicht zurücksetzen; Ownership-Rebind unterbinden. |
+| M8 | Mittel ✅ behoben | Mass Assignment (latent) | `app/Models/User.php:34-53` | `is_super_admin`/`is_active` im `$fillable`. Aktuell über K1 ausnutzbar, aber Landmine für jedes künftige `update($request…)`. | `is_super_admin` aus `$fillable` entfernt; nur per autorisiertem `forceFill`. **→ Abschnitt 7.** |
+| M9 | Mittel | Session-Cookie | `.env` / `config/session.php:172` | `SESSION_SECURE_COOKIE` ungesetzt → kein `Secure`-Flag trotz durchgehend https; `SESSION_ENCRYPT=false`. | `SESSION_SECURE_COOKIE=true` in allen https-Umgebungen. |
+| M10 | Mittel | Security-Header | `app/Http/Middleware/SecurityHeaders.php:11-31` | Gute Header vorhanden, aber **kein HSTS** und **keine CSP** (bewusst zurückgestellt). Bei fremdem HTML-Content wäre CSP wertvolle zweite Linie. | HSTS ergänzen; CSP als eigenes Vorhaben mit Nonce-Strategie (Livewire/Alpine). |
+| M11 | Mittel ✅ behoben | Credential-Übergabe | `app/Http/Middleware/RejectLegacyApiKeys.php:56-66` | Legacy-API-Key wird auch aus `query('api_key')` akzeptiert → landet in Access-/Proxy-Logs, Referer, Historie. Key ist gültiges Sanctum-Token. | Query-/Body-Variante entfernt; nur Bearer- und Legacy-Header bleiben zulässig. |
+| M12 | Mittel ✅ behoben | Performance | `app/Services/Web/ReleaseDetailPageData.php:64-72` | Write-on-read: UPDATE `hits` + INSERT Event bei jedem GET → meistfrequentierte Seite nie response-cachebar, 2 Writes/View. | Zähler/Event per `defer()` nach die Response verlagert; Hit-Inkrement atomar. |
+| M13 | Mittel ✅ behoben | Performance / Caching | `app/Services/Web/SuchePageData.php` · `NewsroomDetailPageData.php` | Einzige Web-`PageData` **ohne** `Cache::remember`; NewsroomDetail ~10+ Aggregate/Request. | Cache nach Portal/Sprache/Slug und Paginierungsseite ergänzt (TTL 300 s). |
+| M14 | Mittel | Konsistenz / Autorisierung | `app/Http/Controllers/Api/V1/PressReleaseController.php:29,79,146,198` | Zwei Autorisierungsstile: Policies (Web/PDF) vs. manuelle `abort_unless(tokenCan())` + Owner-Scopes (API). Reviewer sieht Coverage nicht aus der Policy. | Ownership über `PressReleasePolicy`/`CompanyPolicy` routen; `tokenCan()` nur für Token-Scope. |
+| M15 | Mittel | Duplikation | `resources/views/web/presseecho.blade.php` · `businessportal24.blade.php` | Zwei nahezu identische Landingpages (je 59 Z., 4 abweichende, aus Portal/Theme ableitbare Stellen); `HomeController:21-24` verzweigt. Jede Änderung doppelt. | Zu einer `web/home.blade.php` zusammenführen (Abschnitt 4). |
+| N1 | Niedrig | Queues / Error Handling | `app/Jobs/ClassifyPressRelease.php:32,64-73` · `ScorePressRelease.php:29,53-62` | `tries=3`, aber kein `backoff`/`failed()`; jeder Versuch schreibt `KiAudit`-Zeile ohne Dedup → Duplikate bei Retry. | `backoff` setzen; Audit-Write idempotent/letzter Schritt. |
+| N2 | Niedrig | Offener Redirect | `livewire/customer/company-switcher.blade.php:47` · `admin/portal-switcher.blade.php:39` | `redirect(request()->headers->get('referer'))` — client-kontrollierter Header ohne Whitelisting (praktisch same-origin). | Auf interne Route-Namen/Pfade beschränken bzw. Host-Check. |
+| N3 | Niedrig | XSS / Validierung | `web/newsroom.blade.php:84` · `admin/users/edit.blade.php:392` u. a. | `company->website`/`backlink_url` mit `url`-Default-Regel (erlaubt `ftp`/`skype`/…); `profile.backlink_url` im Admin ganz ohne `url`-Regel. `javascript:` scheitert bereits. | Flächendeckend `url:http,https`; Admin-Regel angleichen. |
+| N4 | Niedrig | Logic / Business Rule | `app/Console/Commands/ResetMonthlyPressReleaseQuota.php:33-34` · `routes/console.php:80-84` | Quota-Reset kalendarisch (1. des Monats), nicht am Stripe-Billing-Anker → Bonus-Monat bei Abschluss am Monatsende. **Zu verifizieren** ob gewollt. | Produktentscheidung; ggf. an Subscription-Periode ankern. |
+| N5 | Niedrig | CSRF / Design | `app/Http/Controllers/EmailUnsubscribeController.php:25-46` | GET ändert Zustand (Abmeldung). Durch unbefristete signierte URL geschützt, aber Link-Prefetcher/Scanner können ungewollt abmelden. | GET nur Bestätigung; Austragung per POST-Button (RFC-8058-POST bleibt). |
+| N6 | Niedrig | Dead Code | `routes/domains.php:44-52,35-37,22` · `resources/css/web/test.css` · `theme-main.css:3` | Leere Domain-Route-Gruppen, auskommentierte Blöcke, verwaiste CSS (`test.css` Tailwind v3; `@source` auf nicht existente `layout.blade.php`). | Löschen/Pfad korrigieren. |
+| N7 | Niedrig | Performance | `app/Http/Controllers/Web/SitemapController.php:111-116` | Volles Archiv per `->get()` in Speicher (3-Spalten + 1h-Cache mildern). Risiko 50k-URL/50MB-Limit + Memory-Spike bei Cache-Miss. | Sitemap-Index + `chunk()`/`cursor()`. |
+| N8 | Niedrig | DB-Index | `HomePageData.php:110` · `CategoryPageData.php:153` · `SuchePageData.php:25` | `orderByDesc('hits')` ohne passenden Index → Filesort über gefilterten Archiv (v. a. uncachedes `SuchePageData`). | Composite-Index `(portal,language,status,deleted_at,hits)`. |
+| N9 | Niedrig | CORS | fehlende `config/cors.php` | Framework-Default (`allowed_origins=['*']`, aber `supports_credentials=false`, nur `api/*`). API ist Bearer-basiert → Risiko gering. | Explizit auf bekannte Origins beschränken. |
+| N10 | Niedrig | DB-Benutzer | `.env` `DB_USERNAME=root` | Alle drei Verbindungen als `root`. Lokal tolerierbar, produktiv nie. | Least-Privilege-DB-User. |
+| N11 | Niedrig | Duplikation / DRY | `app/Http/Controllers/CheckoutController.php:37-43,71-77,…` | Fünf Checkout-Actions mit identischem Billing-/Unternehmer-Guard-Prelude. | Middleware `EnsureBillingReady` oder `guardCheckout()`-Helper. |
+| N12 | Niedrig | Konsistenz | `Api/V1/PressReleaseController.php:153-155` u. a. | Inline-`$request->validate()` neben etablierten Form Requests (nur 4 FR, alle API). | `submit()` etc. in Form Requests promoten (optional). |
+| I1 | Info | Debug/Config | `.env` `APP_DEBUG=true`, `APP_ENV=local` | Lokal ok; gefährlich sobald abgeleitete `.env` produktiv läuft (Live-URLs bereits gesetzt → dev/prod-Trennung unscharf). | Für Nicht-Dev `APP_DEBUG=false`, `APP_ENV=production` erzwingen. |
+| I2 | Info | SQLi (Zu verifizieren) | `app/Services/Admin/AdminSlowRequestReporter.php:302` | `DB::select($prefix.$sql)` führt `EXPLAIN` auf geloggten SQL-Texten aus (App-eigenes Query-Log, `isExplainable()` beschränkt auf SELECT). Kein User-Input-Pfad gefunden. | Zusätzlich Mehrfach-Statements (`;`) per Regex ausschließen. |
+
+---
+
+## 3. Detailabschnitte (Kritisch & Hoch)
+
+### K1 — Rechteausweitung: `editor` → Super-Admin
+
+**Kette (verifiziert):**
+1. `EnsureUserIsAdmin` prüft nur das Gate `access-admin` (`app/Http/Middleware/EnsureUserIsAdmin.php:20`).
+2. `access-admin` = `canAccessAdmin()`, das `editor` einschließt:
+```php
+// app/Models/User.php:471
+public function canAccessAdmin(): bool
+{
+ if (! $this->is_active) { return false; }
+ if ($this->is_super_admin) { return true; }
+ return $this->hasAnyRole(['admin', 'editor']); // ← editor darf in den Admin-Bereich
+}
+```
+3. Der Seeder gibt `editor` bewusst **nicht** `users:manage`/`roles:manage` (`database/seeders/RolesAndPermissionsSeeder.php:34-35,47-55`) — die Granularität ist gewollt.
+4. Die Volt-Komponenten `admin/users/*` und `admin/roles/*` erzwingen sie aber nirgends. `save()` schreibt ungeprüft aus dem Formular:
+```php
+// resources/views/livewire/admin/users/edit.blade.php:415
+$user->update([
+ // ...
+ 'is_active' => $this->isActive,
+ 'is_super_admin' => $this->isSuperAdmin, // ← Checkbox aus dem Formular (:856)
+]);
+$user->syncRoles($validated['selectedRoles']); // ← 'admin' via Rule::exists('roles','name') erlaubt
+```
+`grep` nach `authorize`/`->can(`/`abort`/`users:manage` in diesen vier Komponenten: **null Treffer**. `mount()` (`edit.blade.php:139`) hat keinen Guard. Analog `admin/roles/edit.blade.php:67` (`syncPermissions` ohne `roles:manage`): ein `editor` kann der eigenen Rolle beliebige Permissions geben.
+
+**Warum kritisch:** Ein `editor` ruft `/admin/users/{eigeneId}/edit` auf, setzt `is_super_admin=true` (oder weist sich `admin` zu) und erlangt vollständige Kontrolle — inklusive aller ihm konzeptionell entzogenen Permissions. Die Inkonsistenz ist im Code belegt: Impersonation prüft `users:manage` (`UserImpersonation.php:15`), PM-Publish kennt `press-releases:publish` — nur die User-/Rollen-CRUD nicht.
+
+**Fix:**
+```php
+// in mount() UND jeder Schreibmethode von admin/users/* und admin/roles/*
+abort_unless(auth()->user()->can('users:manage'), 403); // bzw. 'roles:manage'
+
+// is_super_admin / privilegierte Rollen zusätzlich absichern:
+$targetSuperAdmin = auth()->user()->is_super_admin
+ ? $this->isSuperAdmin
+ : $user->is_super_admin; // Nicht-Super-Admin darf das Flag nicht ändern
+$user->forceFill(['is_super_admin' => $targetSuperAdmin])->save();
+```
+Sauberer: `UserPolicy`/`RolePolicy` einführen und `$this->authorize(...)` nutzen (analog vorhandener Policies). Zusätzlich M8 umsetzen (Flag aus `$fillable`).
+
+---
+
+### K2 — Echte Produktions-Secrets im Klartext in `.env`
+
+**Verifiziert:** `.env` ist **nicht** in Git (`git ls-files --error-unmatch .env` schlägt fehl) — korrekt. Die Datei enthält aber reale Live-Geheimnisse:
+- `OPENAI_API_KEY=sk-proj-…` — echter `sk-proj`-Key (verifiziert vorhanden, kein Test-Platzhalter).
+- `GOOGLE_CLIENT_SECRET=GOCSPX-…` mit Live-`GOOGLE_REDIRECT_URI` (`pressekonto.com`).
+- `MAIL_PASSWORD=…` (aktiv) plus ein zweites, auskommentiertes Live-Mailpasswort; auskommentiertes Live-DB-Passwort unter „Live Credentials".
+
+**Warum kritisch:** Klartext-Live-Secrets auf dem Host, teils historisch auskommentiert (= nicht rotiert). In Kombination mit `APP_DEBUG=true` (I1) und fehlender Host-Whitelist (H5) steigt die Exponierungsfläche.
+
+**Fix:** OpenAI-, Google- und aktives Mail-Secret **rotieren** und als kompromittiert behandeln. Auskommentierte Live-Credentials vollständig entfernen. Secrets über Deployment-Env/Secret-Manager bereitstellen, nicht als Datei.
+
+---
+
+### H1 — Impersonation ohne Rangprüfung
+
+```php
+// app/Actions/Admin/UserImpersonation.php:26
+public function canBeImpersonated(User $target): bool
+{
+ return $target->canAccessCustomer(); // gilt auch für Admins/Super-Admins
+}
+```
+Admins erfüllen `canAccessCustomer()`. Ein Initiator mit `users:manage` (selbst kein Super-Admin) kann daher einen **Super-Admin** impersonieren. Der Admin-Bereich ist währenddessen gesperrt (`BlockAdminDuringImpersonation`), der **Kundenbereich des Ziels** aber voll — inkl. **API-Token-Erstellung** (`resources/views/livewire/customer/tokens.blade.php`, `auth()->user()->createToken(...)`). Ein so erzeugtes Token überlebt das Verlassen der Impersonation → persistenter Zugriff im Namen des höher privilegierten Kontos. (Das Impersonation-**Grundgerüst** ist ansonsten sauber: `canInitiate` serverseitig, keine verschachtelte Impersonation, Leave validiert `canAccessAdmin()` des Original-Admins.)
+
+**Fix:**
+```php
+public function canBeImpersonated(User $target): bool
+{
+ return $target->canAccessCustomer()
+ && ! $target->canAccessAdmin()
+ && ! $target->is_super_admin;
+}
+```
+Optional: Token-Erstellung während aktiver Impersonation unterbinden.
+
+---
+
+### H2 — Admin-CRUD/Publish nur grob `access-admin`-gated (systemisch)
+
+Keine der folgenden mutierenden Aktionen prüft eine spezifische Permission; die Absicherung endet am `access-admin`-Gate (= admin **oder** editor):
+- `admin/companies/edit.blade.php:187` `deleteCompany()`, `:104` `update()`
+- `admin/press-releases/index.blade.php:220,244,259` `publish()/reject()/archive()`; `edit.blade.php:271,337` `publish()/deletePressRelease()`
+- `admin/categories/edit.blade.php:134` `delete()`; `admin/footer-codes/edit.blade.php:85` `delete()`; `admin/contacts/index.blade.php:351` `deleteContactFromIndex()`; `admin/payments/index.blade.php:40` `cancelBundle()`
+
+Für **Veröffentlichen** existiert die Permission `press-releases:publish` (die `editor` hat), sie wird aber weder in der Komponente noch in `PressReleaseService::publish()` per `authorize` erzwungen. **Zu verifizieren**, ob `editor` bewusst Vollzugriff auf all diese Aktionen haben soll. Falls einzelne (Firmen/PMs löschen, Bundle kündigen) nur `admin` vorbehalten sein sollen, fehlt die Prüfung.
+
+**Fix:** Pro Aktion Zielrecht definieren und via `authorize('...')`/`can:`-Route erzwingen; Publish konsistent gegen `press-releases:publish`.
+
+---
+
+### H3 — Stored-XSS via `page_url` (javascript-URI) im Admin-Backend
+
+```php
+// app/Http/Controllers/Web/ContactController.php:40
+'page_url' => ['nullable', 'string', 'max:500'], // ← keine URL-Regel
+```
+```blade
+{{-- resources/views/livewire/admin/contact-messages/show.blade.php:166 --}}
+
+```
+`page_url` stammt aus dem **anonymen** Kontaktformular. Blade-Escaping verhindert keine `javascript:`-URLs. Ein anonymer Besucher schleust `javascript:fetch('/admin/...')` ein; klickt ein Admin den Link im Backend, läuft der Code im Session-/Privilegien-Kontext des Admins.
+
+**Fix:** `'page_url' => ['nullable', 'url:http,https', 'max:500']`; defensiv beim Rendern:
+```blade
+@if ($message->page_url && Str::startsWith($message->page_url, ['http://', 'https://']))
+ {{ $message->page_url }}
+@else
+ {{ $message->page_url }}
+@endif
+```
+
+---
+
+### H4 — Doppelte Gutschrift bei gleichzeitigem Stripe-Webhook
+
+```php
+// app/Services/Billing/CreditTopupService.php:70
+if ($topup->credited_at !== null) { return; } // Guard AUSSERHALB der Transaktion, ohne Lock
+// ...
+DB::transaction(function () use ($topup, ...) {
+ $wallet->credit(...); // additiv
+ $topup->update(['credited_at' => now()]);
+});
+```
+`credit_transactions` hat **keine** Unique auf `reference` (`2026_06_17_141219_create_credit_transactions_table.php` nur `nullableMorphs`). Stripe liefert Webhooks at-least-once, Cashier verarbeitet sie synchron pro HTTP-Request. Zwei nahezu gleichzeitige Zustellungen (Original + Retry) lesen beide `credited_at === null`, passieren beide den Guard und **gutschreiben zweimal**. (Der `fulfillSinglePurchase()`-Pfad hat dieselbe Form, ist aber idempotent in der Folgewirkung — nur der additive Top-up ist scharf.)
+
+**Fix:**
+```php
+DB::transaction(function () use ($topup, ...) {
+ $topup = CreditTopup::whereKey($topup->id)->lockForUpdate()->first();
+ if ($topup->credited_at !== null) { return; }
+ $wallet->credit(...);
+ $topup->update(['credited_at' => now()]);
+});
+```
+Alternativ/zusätzlich Unique-Index auf `credit_transactions (reference_type, reference_id, type)`.
+
+---
+
+### H5 — Host-Header-Injection (alle Proxies + `X-Forwarded-Host`)
+
+```php
+// bootstrap/app.php:79
+$middleware->trustProxies(
+ at: '*',
+ headers: Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_HOST | ...
+);
+```
+Es gibt **keine** `trustHosts`-Whitelist (grep: kein Treffer). Damit bestimmt der Client per `X-Forwarded-Host` den Host, den Laravel für URL-Generierung nutzt: vergiftbare absolute Links in Passwort-Reset-/Verify-Mails, **signierten** Abmelde-/Verify-URLs (Host geht in die Signaturbasis ein) und Cache-Poisoning. In einem reinen Traefik/Docker-Setup ist `at:'*'` nur unbedenklich, wenn die App ausschließlich über den Proxy erreichbar ist — das erzwingt die App selbst nicht.
+
+**Fix:**
+```php
+->trustHosts(at: ['pressekonto.de', 'presseecho.de', 'businessportal24.de']) // reale Domains
+```
+Nach Möglichkeit Proxy-Vertrauen auf das bekannte Proxy-Subnetz statt `*` einschränken.
+
+---
+
+### H6 — Veraltete Packages mit HIGH-CVEs
+
+`composer audit`: **19 Advisories / 10 Packages**. Relevant:
+- **HIGH** `symfony/http-kernel` CVE-2026-45075 (HEAD-Request umgeht `methods:['GET']`-Filter in `#[IsGranted]`/CSRF-Attributen).
+- **HIGH** `symfony/mime` CVE-2026-45067 (E-Mail-Header/SMTP-Injection via CRLF in `Address`).
+- **HIGH** `laravel/framework < 12.60` (CRLF im default email-Rule) — Projekt ist **12.57**, betroffen; ferner „Temporary Signed URL Path Confusion" (medium) `< 12.61.1`.
+- Diverse **medium** in `guzzlehttp/guzzle`, `guzzlehttp/psr7`, `symfony/routing`, `symfony/mailer`, `symfony/http-foundation` (SSRF-Bypass), `symfony/polyfill-intl-idn`, `symfony/yaml`.
+
+**Fix:** `composer update` auf gepatchte Minor-Versionen (Framework ≥ 12.61.1, Symfony ≥ 7.4.13 / 6.4.41, Guzzle ≥ 7.12.1, psr7 ≥ 2.12.1), danach `composer audit` erneut + Test-Suite.
+
+---
+
+### H7 — Uncached Navigations-Chrome auf jeder Seite
+
+```php
+// app/Support/CategoryNavigation.php:35 — pro Request, uncached
+Category::query()->topLevel()...
+ ->withCount(['pressReleases as published_count' => ...]) // korrelierte Aggregatabfrage übers ganze Archiv
+```
+Aufgerufen in `site-header.blade.php:36` (`items(null)` = alle Kategorien), `site-footer.blade.php:49`, `industry-index.blade.php:6`, `livewire/web/search.blade.php:68`. Jeder anonyme Seitenaufruf zahlt ≥2 uncachede Count-Aggregate — obwohl die Seitendaten selbst (`HomePageData`/`CategoryPageData`/`TickerData`) sorgfältig 300s gecacht sind.
+
+**Fix:**
+```php
+return Cache::remember("catnav:{$portal}:{$language}:".($limit ?? 'all'), 300,
+ fn () => /* aktuelle Query */);
+```
+Bester Einzel-Perf-Gewinn, geringes Risiko.
+
+---
+
+## 4. Duplikations-Konsolidierungsplan (die zwei Frontends)
+
+**Kernaussage:** Die vermutete Duplikation ist **weitgehend bereits gelöst**. Beide Spokes teilen Layout, Komponenten, Controller, Routen, CSS-Tokens und Daten-Services. Was gut ist und **so bleiben soll**:
+- Domain→Theme einmalige Auflösung in `ThemeServiceProvider` + `DomainAssetContext`; beide Spokes `view_prefix='web'`, `assets_dir='build/web'`.
+- Token-basierte Themes: `theme-presseecho.css`/`theme-businessportal24.css` importieren `shared-styles.css` und redefinieren dieselben `@theme`-Tokennamen mit anderen Werten. **Nicht zusammenführen** — die per-Brand-Werte sind der beabsichtigte Variationspunkt.
+- Config-aware Komponenten (`x-web.site-header`/`site-footer` lesen `config('app.theme')`), zentraler `WebPortalContext::fromRequest()`.
+
+**Einzige echte Copy-Paste-Stelle — Landingpages (M15):**
+`presseecho.blade.php` vs. `businessportal24.blade.php` (je 59 Z.) differieren an genau 4 Stellen, alle zur Renderzeit ableitbar:
+- L4 Brand: `config('domains.domains..brand')`
+- L9-13 Meta-Fallbacks: bereits als `brand.meta_title`/`meta_description` in `config/domains.php` vorhanden
+- L32 Portal: `WebPortalContext::portalFromHost()->value`
+
+**Umsetzung (Priorität 1):**
+1. `resources/views/web/home.blade.php` mit dem gemeinsamen Body anlegen.
+2. Die 4 Stellen durch die o. g. Lookups ersetzen (Brand/Meta aus `config('app.theme')`, Portal aus `WebPortalContext`).
+3. `HomeController::__invoke` (`app/Http/Controllers/Web/HomeController.php:21-24`) auf `return view('web.home', $pageData->build(...))` vereinfachen — Verzweigung löschen.
+4. `presseecho.blade.php` + `businessportal24.blade.php` löschen.
+5. Feature-Test: beide Hosts rendern `web.home` mit korrektem Brand-Namen und Portal-Feed.
+
+**Priorität 2 — Aufräumen (N6):** leere Domain-Route-Gruppen (`routes/domains.php:44-52`), auskommentierte Blöcke (`:22,35-37`), `resources/css/web/test.css`, kaputter `@source` in `theme-main.css:3` löschen/korrigieren.
+
+**Priorität 3 — Konsistenz (M14, N11, N12):** API-Ownership über die vorhandenen Policies routen; Checkout-Guard-Prelude in Middleware extrahieren; Inline-Validierungen optional in Form Requests promoten.
+
+---
+
+## 5. Priorisierte Maßnahmenliste
+
+**Sofort — Sicherheit (blockierend für Produktivbetrieb):**
+1. **K1** — `users:manage`/`roles:manage` auf allen `admin/users/*`- und `admin/roles/*`-Komponenten erzwingen; `is_super_admin`/Admin-Rolle nur für Super-Admins. + **M8** (`is_super_admin` aus `$fillable`).
+2. **H2** — Zielrechte für destruktive/publizierende Admin-Aktionen definieren und erzwingen (Klärung Rollenmodell `editor`).
+3. **K2** — OpenAI-, Google-, Mail-Secrets rotieren; auskommentierte Live-Credentials entfernen.
+4. **H1** — Impersonation-Rangprüfung. **H4** — Wallet-Top-up in Transaktion + Row-Lock (echtes Geld).
+5. **H3** — `page_url`-Validierung + Render-Guard (trivialer Fix, hoher Impact).
+6. **H5** — `trustHosts`-Whitelist. **M9** (`SESSION_SECURE_COOKIE=true`), **I1** (`APP_DEBUG=false` Nicht-Dev) mitnehmen.
+7. **H6** — `composer update` auf gepatchte Versionen, `composer audit` grün.
+
+**Danach — Korrektheit/Bugs:**
+8. **M2** (Quota-TOCTOU), **M3** (Slug-500) transaktional/lock-basiert absichern.
+9. **M1** (Magic-Link 2FA), **M5/M4** (Attachment-MIME + private Disk für unveröffentlichte Medien), **M6** (API-Text sanitizen), **M7** (Newsletter-Rebind), **M11** (Legacy-Key im Query).
+10. **N1** (Job-Backoff/Idempotenz), **N4** (Quota-Reset-Modell klären), **N2** (Referer-Redirect), **N3** (`url:http,https`).
+
+**Mittelfristig — Performance/Refactoring:**
+11. **H7** (`CategoryNavigation` cachen) — größter Perf-Gewinn, sofort machbar.
+12. **M12** (Write-on-read deferred), **M13** (Suche/Newsroom cachen), **N8** (`hits`-Index), **N7** (Sitemap-Chunking).
+13. **M15/N6/M14/N11** (Landing-Konsolidierung, Dead Code, Autorisierungs-Vereinheitlichung).
+14. **M10** (HSTS jetzt, CSP als Projekt).
+
+**Test-Lücken (empfohlene Feature-Tests):**
+- **K1-Regressionstest:** `editor` erhält 403 auf `admin/users`/`admin/roles` und kann `is_super_admin` nicht setzen.
+- **H1-Regressionstest:** Impersonation eines Admins/Super-Admins wird abgelehnt.
+- **H4-Regressionstest:** doppelte Webhook-Zustellung gutschreibt nur einmal.
+- **H3-Regressionstest:** `javascript:`-`page_url` wird abgewiesen/nicht als Link gerendert.
+- Query-Budget-Test auf `web.home` (`DB::listen`, Schwelle) — fängt N+1-Regressionen im Chrome/PageData.
+- `CategoryNavigation`: Caching + Ordering + Portal/Language-Scope.
+- Release-Detail: GET erhöht `hits` um exakt 1 + genau ein `PressReleaseEvent`; nach Deferral Response unverändert.
+- Sitemap-Scale (Chunking/URL-Limit); NewsroomDetail-Caching; Boost-Precedence (erweitert `BoostPlacementTest`).
+
+---
+
+## 6. Was gut gelöst ist (nicht anfassen)
+
+- **Domain-/Theme-System** (Abschnitt 0/4) — vorbildlich token-getrieben.
+- **Panel-Trennung dicht:** `EnsureUserIsAdmin`/`EnsureUserIsCustomer` als `addPersistentMiddleware` registriert → auch `/livewire/update`-Folge-Requests re-geprüft.
+- **IDOR kundenseitig sauber:** `accessibleBy`/`findFor`-Scopes + Policy-`authorize()` an jeder mutierenden Stelle; `#[Locked]` auf Entity-IDs. `ProofPdfController`, `LegacyInvoicePdfController` (`Gate::authorize`), `StripeInvoiceRedirectController` (user_id-Check), Firmen-/Kontakt-Verwaltung vorbildlich.
+- **Policies** mit `before()`-Super-Admin-Kurzschluss und Owner/Firmen-Scoping.
+- **XSS/Purifier:** enges `press_release`-Profil (nur p/br/h2/h3/strong/em/ul/ol/li/blockquote/a, Schemes http/https/mailto/tel — kein `javascript:`), Sanitization **doppelt** (Speichern + Rendern), `renderedText()` als einziger Sink; Legacy-Plaintext `e()`-escaped; `LinkPolicy` erzwingt `rel`.
+- **Bild-Uploads:** inhaltsbasierte MIME-Prüfung, GD-Neukodierung (entfernt Payloads), Extension aus MIME abgeleitet, UUID-Namen, kein SVG.
+- **SQL-Injection:** keine gefunden; `whereRaw`/`selectRaw`/`orderByRaw` durchweg parametrisiert bzw. mit hartkodierten Spaltennamen.
+- **Login-Härtung:** eigenes Throttling 5/min (E-Mail+IP), Passwortprüfung vor Login (kein 2FA-Bypass), Session-Regeneration, Inaktiv-Sperre; Fortify-Limiter gesetzt.
+- **Magic-Link:** Token nur als SHA-256-Hash, atomares Einmal-Einlösen gegen Races (2FA-Umgehung M1 ausgenommen).
+- **Billing-Atomizität:** `InvoiceNumberGenerator` (`insertOrIgnore` + unique + `lockForUpdate`, lückenlos), Wallet-Core (`post()` transaktional + Row-Lock + Negativsaldo-Guard), Webhook-Idempotenz (`mirrorPaidInvoice` dedupt auf `stripe_invoice_id`), Stripe-Webhook-Signatur via Cashier verifiziert.
+- **Mass Assignment:** alle 44 Models mit expliziten `$fillable`-Whitelists, kein `$guarded=[]`, kein `$request->all()` in Persistenz-Pfaden; `forceFill` durchweg hartkodiert (Ausnahme: `is_super_admin` im `$fillable`, M8).
+- **CSRF:** einzige Ausnahme signierte RFC-8058-Abmeldung, Signatur in beiden Handlern geprüft; `verify-email`/`email-aendern` `signed`+`throttle`+auth mit Zusatz-Checks.
+- **Fehlerbehandlung:** keine leeren catch-Blöcke in `app/`; kritische Pfade loggen.
+- **Timezone:** `config/app.php` `Europe/Berlin`, Scheduler + Stripe-Timestamp-Konvertierungen konsistent — kein Mixing-Bug gefunden (Branch-Ziel erfüllt).
+- **Performance-Read-Schicht:** Eager Loading überall, Pagination durchgängig, gezielte Composite-/Fulltext-Indizes, `AppSetting`/`MarketDataService`/`HubPageData`/`Sitemap` gecacht.
+- **Öffentliche Formulare** mit Honeypot + RateLimiter + `throttle`; **BasicAuth** timing-sicher (`hash_equals`).
+- **Testabdeckung** ~176 Dateien, breit über alle kritischen Domänen.
+
+---
+
+## 7. Fix-Protokoll (Umsetzung)
+
+Chronologische Dokumentation der umgesetzten Fixes. Jeder Eintrag nennt Änderung, Begründung und Testnachweis. Alle Tests laufen mit `php artisan test` (Docker/Sail lokal nicht aktiv).
+
+### 2026-07-14 — K1 (Rechteausweitung `editor` → Super-Admin) + M8 (`is_super_admin` mass-assignable) — ✅ behoben
+
+**Problem:** Die User-/Rollen-Verwaltungskomponenten prüften nur das grobe `access-admin`-Gate (schließt `editor` ein), aber nicht die bewusst nur an `admin` vergebenen Permissions `users:manage`/`roles:manage`. Ein `editor` konnte sich `is_super_admin=true` setzen bzw. die Rolle `admin` zuweisen. `is_super_admin` lag zudem im `$fillable`.
+
+**Änderungen:**
+1. `app/Models/User.php` — `is_super_admin` aus `$fillable` entfernt (M8). Wird ab jetzt ausschließlich per autorisiertem `forceFill()` gesetzt.
+2. `app/Providers/AppServiceProvider.php` — zentraler `Gate::before`-Super-Admin-Kurzschluss ergänzt. Damit greifen `can('users:manage')`/`can('roles:manage')` auch für Super-Admins ohne passende Spatie-Rolle (analog zu den Policy-`before()`-Methoden).
+3. Berechtigungsprüfung `authorize('users:manage')` in `mount()` **und** allen Schreibmethoden von `admin/users` (Index `users.blade.php`, `users/create`, `users/edit`, `users/show`); `authorize('roles:manage')` analog in `admin/roles` (`roles/index`, `roles/create`, `roles/edit`). Da `mount()` serverseitig läuft und Livewire-Tests wie HTTP-Requests dagegen prüfen, ist die Sperre sowohl beim initialen Aufruf als auch bei `/livewire/update` wirksam.
+4. `admin/users/edit` + `create` — `is_super_admin` aus dem `update()`/`create()`-Array entfernt und in einen **Super-Admin-only**-`forceFill`-Zweig verschoben: ein Admin mit `users:manage`, der selbst kein Super-Admin ist, kann den Rang nicht (mehr) vergeben.
+5. `app/Services/Import/UserImporter.php` — Import setzt `is_super_admin` jetzt per `forceFill()` (da nicht mehr mass-assignable), Verhalten unverändert.
+6. `resources/views/components/layouts/app/sidebar.blade.php` — Navigation zu Benutzer/Rollen mit `@can('users:manage')`/`@can('roles:manage')` umschlossen (keine 403-Links mehr für Editoren).
+
+**Tests (neu):** `tests/Feature/Admin/AdminPrivilegeEscalationTest.php` (6 Tests): Editor 403 auf allen User-/Rollen-Seiten; Admin 200; Editor kann Rollen-Komponente nicht mounten; Nicht-Super-Admin kann `is_super_admin` nicht vergeben; Super-Admin kann es; `is_super_admin` nicht mass-assignable.
+**Tests (angepasst):** `tests/Feature/Admin/UserImpersonationTest.php` — „editor cannot start impersonation" prüft jetzt die stärkere Sperre auf Seiten-Ebene (403 auf `/admin/users`).
+**Ergebnis:** `tests/Feature/Admin` + `tests/Feature/Auth` = **201 passed**; Pint sauber.
+
+### 2026-07-14 — H1 (Impersonation ohne Rangprüfung) — ✅ behoben
+
+**Problem:** `canBeImpersonated()` erlaubte jedes Ziel mit Kundenzugriff, inkl. Super-Admins. Ein Admin (`users:manage`, kein Super-Admin) konnte einen Super-Admin übernehmen und in dessen Namen persistente API-Token erzeugen.
+
+**Präzisierung des Audit-Vorschlags:** Ein bestehender Test (`admin can impersonate accounts with admin access`) belegt, dass Admin→Admin/Editor-Impersonation **gewollt** ist. Ein pauschales Blockieren aller Admin-Ziele wäre also falsch. Der tatsächliche Eskalationspfad ist enger: **nach oben** (auf einen Super-Admin). Fix daher als gezielte Rangprüfung.
+
+**Änderungen:** `app/Actions/Admin/UserImpersonation.php` — neue Methode `mayImpersonateRank(admin, target)`: `admin->is_super_admin || ! target->is_super_admin`. Erzwungen in `canStart()` (UI-Gate) **und** `start()` (Server-Enforcement, wirft `AuthorizationException`). Admin→Admin/Editor bleibt erlaubt; nur Nicht-Super-Admin→Super-Admin ist gesperrt.
+
+**Tests (neu):** `UserImpersonationTest.php` — „non super admin cannot impersonate a super admin" (403) und „super admin can impersonate another super admin" (erlaubt).
+**Ergebnis:** `UserImpersonationTest` **7 passed**.
+
+### 2026-07-14 — H3 (Stored-XSS via `page_url`) — ✅ behoben
+
+**Problem:** `page_url` aus dem anonymen Kontaktformular war nur als `string` validiert und wurde im Admin-Backend als klickbarer `` gerendert → `javascript:`-URI lief beim Admin-Klick im Admin-Kontext.
+
+**Änderungen:**
+1. `app/Http/Controllers/Web/ContactController.php` — Regel auf `['nullable', 'url:http,https', 'max:500']` verschärft. Das Feld wird per JS mit der echten Seiten-URL befüllt, daher keine Einschränkung für legitime Submissions.
+2. `resources/views/livewire/admin/contact-messages/show.blade.php` — Render-Guard: Link nur bei `http(s)`-Präfix, sonst als reiner Text (Defense-in-depth für Bestandsdaten).
+
+**Tests (neu):** `tests/Feature/Web/ContactFormTest.php` — „a javascript page_url is rejected (stored XSS guard)": `javascript:`-URL → 422, kein `ContactMessage`, keine Mail.
+**Ergebnis:** `ContactFormTest` **16 passed**.
+
+### 2026-07-14 — H4 (Doppel-Gutschrift bei Stripe-Webhook-Retry) — ✅ behoben
+
+**Problem:** Der Idempotenz-Guard (`credited_at !== null`) lag **außerhalb** der Transaktion ohne Row-Lock. Zwei at-least-once-Zustellungen, die die Zeile vor der ersten Gutschrift laden, konnten beide gutschreiben (echtes Geld doppelt).
+
+**Änderungen:** `app/Services/Billing/CreditTopupService::fulfill()` — Guard **in** die Transaktion verschoben und die Topup-Zeile per `lockForUpdate()` gesperrt (analog zum bereits vorhandenen Wallet-`post()`). Erst nach dem Lock wird `credited_at` geprüft; parallele Aufrufe serialisieren. (SQLite ignoriert `FOR UPDATE`; der Guard-in-Transaktion ist dennoch testbar und für MySQL-Produktion korrekt.)
+
+**Tests (neu):** `tests/Feature/CreditTopupTest.php` — „two concurrent webhook deliveries credit the wallet only once": zwei separate, vor der Gutschrift geladene Instanzen → nur 1 Credit-Transaktion, Saldo einmal. (Dieser Test schlägt auf dem alten Code fehl.)
+**Ergebnis:** `CreditTopupTest` **8 passed**; gesamte `tests/Feature/Billing` **176 passed**.
+
+### 2026-07-14 — H5 (Host-Header-Injection) — ✅ behoben
+
+**Problem:** `trustProxies(at:'*')` inkl. `X-Forwarded-Host` ohne Host-Whitelist → Client kann den für URL-Generierung genutzten Host setzen.
+
+**Änderungen:** `bootstrap/app.php` — `->trustHosts()` mit einer Closure ergänzt, die aus `config('domains.domain_portal|presseecho|businessportal')` ankergebundene Host-Patterns (`^(.+\.)?host$`) baut. Fremde Host-Header werden verworfen.
+
+**Verifikation:** Laravel erzwingt Trusted Hosts konstruktionsbedingt **nur außerhalb** von `local`/Unit-Tests (`TrustHosts::shouldSpecifyTrustedHosts()`), daher greift der Schutz in Produktion, ohne die Multi-Host-Testsuite zu brechen. App-Boot mit der neuen Closure verifiziert; `tests/Feature/Web` **228 passed** (unverändert).
+
+### 2026-07-14 — M1 (Magic-Link umgeht 2FA) — ✅ behoben
+
+**Problem:** `MagicLinkConsumeController` loggte direkt ein und übersprang aktiviertes 2FA.
+
+**Änderungen:** `app/Http/Controllers/Auth/MagicLinkConsumeController.php` — bei `hasEnabledTwoFactorAuthentication()` wird nun (wie im Passwort-Login) `login.id`/`login.remember` in die Session gelegt und auf `two-factor.challenge` umgeleitet, statt einzuloggen. Der Link ist bereits atomar verbraucht (Einmal-Nutzung bleibt).
+
+**Tests (neu):** `tests/Feature/Auth/MagicLinkLoginTest.php` — „magic link login with two-factor enabled is handed to the challenge": Redirect auf Challenge, Gast-Status, `login.id` gesetzt, Link verbraucht.
+**Ergebnis:** `MagicLinkLoginTest` + `TwoFactorLoginTest` **19 passed**.
+
+### 2026-07-14 — M6 (API-Text ungefiltert gespeichert) — ✅ behoben
+
+**Problem:** `store()`/`update()` der V1-API speicherten `text` ungefiltert (Web-Pfade sanitizen über `PressReleaseHtmlSanitizer`).
+
+**Änderungen:** `app/Http/Controllers/Api/V1/PressReleaseController.php` — neuer Helper `sanitizeHtmlText()`, aufgerufen in `store()` und `update()`. Sanitisiert HTML per HTMLPurifier (`clean()`), lässt aber Legacy-Plaintext unangetastet (nur wenn `isHtml()`), analog zum `render()`-Vertrag — so werden `<`/`&` in Klartext-Einreichungen nicht zerstört.
+
+**Tests (neu):** `tests/Feature/Api/V1/PressReleaseApiTest.php` — „api submitted html text is sanitized before persistence": `