Affiliate-Toolkit 3.8.6: Warum wir das Template-Rendering geändert haben

Mit Version 3.8.6 des affiliate-toolkit haben wir eine sicherheitsrelevante Änderung am Template-Rendering eingeführt. Da diese Änderung bestehende Installationen betreffen kann und im Changelog nicht prominent genug kommuniziert wurde, fassen wir hier den Hintergrund, die Auswirkungen und die nötigen Schritte zusammen.

Was sich geändert hat

Ab Version 3.8.6 wird reiner PHP-Code – also alles innerhalb von <?php … ?>-Blöcken – vor dem Blade-Rendering automatisch aus den Templates entfernt und nicht mehr ausgeführt. Erlaubt ist ausschließlich die Blade-Vorlagensyntax.

Warum wir das gemacht haben

Das affiliate-toolkit wurde vom WordPress.org Plugin Review Team wegen einer Sicherheitslücke vorübergehend aus dem Plugin-Directory entfernt. Die Möglichkeit, beliebigen PHP-Code über Templates auszuführen, war Teil des Problems.

Die Sanitization in 3.8.6 ist der Fix, der das Plugin wieder in das Directory zurückgebracht hat. Diese Änderung war nicht optional – ohne sie wäre das Plugin aktuell nicht mehr offiziell verfügbar.

Wen das betrifft

Wer ausschließlich mit den Standard-Templates und Standard-Ausgaben arbeitet, muss in der Regel nichts tun. Betroffen sind Installationen mit eigenen Templates oder Snippets, die PHP-Code enthalten – etwa für individuelle Produktboxen, Offer-Listen oder AJAX-Ausgaben. In diesen Fällen können Ausgaben unvollständig oder leer sein, bis die Templates umgestellt sind.

Typische Symptome:

• Produktboxen bleiben leer
• More-Offers oder Detail-Offers werden nicht mehr angezeigt
• AJAX-basierte Produktanzeigen laden keine Daten
• Eigene Snippets brechen ohne sichtbare Fehlermeldung

Migration auf Blade-Syntax

Die häufigsten Konstrukte lassen sich 1:1 ersetzen:

<?php echo $var; ?>                   →  {{ $var }}
<?php if (...): ?> … <?php endif; ?>  →  @if(...) … @endif
<?php foreach (...): ?> … endforeach  →  @foreach(...) … @endforeach
<?php echo esc_html($x); ?>           →  {{ $x }}        (escaping ist Default)
<?php echo $raw; ?>                   →  {!! $raw !!}    (unescaped, nur bei vertrauenswürdiger Quelle)

Für Fälle, in denen Blade nicht ausreicht – etwa eigene Helper-Funktionen, komplexere Berechnungen oder externe API-Aufrufe – ist der vorgesehene Weg ein eigener Filter oder Hook in einem Child-Plugin oder im Theme, nicht PHP direkt im Template.

Warum der kursierende Hotfix keine Lösung ist

Im Support-Forum kursiert ein Hotfix, der die Sanitization durch Auskommentieren einer einzelnen Zeile (self::sanitize_template_content()) deaktiviert. Davon raten wir ausdrücklich ab.

Wer das macht, öffnet die ursprüngliche Sicherheitslücke auf seiner Installation wieder vollständig. Damit lässt sich über Template-Inhalte – auch indirekt, etwa über importierte oder geteilte Templates – beliebiger PHP-Code ausführen. Das ist kein theoretisches Risiko, sondern genau der Grund, warum das Plugin gesperrt war.

Wer den Hotfix einsetzt, übernimmt die volle Verantwortung für die daraus entstehenden Sicherheitsrisiken auf seiner Seite.

Was wir besser machen

Eine Änderung mit derartigen Auswirkungen auf bestehende Templates hätte prominent im Changelog stehen müssen und nicht nur als Hinweis im Template-Editor. Das war ein Kommunikationsfehler, für den wir uns bei allen betroffenen Nutzern entschuldigen. Für künftige Sicherheits-Releases stellen wir die Release-Kommunikation entsprechend um.