TP49 angelegt: CF-Access-Wildcard oeffnet alle internen Dienste fuer jeden GitHub/Google-User

Fund vom 2026-07-10, seither unbehoben — stand nur in der Memory project_cf_tunnel_1033,
in keiner TP-Liste. Beim Sichern der Memories wiederentdeckt.

login_method:<idp> als include matcht JEDEN via diesen IdP, nicht den Owner. Betroffen
sind alle Dienste hinter *.emsenhuber.net (hass/grafana/portainer/pve). Gitea #76.

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/teilprojekte.md

@@ -2576,3 +2576,49 @@ uns verfranzen. Geli kommt rein, das zählt."* — Diese Prämisse fiel weg: `42
 public CF-Worker hinter CF Access (löst auf CF-Anycast), kein BF-Origin ⇒ dafür braucht es kein
 Split-Horizon; Zugang via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Der Override-Bedarf für
 **interne** Namen blieb dabei übersehen — deshalb reopened, s.o.
+
+<a id="tp49"></a>
+### TP49  ·  Gitea #76 — CF-Access: Wildcard-Policy öffnet alle internen Dienste für jeden GitHub/Google-User ▸ 🔴 ABSOLUTE PRIORITÄT
+
+*(Angelegt 2026-10-06 auf Christoph-Direktive. Fund stammt vom 2026-07-10 und stand seither
+unbehoben in der Memory `project_cf_tunnel_1033` — beim Sichern der Memories wiederentdeckt.)*
+
+#### Der Befund (2026-07-10, nie behoben)
+Eine Policy am CF-Access-Wildcard `*.emsenhuber.net` (App `16aaec78`) trägt
+`login_method:github` und `login_method:google` **als include**. Das ist ein Denkfehler mit
+Wirkung nach außen: 🔴 **`login_method:<idp>` matcht JEDEN, der sich über diesen IdP anmeldet —
+nicht nur den Owner.** Ein beliebiger GitHub- oder Google-Account kommt damit durch.
+
+Betroffen sind **alle Dienste hinter dem Wildcard**: `hass`, `grafana`, `portainer`, `pve` u.a. —
+also Smart-Home (inkl. Presence/Türen), Container-Control und Hypervisor-Management.
+
+#### Warum es so lange offen blieb
+Der Befund war als „offen, user-gated" markiert und wurde bewusst nicht einseitig geändert
+(Aussperr-Risiko). Er stand danach nur in einem Session-Memory und in keiner TP-Liste — beim
+Aufräumen der Memories am 2026-10-06 kam er wieder hoch.
+
+#### Erster Schritt: messen, nicht annehmen
+1. `GET /accounts/{id}/access/apps` → existiert `16aaec78` noch?
+2. `GET …/access/apps/{id}/policies` → welche `include`-Regeln, welche `login_method`-Einträge?
+3. **Sweep über ALLE Apps** — gibt es weitere Policies mit `login_method:<idp>`?
+4. Existiert der reusable Bypass `a8129e37` noch? (Am 2026-07-10 detacht, **nicht** gelöscht.)
+
+#### Fix (falls bestätigt)
+`login_method:*` aus den Includes entfernen; Zugang über `email:…` der tatsächlichen Personen.
+⚠️ Vorher abstimmen, wer Zugang braucht — sonst sperrt man sich aus.
+
+#### Gotchas (spart Suchzeit)
+- Reusable Policy nur per **App-PUT** (`policies:[{id,precedence}]`) detachbar — **nicht** via
+  `/policies`-DELETE („can not delete reusable policies").
+- Policy-`precedence` muss **eindeutig** sein (Kollision mit Bypass = 1).
+- Writes nur via `CF_API_TOKEN`/curl; der `cloudflare`-MCP (OAuth) ist **read-only**.
+  ⚠️ Token-Status vor Schreibaktionen live prüfen — `CF_API_TOKEN` galt am 2026-09-07 als ungültig
+  (401), `CF_DNS_API_TOKEN` ist gültig, hat aber nur `DNS:Edit`.
+
+#### Abgrenzung
+**Nicht** TP41 (CF-Access-Reparatur, abgeschlossen) — das war der Auth-Kern; dies ist ein
+inhaltlicher Policy-Fehler, der dabei übersehen wurde. **Nicht** TP44 (CF-Estate in Nautobot) —
+Dokumentation, nicht Berechtigung. Verwandt: TP46 (#72).
+
+**→ Abschluss, wenn alle Apps auf `login_method`-Includes geprüft und die betroffenen Policies
+auf `email:`-Includes umgestellt sind.**