Hacked TYPO3 Site: Cleanup and Recovery

By Glenn Lyvers · Updated September 21, 2026 · 4 min read

TYPO3 powers a substantial number of corporate and public sector sites, particularly across Europe, and it receives a fraction of the hacked-site documentation written for WordPress. The platform itself is soundly built with an active security team. When a TYPO3 site is compromised it is almost always the familiar story: an unsupported version, or an extension nobody has updated in years.

How TYPO3 sites get compromised

Running an unsupported version is the leading cause. TYPO3 has clearly defined support windows with long-term support releases, and once a version passes out of support it receives no further security fixes. Corporate sites frequently sit on an old version for years because upgrading is a budgeted project rather than a routine task.

Third-party extensions are the other major route, and the same dynamic applies — an extension installed for one feature five years ago, whose author stopped maintaining it, sitting in the install because nobody audits what is no longer used. After that, the usual: weak backend credentials and over-permissive file permissions.

Where to look

The fileadmin directory holds editor-managed content files and should contain no executable code. The uploads directory and the various typo3temp paths are writable and are natural places for dropped files. Check all of them for PHP.

Then the extension directories, comparing what is installed against what you believe you installed, and core files against a clean copy of your exact version. Check LocalConfiguration and related configuration files for modifications, since they hold database credentials and the encryption key. And check the database for injected content in page content elements and in TypoScript, which can carry markup rendered onto pages.

Backend accounts and permissions

TYPO3 separates backend users from frontend users, and it is the backend that matters here. Check for backend administrator accounts you did not create, and for existing accounts whose permissions have been widened — the permission model is granular, which makes a quiet escalation easier to miss than a new account.

Check backend user groups as well as individual accounts. Then review the install tool access, since that is effectively root for the application, and confirm it is not reachable without proper authentication.

Caches will confuse you

TYPO3 caches aggressively, both in the database and on disk, and cached pages generated while the site was infected will keep being served after you have cleaned the source. This produces the familiar and demoralising experience of cleaning a site, checking it, and seeing the injection still there.

Flush all caches after cleaning, including the ones held in the database, and then verify. Where a cleanup appears to have failed on TYPO3, stale cache is the first thing to rule out rather than the last.

Cleaning it

Preserve evidence first, then update core to a supported version, reinstall extensions from official sources and remove those you do not use, and delete anything in the writable directories that does not belong. Sweep the database for injected content in content elements and TypoScript configuration.

Then rotate: the database password, the encryption key in your configuration, all backend user passwords, and any credentials for external integrations. Flush every cache, then verify the rendered site from outside with no backend session.

Staying on a supported version

This is the substantive fix and on a corporate TYPO3 site it is usually a planning problem rather than a technical one. Long-term support releases exist precisely so that organisations can stay secure without upgrading constantly, and getting onto one with a plan for the next is what keeps this from recurring.

In the meantime: audit extensions and remove what is unused, restrict backend access by IP where the user population allows it, enable two-factor authentication on backend accounts, and keep fileadmin non-executable. If you want the site assessed and cleaned properly by someone who will not assume it is WordPress, that is work I take on — see the platforms I clean.

Common questions

Which directories should I check first in TYPO3?

fileadmin, uploads and the typo3temp paths — all writable and none of which should contain executable PHP. Then extension directories against what you believe is installed, core against a clean copy of your version, and the configuration files that hold your credentials and encryption key.

Why does the injection reappear after I clean it?

Almost always stale cache. TYPO3 caches aggressively both on disk and in the database, so pages rendered while the site was infected keep being served afterwards. Flush every cache, including database-held caches, then verify before concluding the cleanup failed.

Is my TYPO3 version still supported?

Check your version against TYPO3's published support windows. Versions past their support window receive no further security fixes, which puts you in the same position as any end-of-life platform: known vulnerabilities stay exploitable permanently and the list grows.

Where can injected content hide besides files?

In the database — page content elements can carry markup, and TypoScript configuration is rendered into pages, which makes it an effective and frequently overlooked hiding place. Search both rather than assuming a file cleanup covers everything.

How do I check backend accounts properly?

Look for administrator accounts you did not create, but also review backend user groups and the permissions of existing accounts, since the granular permission model makes a quiet escalation easier to miss than a new account. Check install tool access as well — it is effectively root.