| Plugin-Name | Beitrag-Flagger |
|---|---|
| Art der Schwachstelle | Cross-Site-Scripting (XSS) |
| CVE-Nummer | CVE-2026-1854 |
| Dringlichkeit | Niedrig |
| CVE-Veröffentlichungsdatum | 2026-03-23 |
| Quell-URL | CVE-2026-1854 |
Authentifizierter Mitwirkender gespeichertes XSS im Post Flagger (<=1.1): Risiko, Erkennung und schnelle Minderung
Eine kürzlich offengelegte Schwachstelle betrifft das Post Flagger WordPress-Plugin (Versionen <= 1.1): Ein authentifizierter Mitwirkender kann eine bösartige Nutzlast im Attribut “slug” des Shortcodes des Plugins erstellen und speichern, die später im Kontext des Browsers eines Seitenbesuchers oder Administrators gerendert und ausgeführt wird (gespeichertes Cross-Site Scripting / XSS). Das Problem wurde mit CVE-2026-1854 versehen und hat eine CVSS-ähnliche Bewertung in öffentlichen Berichten (6.5), hauptsächlich weil es sich um ein gespeichertes XSS mit begrenzten, aber realen Ausnutzungswegen und Anforderungen an die Benutzerinteraktion handelt.
Als das Team hinter WP-Firewall bewerten, triagieren und reagieren wir jede Woche auf diese Art von Plugin-Schwachstellen. Unten finden Sie eine praktische, entwicklerfreundliche und betriebsorientierte Aufschlüsselung: was das Problem ist, wie ein Angreifer es missbrauchen könnte, wie Sie erkennen können, ob Ihre Seite betroffen ist, und konkrete Schritte zur Minderung – sowohl sofort als auch dauerhaft. Wenn Sie für eine oder mehrere WordPress-Seiten verantwortlich sind, speichern Sie diesen Leitfaden.
Kurze Zusammenfassung (was passiert ist)
- Plugin: Post Flagger (WordPress-Plugin)
- Betroffene Versionen: <= 1.1
- Schwachstelle: Gespeichertes Cross-Site Scripting (XSS) über das Attribut des Shortcodes
slug - Erforderliches Privileg: Authentifizierter Mitwirkender (oder höher)
- Auswirkungen: Gespeichertes XSS, das im Browser ausgeführt wird, wenn es gerendert wird (Besucher oder höher privilegierte Benutzer können Ziel sein). Kann für Sitzungsdiebstahl, persistente Verunstaltung oder Social Engineering gegen Administratoren verwendet werden.
- CVE: CVE-2026-1854
- Sofortige Maßnahme: Plugin aktualisieren, wenn eine gepatchte Version verfügbar ist. Wenn Sie nicht aktualisieren können, wenden Sie kurzfristige Minderung an (detailliert unten).
Warum gespeichertes XSS in WordPress wichtig ist
Gespeichertes XSS ist gefährlich, weil die bösartige Nutzlast auf dem Server (in der Datenbank, im Beitragsinhalt oder in den Plugin-Metadaten) gespeichert wird und später anderen Benutzern bereitgestellt wird. WordPress-Seiten sind ein hochgradiges Ziel, da es mehrere Arten von Benutzern gibt (Administratoren, Redakteure, Mitwirkende, Abonnenten). Selbst wenn eine Schwachstelle ein Mitwirkenden-Konto erfordert, um die Nutzlast zu platzieren, ist das keine geringfügige Anforderung: Viele Seiten akzeptieren Beiträge von Autoren, Gastautoren und redaktionellen Assistenten – Konten, die die Rolle des Mitwirkenden haben könnten.
Angreifer nutzen gespeichertes XSS, um:
- Authentifizierungscookies oder -tokens von privilegierten Benutzern zu stehlen (Sitzungshijacking).
- Aktionen im Kontext eines Administrators auszuführen (CSRF-ähnliches Ketten).
- Hintertüren zu installieren (indem sie einen Administrator überzeugen, auf etwas zu klicken).
- Persistenten Spam oder bösartiges JavaScript einzuschleusen, das Suchmaschinen/Besucher betrifft.
Da Shortcodes ein Rendering-Mechanismus sind, der oft HTML oder JS ausgibt, sind nicht vertrauenswürdige Shortcode-Attribute eine häufige Risikofquelle, wenn sie vor der Ausgabe nicht bereinigt werden.
Technische Details (hochgradig, verantwortlich)
Der Kern des Problems ist, dass ein von dem Post Flagger-Plugin implementierter Shortcode ein slug Attribut akzeptiert, das bei der Ausgabe nicht ordnungsgemäß bereinigt oder escaped wird. Ein Angreifer mit einem Mitwirkenden-Konto kann Inhalte erstellen oder bearbeiten (z. B. einen Beitrag, einen Kommentar oder wo immer dieser Shortcode eingefügt werden kann) und ein manipuliertes slug Attribut mit HTML/JS einfügen. Wenn dieser Shortcode später gerendert wird (zum Beispiel in Admin-Vorschauen, Front-End-Seiten oder Widgets), wird die Nutzlast ohne ausreichende Kodierung in die Seite ausgegeben und wird im Browser des Opfers ausgeführt.
Typische Verwundbarkeitskette:
- Mitwirkender erstellt Inhalte mit einem Shortcode wie:
[post_flagger slug=""] - Das Plugin speichert das Shortcode-Attribut (oder den abgeleiteten Wert) in der Datenbank, ohne es für HTML/JS zu bereinigen.
- Wenn der Inhalt gerendert wird, gibt das Plugin das Slug-Attribut in HTML aus, ohne es zu escapen (oder erlaubt HTML durch
wp_ksesfehlerhaft). - Browser interpretieren das injizierte JS und führen es im Ursprung der Seite aus.
Hinweis: Die genauen Datei-, Funktions- und Zeilennummern variieren je nach Plugin-Version. Das Problem resultiert aus unzureichender Eingabebereinigung und/oder unsicherer Ausgabekodierung.
Ausnutzungsszenarien (realistisch)
- Szenario A: Mitwirkender platziert die Nutzlast in einem Beitrag; ein Redakteur oder Administrator öffnet den Beitrag im Admin-Editor oder in der Vorschau und das gespeicherte Skript wird in ihrem Browser ausgeführt. Von dort aus kann der Angreifer versuchen, Auth-Cookies zu exfiltrieren oder Aktionen mit der Sitzung des Administrators durchzuführen.
- Szenario B: Mitwirkender platziert die Nutzlast in Inhalten, die für die Besucher der Seite sichtbar sind. Wenn Besucher die Seite durchsuchen, wird das Skript ausgeführt und kann stillschweigend umleiten, bösartige Inhalte anzeigen oder versuchen, Besucher zu fingerprinten.
- Szenario C: Nutzlast verwendet für Social Engineering: eine gefälschte Admin-Benachrichtigung oder ein Modal anzeigen, um privilegierte Benutzer dazu zu bringen, auf eine Aktion zu klicken (z. B. “Klicken Sie zur Genehmigung”, die eine kostspielige oder zerstörerische Operation auslöst).
Der Exploit erfordert, dass ein Angreifer Inhalte erstellt oder bearbeitet (Mitwirkender) und beruht typischerweise auch darauf, dass ein anderer Benutzer die infizierte Seite ansieht oder eine Vorschau öffnet. Stored XSS wird oft in mehrstufigen Angriffen weaponisiert.
Wie man überprüft, ob Ihre Seite anfällig oder bereits kompromittiert ist
- Überprüfen, ob Post Flagger installiert und aktiv ist:
- In WP Admin → Plugins, überprüfen Sie den Plugin-Namen und die Version.
- Durchsuchen Sie Beiträge, Auszüge und Metadaten nach verdächtiger Verwendung von Shortcodes:
- Verwenden Sie die Datenbank: Suchen Sie nach “[post_flagger” oder dem Shortcode-Namen.
- Beispiel WP‑CLI:
wp search-replace '\[post_flagger' '\[post_flagger' --all-tables --precise --include-columns=post_content
Oder eine sicherere schreibgeschützte Auflistung:
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[post_flagger%';"
- Überprüfen Sie die
slugAttributinhalte für HTML-Tags oder Ereignis-Handler:- Suchen
<script>,<img onerror=,<svg onload=,Javascript:,</, oder spitze Klammern.
- Suchen
- Überprüfen Sie Revisionen für Beiträge, die kürzlich von Konten von Mitwirkenden erstellt/bearbeitet wurden.
- Überprüfen Sie die Zugriffsprotokolle und Admin-Logins zu Zeiten, als möglicherweise verdächtige Beiträge veröffentlicht/vorgestellt wurden.
- Führen Sie einen umfassenden Sicherheits-Scan der Website (Malware-Scanner, XSS-Scanner) durch, um injizierte Skripte zu erkennen.
Wenn Sie verdächtige Einträge finden, behandeln Sie diese als potenziell bösartig und folgen Sie den untenstehenden Schritten zur Vorfallreaktion.
Sofortige Maßnahmen (was jetzt zu tun ist)
Wenn Sie eine Website mit aktivem Post Flagger <= 1.1 verwalten, tun Sie Folgendes sofort:
- Aktualisieren Sie das Plugin, wenn eine gepatchte Version verfügbar ist.
- Wenn kein Patch verfügbar ist oder Sie nicht sicher aktualisieren können:
- Deaktivieren Sie das Plugin sofort.
- Oder entfernen Sie vorübergehend den Shortcode-Handler, damit gespeicherte Shortcodes nicht gerendert werden:
// Fügen Sie dies der functions.php Ihres Themes oder einem kleinen mu-Plugin hinzu;
- Beschränken Sie die Berechtigungen von Mitwirkenden und Autoren:
- Fördern Sie vorübergehend die manuelle Überprüfung von Beiträgen von Mitwirkenden, bevor Vorschauen erlaubt sind.
- Oder deaktivieren Sie vorübergehend die Vorschaufunktion auf der Front-End-Seite mithilfe eines Rollen-/Berechtigungs-Plugins oder Codes.
- Blockieren oder filtern Sie bösartige Eingaben mit einer Web Application Firewall (WAF):
- Fügen Sie eine Regel hinzu, um zu blockieren
slugAttribute, die enthalten<,>,Javascript:, oderon\w+=. - Beispiel ModSecurity-ähnliche Regel (konzeptionell):
SecRule REQUEST_BODY "@rx \[post_flagger.*slug=.*(|javascript:|on[a-z]+=)" \" - Wenn Sie eine verwaltete WAF betreiben, bitten Sie Ihren Anbieter, die Regel für Ihre Website virtuell zu patchen.
- Fügen Sie eine Regel hinzu, um zu blockieren
- Scannen Sie die DB und entfernen Sie verdächtige Einträge:
- Suchen Sie nach dem Shortcode und überprüfen Sie
slugAttribute. Wenn sie bösartig sind, entfernen oder bereinigen Sie sie. - Stellen Sie sicher, dass Sie Sicherungen haben, bevor Sie den DB-Inhalt ändern.
- Suchen Sie nach dem Shortcode und überprüfen Sie
- Ändern Sie Passwörter und machen Sie die Sitzungen von Admin-/Editor-Benutzern ungültig, von denen Sie vermuten, dass sie möglicherweise kompromittiert wurden.
- Versetzen Sie die Website in den Wartungsmodus, wenn Sie während der Behebung eine aktive Ausnutzung vermuten.
Diese Maßnahmen verringern das Risiko weiterer Kompromittierungen, während Sie eine langfristige Lösung implementieren.
Empfohlene dauerhafte Lösungen (für Website-Besitzer und Plugin-Autoren)
Website-Besitzer:
- Halten Sie Plugins aktuell und entfernen Sie ungenutzte Plugins.
- Durchsetzen des Prinzips der minimalen Berechtigung: Begrenzen Sie die Konten von Mitwirkenden, wenden Sie Zwei-Faktor-Authentifizierung für Redakteure/Administratoren an.
- Verwenden Sie eine WAF mit virtuellem Patchen, wenn ein Plugin-Patch verzögert wird.
Plugin-Autoren (Entwickler-Checkliste):
- Bereinigen Sie Eingaben so schnell wie möglich.
$slug = isset($atts['slug']) ? sanitize_text_field($atts['slug']) : '';
- Validieren Sie gegen erwartete Muster. Wenn der Slug nur alphanumerisch sein sollte, validieren Sie mit einer Whitelist:
if ( ! preg_match('/^[a-z0-9-]+$/', $slug) ) { - Entkommen Sie bei der Ausgabe:
- Beim Ausgeben in HTML-Attribute:
echo esc_attr( $slug ); - Für die Ausgabe im Inhaltsbereich:
echo esc_html( $safe_text );
- Beim Ausgeben in HTML-Attribute:
- Vermeiden Sie es, Benutzereingaben direkt auszugeben. Verwenden Sie
wp_kses()oder andere kontrollierte HTML-Whitelist nur wenn nötig. - Stellen Sie sicher, dass Shortcodes nicht in unsicheren Kontexten ohne Zugriffsprüfungen oder Bereinigung aufgerufen werden.
- Führen Sie Unit-Tests zur Handhabung von Shortcodes mit bösartigen Eingabewerten durch (Attribute, die Tags, Ereignis-Handler, javascript: URIs enthalten).
- Berücksichtigen Sie beim Rendern immer den Kontext: Attribut, HTML-Body, JS-String, URL — verwenden Sie die richtige Escape-Funktion.
Die Befolgung dieser Regeln wird die Klasse von Sicherheitsanfälligkeiten schließen, die zu dem hier beschriebenen XSS geführt haben.
Erkennungssignaturen und Protokollprüfungen (praktische Suchmuster)
Bei der Suche nach gespeichertem XSS auf einer WordPress-Seite sind nützliche Artefakte:
- Datenbankabfragen:
- Suchen
wp_posts.post_contentUndwp_postmeta.meta_value:SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[post_flagger%';
- Suchen
- Suchen Sie nach HTML-Tags innerhalb von Shortcode-Attributen:
- Regex-Indikatoren:
<script,onerror=,onload=,Javascript:,<svg,<img,</script>.
- Regex-Indikatoren:
- Webserver-Protokolle:
- Suchen Sie nach ungewöhnlichen POST-Anfragen von Mitwirkenden, die verdächtige Payloads enthalten.
- Browser-Konsole-Fehler und injizierte Inline-Skripte, die von Ihrer Domain bereitgestellt werden.
- WAF-Protokolle:
- Blockierte Anfragen, die enthalten
<oderon\w+=in Formularfeldern, die auf dieslugShortcode-Attribut.
- Blockierte Anfragen, die enthalten
Sammeln und bewahren Sie Beweise, wenn Sie eine Ausbeutung vermuten.
Vorgeschlagene WAF/virtuelle Patch-Muster (Beispielregeln)
Wenn Sie eine WAF betreiben oder kontrollieren, kann das virtuelle Patchen ein Lebensretter sein, bis ein Plugin-Update verfügbar ist. Die zentrale Idee: blockieren oder bereinigen Sie Payloads, die HTML/JS enthalten, wenn sie verwendet werden in der slug Attribut.
Beispielhafte konzeptionelle Regeln (fügen Sie ungetestete Regeln nicht direkt in die Produktion ein — passen Sie sie an Ihre Plattform an):
- Blockieren Sie verdächtige Zeichen im ‘slug’-Parameter (generische Pseudo-Regel):
wenn request_body enthält "[post_flagger" UND request_body entspricht "slug=.*(|javascript:|on[a-z]+=)" dann blockieren
- Entfernen Sie spitze Klammern aus Slug-Werten:
- Aktion: bereinigen Sie den Anfragekörper, indem Sie
<Und>InslugWerte durch URL-kodierte Äquivalente ersetzen (oder die Anfrage ablehnen).
- Aktion: bereinigen Sie den Anfragekörper, indem Sie
- Normalisieren und durchsetzen des erlaubten Musters:
- Wenn
slugentspricht nicht/^[a-z0-9-]+$/idann protokollieren und blockieren.
- Wenn
Anmerkungen:
- WAF-Regeln sollten gezielt und getestet werden, um Fehlalarme zu vermeiden.
- Verwenden Sie die WAF, um eine 403 mit einer hilfreichen Nachricht an die Site-Redakteure zurückzugeben (z. B. “Ihre Einreichung enthält ungültige Zeichen und wurde zur Sicherheitsüberprüfung blockiert”).
Neutralisierung des Shortcodes auf Ihrer Website (Beispiel mu-Plugin)
Wenn Sie das Plugin nicht sicher aktualisieren können, neutralisieren Sie den Shortcode, um das Rendern zu verhindern:
- Erstellen Sie eine mu-Plugin-Datei:
wp-content/mu-plugins/neutralize-postflagger.php - Inhalte:
<?php;
- Dies verhindert das Rendern von gespeichertem XSS auf Seiten, während der DB-Inhalt für eine spätere Bereinigung erhalten bleibt.
Vorfallreaktions-Checkliste (wenn Sie Angreiferaktivitäten feststellen)
- Versetzen Sie die Website in den Wartungsmodus (kurz), wenn eine Live-Ausnutzung stattfindet.
- Machen Sie einen Snapshot/Backup der Website und der DB für forensische Analysen.
- Identifizieren und isolieren Sie bösartige Beiträge oder Postmeta-Einträge.
- Neutralisieren Sie das Rendern (siehe mu-Plugin oben) und wenden Sie WAF-Regeln an, um weitere Einreichungen zu blockieren.
- Entfernen oder bereinigen Sie bösartige gespeicherte Payloads (Änderungen auf sichere, prüfbare Weise vornehmen).
- Ändern Sie die Passwörter für alle Admin-/Editor-Konten, entfernen Sie unbekannte Benutzerkonten und erzwingen Sie eine Passwortzurücksetzung für alle Benutzer mit hohen Rechten.
- Ungültig machen von Sitzungen und Tokens (z. B. Salze in wp-config.php ändern, wenn Sie Cookie-Diebstahl vermuten).
- Scannen Sie die Website-Dateien nach Webshells, unerwarteten geplanten Aufgaben (Cron-Einträge) oder modifizierten Kern-Dateien.
- Überwachen Sie Protokolle auf Exfiltrationsversuche oder verdächtige ausgehende Verbindungen von der Website.
- Nach der Bereinigung den normalen Betrieb wieder aktivieren und den Vorfall sowie die Maßnahmen dokumentieren.
- Ziehen Sie ein Sicherheitsaudit oder eine professionelle Überprüfung in Betracht, wenn die Website sensible Benutzerdaten speichert.
Empfehlungen zur Härtung zur Reduzierung zukünftiger Risiken
- Minimieren Sie Plugins und entfernen Sie alle, die nicht verwendet werden; jedes Plugin erhöht die Angriffsfläche.
- Beschränken Sie, wer Plugins installieren oder aktivieren kann (nur Website-Besitzer).
- Erzwingen Sie 2FA für alle Administrator- und Editorkonten.
- Halten Sie regelmäßige Backups und überprüfen Sie die Wiederherstellungsprozesse.
- Verwenden Sie eine proaktive WAF, die sowohl virtuelle Patches als auch maßgeschneiderte Filter bietet.
- Führen Sie regelmäßige automatisierte Sicherheitsüberprüfungen und manuelle Überprüfungen für risikobehaftete Plugin-Updates durch.
- Übernehmen Sie eine Staging-/Testumgebung für Plugin-Updates; testen Sie auf Sicherheitsrückschritte.
Entwicklerleitfaden: sichere Shortcode-Muster
Wenn Sie Shortcodes erstellen, folgen Sie diesem Muster:
- Erwarten Sie nicht vertrauenswürdige Eingaben. Bereinigen und validieren Sie frühzeitig.
- Bestimmen Sie den erlaubten Zeichensatz für Attribute. Für Slugs: nur Buchstaben, Zahlen, Bindestriche erlauben.
- Verwenden Sie die Bereinigungsfunktionen von WordPress:
- Eingabe:
Textfeld bereinigen (),sanitize_title() bereinigt haben - Ausgabe:
esc_attr(),esc_html(),wp_kses_post()(nur wenn Sie HTML ausdrücklich erlauben)
- Eingabe:
- Beispiel für einen minimalen sicheren Handler:
function my_plugin_post_flagger_shortcode($atts) {'<div class="post-flagger" data-slug="' . esc_attr( $slug ) . '"></div>';
Wie WP‑Firewall hilft (unsere Sicherheits-Perspektive)
Als WordPress-Firewall- und Sicherheitsdienstanbieter umfasst unser Ansatz für Schwachstellen wie diese:
- Kontinuierliche Überwachung öffentlicher Schwachstellendiskussionen (CVE, Sicherheitsforschung).
- Schnelle Erstellung und Bereitstellung von virtuellen Patch-WAF-Regeln, die auf den Angriffsvektor abzielen (Shortcode-Attribut-Injektionsmuster).
- Standortscans und Erkennungsregeln, um gespeicherte Payloads und verdächtige Shortcode-Vorkommen zu finden.
- Verwaltete Vorfallreaktionsleitfäden und automatisierte Minderungsvorlagen (mu-Plugins, Regelsets), die Kunden sofort anwenden können.
- Laufende Empfehlungen zur Härtung der Website und Leitfäden zu Rollen/Fähigkeiten, um die Wahrscheinlichkeit ähnlicher Angriffe zu verringern.
Wenn Sie auf beigetragenen Inhalt angewiesen sind oder mehrere nicht vertrauenswürdige Redakteure/Beitragsleistende zulassen, empfehlen wir eine mehrschichtige Schutzstrategie: Härtung auf Host-Ebene + eine Anwendungs-WAF + regelmäßige Scans.
Beginnen Sie mit stärkeren Abwehrmaßnahmen: Probieren Sie den kostenlosen WP‑Firewall-Plan aus
Wir möchten es jedem WordPress-Seiteninhaber erleichtern, sofort einen Basisschutz zu erhalten. WP‑Firewall bietet einen kostenlosen Basisplan an, der wesentliche Schutzmaßnahmen umfasst: eine verwaltete Firewall, unbegrenzte Bandbreite, eine Webanwendungsfirewall (WAF), einen Malware-Scanner und Minderung für die OWASP Top 10-Risiken. Wenn Sie einfachen, sofortigen Schutz und die Möglichkeit wünschen, virtuelles Patchen und Scannen hinzuzufügen, ohne den Code zu ändern oder auf Plugin-Updates zu warten, probieren Sie noch heute den kostenlosen Plan aus:
Beginnen Sie mit dem WP‑Firewall Basic (Kostenlos) Plan
Für Teams und Agenturen bieten wir auch erschwingliche Standard- und Pro-Pläne mit automatischer Malware-Entfernung, IP-Whitelist/Blacklist, monatlichen Sicherheitsberichten und automatisiertem virtuellen Patchen an, um Ihre Seiten zu schützen, selbst wenn Drittanbieter-Plugins ungepatchte Sicherheitsanfälligkeiten aufweisen.
Abschließende Hinweise und empfohlene nächste Schritte
- Überprüfen Sie sofort, ob Post Flagger installiert ist und welche Version Sie verwenden.
- Priorisieren Sie die Behebung: Aktualisieren, wenn möglich; andernfalls neutralisieren Sie die Darstellung und wenden Sie WAF-Regeln an.
- Durchsuchen Sie Ihre Datenbank nach gespeicherten Instanzen des Shortcodes und entfernen oder bereinigen Sie verdächtige Einträge.
- Härten Sie die Arbeitsabläufe der Mitwirkenden: Fordern Sie eine redaktionelle Überprüfung an, entfernen Sie vorübergehend die Vorschaufunktion, wo nötig, und wenden Sie 2FA für höherprivilegierte Benutzer an.
- Ziehen Sie in Betracht, einen proaktiven WAF/virtuellen Patch-Service und einen geplanten Scan-Zyklus hinzuzufügen.
WordPress wird immer ein Ziel sein aufgrund seiner Allgegenwart; Plugins verstärken dieses Risiko, wenn sie nicht defensiv geschrieben sind. Stored XSS ist mit ein paar einfachen Hygieneschritten für Entwickler vermeidbar und kann schnell mit verteidigbaren Betriebsprozessen und einer guten WAF eingegrenzt werden. Wenn Sie Hilfe bei der Triage einer bestimmten Seite benötigen oder maßgeschneiderte Milderungsregeln wünschen, kann unser WP-Firewall-Team mit schnellem virtuellem Patchen und Bereinigungsanleitungen helfen.
Bleiben Sie sicher und behandeln Sie Shortcodes und Plugin-Attribute als nicht vertrauenswürdige Eingaben, bis das Gegenteil bewiesen ist – bereinigen Sie frühzeitig und escapen Sie spät.
Wenn Sie eine kurze, druckbare Checkliste für Ihr Admin-Team möchten, antworten Sie für eine verkürzte PDF-Version mit Schritt-für-Schritt-Anweisungen und WAF-Regeln, die zu Ihrem Hosting-Stack passen.
