PHP-Sicherheitslücke in WordPress: Was Administratoren jetzt sofort tun müssen

Veröffentlicht: 01. November 2026 · Lesezeit: ca. 13 Minuten

Sie sehen im Dashboard: WordPress ist aktuell, alle Plugins sind auf dem neuesten Stand, das Backup läuft. Trotzdem meldet Ihr Monitoring ungewöhnliche POST-Anfragen auf /wp-admin/admin-ajax.php – und Sie fragen sich, ob das Rauschen oder ein echter Angriff ist. Genau hier liegt das Problem: Die Entscheidung, ob Sie jetzt sofort eskalieren oder abwarten und beobachten, fällt vielen schwer. WordPress-Updates geben ein falsches Gefühl von Vollständigkeit. Die PHP-Laufzeit auf dem Webserver – die eigentliche Angriffsfläche bei bestimmten Schwachstellen – bleibt dabei außen vor. Ob Ihr Betrieb gerade in dieser Lücke steht, hängt von einem einzigen Wert ab: der aktiven PHP-Version Ihres Servers. Den müssen Sie kennen, bevor Sie irgendetwas anderes entscheiden.

Die PHP Schwachstelle WordPress KMU betrifft ist kein theoretisches Risiko: Heise Security berichtete Ende Oktober, dass WordPress-Installationen aktiv angegriffen werden und Exploit-Versuche beobachtet wurden – WordPress-Update stopft Schadcode-Lücke, Exploit-Versuche beobachtet. Was dabei häufig übersehen wird: Ein WordPress-Core-Update patcht die Anwendungsschicht, ersetzt aber nie die PHP-Laufzeit des darunterliegenden Webservers. Beide Schichten müssen unabhängig voneinander aktuell gehalten werden.

Das trifft Betriebe mit eigener Website, Onlineshop oder Kundenportal auf WordPress-Basis besonders hart. Sie stehen oft vor dem Problem, dass der Hoster die PHP-Version verwaltet – ohne aktiven Anstoß durch den Betreiber ändert sich dort häufig nichts. BSI und IHK München haben explizit darauf hingewiesen, dass genau diese Zweiteilung der Verantwortung zum blinden Fleck wird. Laut BSI Lagebericht stieg die Zahl neu gemeldeter Schwachstellen weltweit um 24 % – ein Tempo, das reaktives Patchen strukturell überfordert.

Dieser Artikel analysiert die Angriffsarchitektur technisch konkret: Wie funktioniert der Angriffspfad, welche PHP-Versionen sind betroffen, welche Konfigurationsparameter Sie sofort prüfen sollten – und was gilt, wenn Ihr Hoster trotz kritischer Lücke nicht handelt.

Angriffsarchitektur: Wie PHP-Schwachstellen WordPress-Installationen kompromittieren

Die PHP Schwachstelle WordPress KMU entfaltet ihre Wirkung nicht an einem einzelnen Punkt, sondern als Zusammenspiel zweier Schichten: der WordPress-Anwendung und der PHP-Laufzeitumgebung auf dem Server. Das Verständnis dieser Architektur ist Voraussetzung für jede sinnvolle Gegenmaßnahme.

WordPress selbst ist in PHP geschrieben und wird vollständig durch den PHP-Interpreter des Webservers ausgeführt. Jede eingehende HTTP-Anfrage – ob an index.php, wp-login.php oder xmlrpc.php – durchläuft zunächst den PHP-Prozess, bevor WordPress-eigene Logik greift. Eine Schwachstelle auf PHP-Ebene kann daher wirken, bevor WordPress überhaupt einen Request verarbeitet oder eine Zugriffsprüfung durchführt.

Ein konkretes Beispiel ist CVE-2023-2745, eine Path-Traversal-Schwachstelle im WordPress-Core, die in Verbindung mit bestimmten PHP-Konfigurationen ausgenutzt werden kann. Das BSI hat diese Schwachstelle offiziell gemeldet; ein verfügbarer Proof-of-Concept (PoC) erhöhte die Dringlichkeit nachträglich. Angreifer können dabei über manipulierte Dateipfade auf Dateien außerhalb des vorgesehenen Webroot zugreifen – sofern die PHP-Konfiguration keine ausreichende Isolation bietet.

Der typische Angriffspfad sieht so aus:

Angreifer sendet präparierte POST-Anfrage an /wp-admin/admin-ajax.php oder /xmlrpc.php
PHP-Laufzeit verarbeitet die Anfrage – bei anfälligen Versionen ohne ausreichende Eingabevalidierung
Über unsichere Deserialisierung, Path-Traversal oder File-Upload-Schwachstellen wird Schadcode eingeschleust
Der Code wird im Kontext des PHP-Prozesses ausgeführt – mit dessen Dateisystemrechten
Persistenz wird über manipulierte wp-config.php, Backdoor-Plugins oder Cron-Jobs gesichert

Als ISO/IEC 27001 zertifiziertes IT-Systemhaus analysiert die TTG GmbH solche Angriffspfade regelmäßig. Entscheidend ist: Der Angriff ist selten laut. Ungewöhnliche POST-Volumen im access.log oder unerklärliche Fehler in error.log sind die einzigen frühen Indikatoren – weshalb Monitoring auf diese Endpunkte aktiv konfiguriert sein muss, nicht optional.

Prüfen Sie, ob xmlrpc.php über den Webserver (nicht nur WordPress-seitig) geblockt ist
Stellen Sie sicher, dass wp-config.php außerhalb des Document Root liegt oder per .htaccess gesperrt ist
Überwachen Sie /var/log/apache2/access.log bzw. /var/log/nginx/access.log auf wiederholte 4xx-Antworten an sensiblen Endpunkten
Setzen Sie open_basedir in der PHP-Konfiguration, um Dateizugriffe auf das Webroot zu beschränken

Versionsmatrix: Welche PHP- und WordPress-Kombinationen heute noch vertretbar sind

Die PHP Schwachstelle WordPress KMU hängt maßgeblich davon ab, welche PHP-Version aktiv ist – und ob diese noch Sicherheitsupdates erhält. Das PHP-Projekt pflegt eine klare Lebenszyklusdefinition: Jede Hauptversion erhält zwei Jahre aktive Entwicklung, danach ein Jahr Security-only-Patches, anschließend End-of-Life (EOL).

Die aktuelle Lage:

PHP-Version	Status	Empfehlung
≤ 7.4	EOL – keine Patches	Sofort migrieren, kein Produktivbetrieb
8.0	EOL – keine Patches	Sofort migrieren
8.1	EOL – keine offiziellen Patches	Upgrade dringend planen
8.2	Security-only, EOL Ende 2026	Übergangslösung, Migration planen
8.3 / 8.4	Aktiv supported	Zielversion für Neuinstallationen

WordPress selbst setzt seit Version 6.5 PHP 7.4 als Minimalanforderung voraus – was technisch funktioniert, aber sicherheitstechnisch inakzeptabel ist. Die WordPress-Dokumentation empfiehlt aktiv PHP 8.1 oder höher. Wichtig: WordPress prüft beim Update nicht, ob die PHP-Version noch sicherheitsgepflegt ist.

Auf der Plugin-Seite gilt: Viele ältere Plugins setzen noch auf veraltete PHP-APIs und sind nicht mit PHP 8.3 kompatibel. Ein Upgrade der PHP-Laufzeit kann daher Plugin-Konflikte auslösen. Die IT-Sicherheitslösungen der TTG GmbH umfassen genau diese Kompatibilitätsprüfung vor einem PHP-Upgrade, um Ausfälle zu vermeiden.

Lesen Sie die aktive PHP-Version im WordPress-Backend unter Werkzeuge → Website-Zustand → Server ab
Gleichen Sie die Version mit dem offiziellen PHP-Support-Status ab – EOL-Versionen sind nicht verhandelbar
Prüfen Sie Plugin-Kompatibilität mit PHP 8.3 über das Plugin-Repository oder den Hersteller, bevor Sie upgraden
Fordern Sie beim Hoster schriftlich den Zeitplan für PHP-Versionsupdates an – und dokumentieren Sie die Antwort

Konkrete Konfiguration: Parameter, Pfade und Einstellungen, die jetzt zählen

Die PHP Schwachstelle WordPress KMU lässt sich auf Konfigurationsebene mitigieren – vorausgesetzt, Sie haben Zugriff auf die PHP-Einstellungen. Bei Shared-Hosting-Umgebungen ist das oft nicht der Fall; dort müssen Sie den Hoster direkt einbinden. Auf VPS- oder Dedicated-Server-Umgebungen stehen folgende Parameter im Fokus:

session.upload_progress.enabled
Diese PHP-INI-Direktive ermöglicht es, Upload-Fortschritte in Session-Dateien zu schreiben. In Verbindung mit bestimmten Race-Condition-Schwachstellen wurde dieser Mechanismus für Angriffe genutzt. Das PHP-Projekt empfiehlt, ihn zu deaktivieren:

session.upload_progress.enabled = 0

Setzen Sie diesen Wert in /etc/php/8.x/fpm/php.ini (PHP-FPM) oder in der jeweiligen Pool-Konfiguration unter /etc/php/8.x/fpm/pool.d/www.conf. Nach der Änderung: systemctl restart php8.x-fpm.

open_basedir
Beschränkt den Dateisystemzugriff eines PHP-Prozesses auf definierte Verzeichnisse. Setzen Sie dies pro VHost:

php_admin_value[open_basedir] = /var/www/html/ihre-domain:/tmp

Dadurch kann ein kompromittiertes WordPress-Plugin keine Dateien außerhalb des eigenen Webroots lesen oder schreiben.

disable_functions
Deaktivieren Sie PHP-Funktionen, die für Shell-Ausführung genutzt werden, aber in WordPress nicht benötigt werden:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen

expose_php = Off
Verhindert, dass die PHP-Version im HTTP-Response-Header X-Powered-By sichtbar ist – entzieht automatisierten Scannern eine Information.

Für die WordPress-Konfiguration selbst gilt: Legen Sie wp-config.php eine Ebene oberhalb des Document Root ab und schützen Sie den /wp-admin-Bereich zusätzlich per HTTP-Basic-Auth oder IP-Whitelist auf Webserver-Ebene. Die sichere IT-Infrastruktur für KMU beginnt genau hier – mit der richtigen Absicherung der Laufzeitumgebung, nicht erst auf Anwendungsebene.

Prüfen Sie phpinfo() oder php -i | grep session.upload_progress – ist der Wert noch aktiv?
Setzen Sie open_basedir pro VHost, nicht global
Deaktivieren Sie expose_php und prüfen Sie den Response-Header mit curl -I https://ihre-domain.de
Starten Sie PHP-FPM nach jeder INI-Änderung neu und verifizieren Sie die Änderung mit php -i

Grenzfälle und Fallstricke: Was beim PHP-Upgrade in der Praxis wirklich bricht

Die PHP Schwachstelle WordPress KMU zu beheben klingt auf dem Papier einfach: PHP-Version hochziehen, fertig. In der Praxis bricht dabei regelmäßig etwas – und zwar genau dann, wenn der Produktivbetrieb es am wenigsten verträgt. Drei Problemkategorien dominieren erfahrungsgemäß:

1. Deprecated Functions und Fatal Errors
PHP 8.x hat eine Reihe von Funktionen und Syntax-Konstrukten, die in 7.x noch funktionierten, entfernt oder strenger behandelt. Typische Kandidaten: each() (seit 8.0 entfernt), ereg()-Funktionen (seit 7.0 weg), implizite Konvertierungen zwischen Typen (seit 8.0 wirft PHP teils Exceptions statt Notices). Ältere WooCommerce-Versionen, Formularplugins oder Memberpress-Installationen stolpern hier regelmäßig.

2. Hosting-Panele mit starrer PHP-Version
Auf Plesk- oder cPanel-Instanzen lässt sich die PHP-Version zwar über Domains → PHP-Einstellungen wechseln – aber nur auf die vom Hoster bereitgestellten Versionen. Bietet der Hoster PHP 8.3 nicht an, bleibt der Betreiber in der Sackgasse. Hier hilft nur die schriftliche Eskalation beim Hoster, mit Verweis auf die fehlenden Sicherheitsupdates – oder ein Hoster-Wechsel.

3. WordPress-Multisite und unterschiedliche Plugin-Kompatibilitäten
In Multisite-Installationen teilen sich alle Sub-Sites dieselbe PHP-Version. Ein Plugin, das auf Sub-Site A mit PHP 8.3 inkompatibel ist, blockiert u. U. das gesamte Netzwerk. Testen Sie deshalb zwingend auf einer Staging-Umgebung, bevor Sie die PHP-Version in Produktion ändern.

Vertragliche Grauzone zwischen Betreiber und Hoster
Ein in der deutschsprachigen Diskussion kaum beleuchtetes Thema: Was gilt rechtlich, wenn der Hoster trotz bekannter kritischer Schwachstelle die PHP-Version nicht aktualisiert? Aus DSGVO-Sicht trägt der Websitebetreiber als Verantwortlicher die Pflicht, technische Schutzmaßnahmen nach Art. 32 DSGVO sicherzustellen. Patcht der Hoster nicht, kann das eine Pflichtverletzung des Auftragsverarbeiters darstellen. Prüfen Sie Ihren Hosting-Vertrag auf SLAs für Sicherheitsupdates und fordern Sie diese schriftlich ein – das schafft Nachweis und Druck. Die IT-Dienstleistungen der TTG GmbH umfassen auch die Bewertung und Eskalation solcher Hosting-Konstellationen.

Testen Sie jeden PHP-Versionssprung auf einer identischen Staging-Instanz – nie direkt in Produktion
Nutzen Sie php -l dateiname.php für Syntax-Checks bei verdächtigen Dateien
Aktivieren Sie temporär display_errors = On und error_reporting = E_ALL auf Staging – nie auf Produktion
Fordern Sie vom Hoster schriftlich den PHP-Upgrade-Zeitplan an – dokumentieren Sie das Datum der Anfrage
Prüfen Sie bei Multisite: Plugin-Kompatibilität für jede Sub-Site separat, bevor der PHP-Sprung erfolgt

Betrieb und Monitoring: Woran Sie erkennen, dass Ihre WordPress-Installation sauber läuft

Nach dem Absichern stellt sich die PHP Schwachstelle WordPress KMU als Dauerthema heraus – nicht als einmaliger Fix. Der Betrieb einer gesicherten WordPress-Umgebung erfordert aktives Monitoring auf mehreren Ebenen. Hier sind die konkreten Indikatoren, die in der täglichen Praxis belastbare Aussagen liefern.

Serverlog-Analyse
Die aussagekräftigsten Quellen sind access.log und error.log. Suchen Sie aktiv nach:

Wiederholten POST-Anfragen auf /wp-login.php, /xmlrpc.php oder /wp-admin/admin-ajax.php von wenigen IP-Adressen
HTTP-500-Fehlern in Verbindung mit PHP-Fatal-Errors – oft Indikator für Exploit-Versuche, die an der PHP-Version scheitern
Unbekannten User-Agents, insbesondere solche, die typische Scanner wie Nuclei, sqlmap oder WPScan verraten

WordPress-seitige Integritätsprüfung
Das Plugin Wordfence Security bietet einen File-Integrity-Scanner, der Core-Dateien gegen bekannte Hashwerte prüft. Abweichungen in wp-includes/ oder wp-admin/ sind ein Alarmsignal. Alternativ: wp core verify-checksums via WP-CLI direkt auf der Shell ausführen – gibt in Sekunden Auskunft, ob Core-Dateien manipuliert wurden.

PHP-Error-Log gezielt auswerten
Der Pfad zum PHP-Error-Log ist in php.ini unter error_log definiert – häufig /var/log/php/error.log oder /var/log/php-fpm/error.log. Unerwartete Warning: include()– oder Fatal error: Call to undefined function-Einträge können auf manipulierte Dateien hindeuten.

Uptime und Response-Zeit als Baseline
Ein kompromittiertes System zeigt oft unerklärliche Response-Zeit-Spitzen oder Lastspitzen, bevor sichtbare Symptome auftreten. Tools wie die TTG GmbH als regionaler IT-Partner setzen hier auf automatisiertes Monitoring mit definierten Schwellwerten – reagieren Sie auf Anomalien, bevor Nutzer Ausfälle melden.

Das BSI Lagebericht Cybersicherheit dokumentiert, dass täglich durchschnittlich 119 neue Schwachstellen gemeldet werden – ein Patch-Prozess, der nur auf Meldungen reagiert, kommt strukturell zu spät. Monitoring muss die Lücke schließen.

Konfigurieren Sie Log-Rotation und -Archivierung: Logs älter als 90 Tage löschen – kürzer halten ist keine Option bei Incident-Response
Richten Sie einen Alert ein, wenn wp-config.php oder .htaccess ihre Prüfsumme ändern
Führen Sie wöchentlich wp core verify-checksums und wp plugin verify-checksums --all aus
Aktivieren Sie Two-Factor-Authentication für alle WordPress-Admin-Accounts – z. B. über das Plugin WP 2FA

Einordnung für Entscheider: Aufwand, Risiko und nächste Schritte

Die PHP Schwachstelle WordPress KMU ist kein Thema, das man delegieren und vergessen kann – aber der Aufwand ist überschaubar, wenn er strukturiert angegangen wird. Für Entscheider, die den technischen Kontext einordnen müssen, hier das Wesentliche:

Was kostet Nichtstun konkret?
Laut BSI Lagebericht gingen 80 % der dokumentierten Ransomware-Angriffe gegen KMU. Ein kompromittierter Webserver ist in vielen Fällen nicht der Endpunkt des Angriffs, sondern der Einstieg ins interne Netz – über gespeicherte Credentials, API-Keys in wp-config.php oder VPN-Zugangsdaten in Browserprofilen auf dem Webserver. Das Schadensmodell reicht damit weit über einen ausgefallenen Webauftritt hinaus.

Was ist realistisch umsetzbar?
Die PHP-Version im WordPress-Backend ablesen: 5 Minuten. Beim Hoster schriftlich anfragen: 15 Minuten. Eine Staging-Umgebung für den PHP-Upgrade-Test aufsetzen: ein halber Tag. Das sind keine Großprojekte – es sind Entscheidungen, die oft nur daran scheitern, dass niemand die Initiative ergreift.

Budgetrahmen
Ein externer Sicherheits-Check einer WordPress-Installation liegt je nach Umfang zwischen 500 und 2.000 Euro. Das schließt typischerweise PHP-Konfigurationsprüfung, Plugin-Audit und Log-Analyse ein. Managed-WordPress-Hosting mit automatischem PHP-Versionsmanagement ist für Betriebe ohne eigene Admin-Kapazität oft die wirtschaftlichere Lösung als Self-Hosting auf veralteter Infrastruktur.

Für Betriebe in Heilbad Heiligenstadt und der näheren Umgebung ist die TTG GmbH direkt ansprechbar – mit über 25 Jahren Erfahrung in der Betreuung mittelständischer IT-Infrastrukturen. Das bedeutet konkret: kein Ticketsystem in Indien, sondern ein Ansprechpartner, der Ihre Umgebung kennt.

Der BSI – IT-Grundschutz für Unternehmen bietet darüber hinaus kostenfreie Orientierung, welche Maßnahmen für Ihren Betriebstyp als Minimum gelten. Ergänzend empfiehlt sich ein Blick in die IHK-Beratungsangebote zur Informationssicherheit, die gerade für Betriebe ohne interne IT-Abteilung einen niederschwelligen Einstieg bieten.

Nehmen Sie jetzt Kontakt auf – unverbindlich und ohne Umwege.

Lassen Sie den Sicherheitsstatus Ihrer WordPress-Instanz durch einen Fachmann bewerten – einmalig, mit klarem Ergebnis
Stellen Sie sicher, dass Hosting-Verträge SLAs für Sicherheits-Patches enthalten
Planen Sie den PHP-8.3-Upgrade-Zeitplan jetzt – nicht wenn PHP 8.2 EOL erreicht hat
Dokumentieren Sie alle Anfragen an den Hoster schriftlich – das ist bei DSGVO-Vorfällen belegpflichtig

Ihre Checkliste: So starten Sie jetzt

Prüfen Sie die aktive PHP-Version im WordPress-Backend unter Werkzeuge → Website-Zustand → Server – alles unter PHP 8.2 ist sofort zu eskalieren.
Vergleichen Sie die Version mit dem offiziellen PHP-Support-Status auf php.net – EOL-Versionen erhalten keine Sicherheitspatches mehr.
Fragen Sie Ihren Hoster schriftlich an, welche PHP-Version aktiv ist, wann Updates eingespielt werden und ob PHP 8.3 verfügbar ist – dokumentieren Sie Datum und Antwort.
Aktivieren Sie Auto-Updates für WordPress-Core, Plugins und Themes – unter Dashboard → Updates → Automatische Updates.
Prüfen Sie Ihre Server-Logs (access.log, error.log) auf ungewöhnliche POST-Anfragen an /wp-login.php, /xmlrpc.php und /wp-admin/admin-ajax.php.
Führen Sie auf der Shell aus: wp core verify-checksums und wp plugin verify-checksums --all – Abweichungen sofort untersuchen.
Setzen Sie bei Root-Zugang session.upload_progress.enabled = 0 und open_basedir auf das Webroot – dann PHP-FPM neu starten.
Sprechen Sie mit einem IT-Dienstleister, wenn Sie keinen Root-Zugang haben, Ihr Hoster nicht reagiert oder Sie Anomalien in den Logs entdeckt haben.

Häufig gestellte Fragen

Reicht es, WordPress auf die aktuelle Version zu aktualisieren?

Nein – das ist ein verbreiteter Irrtum. WordPress-Updates betreffen ausschließlich die Anwendungsschicht: Core-Dateien, Plugins und Themes. Die PHP-Laufzeit, die WordPress auf dem Webserver ausführt, wird dadurch nicht verändert. BSI und IHK München haben ausdrücklich darauf hingewiesen, dass beide Ebenen unabhängig voneinander gepatcht werden müssen. Wer nur WordPress aktualisiert, aber auf PHP 7.4 oder 8.1 betreibt, bleibt auf der Laufzeitebene verwundbar.

Mein Hoster kümmert sich doch um die PHP-Version – muss ich trotzdem aktiv werden?

Ja, denn die Verantwortung liegt aus DSGVO-Sicht beim Betreiber der Website, nicht beim Hoster. Art. 32 DSGVO verpflichtet Sie, technische Schutzmaßnahmen sicherzustellen. Ob Ihr Hoster tatsächlich aktuelle PHP-Versionen einsetzt, müssen Sie aktiv prüfen und schriftlich bestätigen lassen. Viele Hoster aktualisieren PHP erst auf Anfrage oder bieten ältere Versionen über Jahre hinweg als Standard an. Anfrage dokumentieren, Antwort aufbewahren.

Wie erkenne ich, ob meine WordPress-Installation bereits kompromittiert wurde?

Prüfen Sie zunächst die Server-Logs auf ungewöhnliche POST-Anfragen und Fehler. Führen Sie auf der Shell wp core verify-checksums aus – liefert das Plugin abweichende Hashes, ist sofortige Untersuchung geboten. Sichtbare Symptome wie Weiterleitungen auf fremde Seiten, unbekannte Admin-Accounts oder unerklärliche Lastspitzen sind oft bereits späte Indikatoren. Im Zweifel: Website offline nehmen und eine Fachkraft einschalten.

Was kostet eine professionelle Überprüfung meiner WordPress-Sicherheit?

Ein strukturierter Sicherheits-Check einer einzelnen WordPress-Installation liegt je nach Tiefe zwischen 500 und 2.000 Euro. Darin enthalten sind üblicherweise PHP-Konfigurationsprüfung, Plugin-Audit, Log-Analyse und ein schriftlicher Befundbericht. Das ist überschaubar verglichen mit den Kosten eines Sicherheitsvorfalls – Wiederherstellung, Datenschutzmeldepflicht nach Art. 33 DSGVO und möglicher Reputationsschaden eingerechnet.

Wie dringend ist das Thema – habe ich noch Zeit, das zu planen?

Exploit-Versuche gegen WordPress-Installationen werden laut Heise Security aktiv und in großem Umfang beobachtet. Automatisierte Scanner suchen gezielt nach veralteten PHP-Versionen und bekannten Schwachstellen. Wer heute auf einer EOL-PHP-Version betreibt, ist in der Praxis kein unbekanntes Ziel mehr – sondern ein sichtbares. Eine grobe Bestandsaufnahme – PHP-Version prüfen, Hoster kontaktieren – ist in 30 Minuten erledigt. Der Aufwand ist gering, das Zeitfenster dafür nicht unbegrenzt.

Lesetipps – weitere Ratgeber der TTG GmbH

Über den Autor
Martin Trappe ist Geschäftsführer der TTG Daten- und Bürosysteme GmbH in Dingelstädt. Mit über 25 Jahren Erfahrung im IT-Mittelstand betreut er kleine und mittelständische Unternehmen in Nordthüringen, Eichsfeld und Südniedersachsen. Die TTG GmbH ist ISO/IEC 27001 zertifiziert – dem höchsten Standard für Informationssicherheit.

Kontakt aufnehmen · Über TTG GmbH

Wissen Sie gerade, auf welcher PHP-Version Ihre WordPress-Website live geht – und ob diese noch Sicherheitsupdates erhält?

Ihre IT-Sicherheit jetzt stärken

Schützen Sie Ihr Unternehmen vor Cyberangriffen und Datenverlust. Die TTG GmbH berät KMU in Nordthüringen und Eichsfeld – ISO/IEC 27001 zertifiziert, persönlich vor Ort.