Threat intel
AfD email leak: what a hosting provider breach exposes
Germany's AfD says a hosting provider was breached in September and mailboxes were copied. What it shows about hosted mail, and what to ask your own provider.
Germany's Alternative für Deutschland (AfD) party has confirmed that an external hosting provider it uses was attacked in September 2026 and that parts of several mailboxes were copied. On October 19 an anonymous website went online indexing what it says are 421,179 internal party emails, about 281 GB of material, which the attackers say came from roughly ten mailboxes. The party says most of the affected mailboxes had not been used for years, that current mailboxes of its federal organisation were not touched, and that the attack was detected and stopped quickly.
The material has not been independently verified, and the provider has not been named. The politics and the contents are outside our scope. For other organisations the useful part is the shape of the incident: email held by a third party, old mailboxes still sitting on a live server, and an attacker who says the way in was a website on the same provider. Any organisation that hands its web and mail hosting to an outside company carries that risk.
What is confirmed and what is claimed
An AfD spokesperson told the dpa news agency and other German media that "in September 2026 there was a hacker attack on a hosting service provider of our party" and that parts of "a few mailboxes" were unlawfully copied. The party said all affected users were informed and that the online publication, "presumably of part of this data", is being reviewed. Reuters reported the same statement on October 20 and noted that the spokesperson did not say how much data was taken.
The scale comes from the other side. The leak site indexes 421,179 messages, a count reported by Security Affairs and Brussels Signal, and archived copies showed about 281 GB, according to Reuters and Brussels Signal. dpa reports the attackers' claim of ten mailboxes, including one in the name of a former party leader and one address the party once listed as a contact for its federal office. International Cyber Digest, which examined the index on October 19, found the newest message dated September 12, 2026. Security Affairs points out that this date sits awkwardly with the party's description of mostly dormant accounts.
Two details remain unverified. Security Affairs reports that the attacker told International Cyber Digest the entry point was "a single unpatched party website", from which they reached the mail servers. No other outlet we found repeats the method, and the provider has not described it. Berlin security researcher Lilith Wittmann said on X that, from what she had seen, she considered the material genuine and the described route into the systems credible. Treat the route as the attacker's account until the provider or investigators confirm it.
How a website becomes a way into mail
Small hosting providers often run websites and mail on the same servers, or on servers sharing an admin network, control panel and storage. A typical stack pairs a content management system such as WordPress with Postfix and Dovecot (common open source mail transfer and mailbox servers), which store mailboxes as plain files in Maildir folders.
If an attacker exploits an unpatched plugin or framework on the website, they usually get code running as the web server's user. On a well-separated setup that user can read the web root and nothing else. On a shared or loosely built one, the same box may hold the mail store, a configuration file with database passwords, or a control panel session that manages mail accounts. From there, copying mailboxes needs no password at all: the attacker reads the Maildir files directly or pulls them with the server's own tools. Because nobody logs in over IMAP (the protocol mail clients use to read mailboxes), mailbox login logs show nothing unusual.
Dormant mailboxes make this worse. A mailbox nobody has opened in years still holds every message it ever received, and nobody notices it being read.
What to ask your hosting provider
1. Patching on shared web servers
Ask who patches the content management system, its plugins and the PHP or other runtime on each site, and within how many days of a security release. Contracts often cover only the operating system and leave the application to the customer, which is how forgotten campaign sites stay unpatched for years. List every site on your domains, including staging copies and old projects, and either bring each one under a patching owner or take it down.
2. Separation between web and mail
Ask whether websites and mailboxes run on the same server, container or virtual machine, and whether the web server's user can read the mail store. A good answer is that mail runs on separate hosts, with no shared file systems and no route from the web tier to the mail store or its admin interfaces. If the provider uses a control panel such as Plesk or cPanel, ask how a compromised site account is kept away from mail accounts on the same server.
3. Retention and dormant mailboxes
Get a list of every mailbox on your domains with its last login date. Accounts with no login in 12 months should be exported to offline, encrypted storage if you must keep them, then deleted from the live server. Ask the provider whether deleted mailboxes and backups are actually purged, and after how long.
4. Logs you can get on request
Ask what the provider keeps and for how long: web server access logs, control panel audit logs, Dovecot and Postfix logs, and file access or outbound transfer records on the mail hosts. Agree in writing that you can get your own logs within one working day of asking; without them you cannot tell what was read.
5. Breach notification
Check the contract for how fast the provider must tell you about a breach that touches your data. Under the EU General Data Protection Regulation (GDPR), the provider is your processor and must inform you without undue delay, and you as controller have 72 hours from awareness to notify your supervisory authority.
Checking whether you were exposed
If your provider reports an incident, or you suspect one, ask for these specifically:
- Web server access logs for every site on the shared host, filtered for POST requests to unusual PHP files, requests to recently created files in upload folders, and hits on plugin paths with known vulnerabilities.
- A list of files in each web root changed in the window, for example
find /var/www -type f -newermt 2026-08-01 -name '*.php', to find dropped web shells (small scripts that give an attacker remote command access). - Dovecot logs (
imap-loginandpop3-loginlines, withuser=andrip=fields) for logins from unknown addresses, keeping in mind that direct file copying leaves no login line. - Outbound traffic records from the mail hosts for large transfers to unfamiliar addresses, which is often the only trace of a bulk copy.
Afterwards, rotate the passwords of every mailbox on the affected server, dormant ones included, and of any service account that sends mail through it. Revoke application passwords and API tokens issued by the hosting control panel. Where mailboxes held identity documents or bank details of members or customers, your data protection lead will need to assess whether those people must be told.
The wider lesson
Hosting contracts are usually signed for price and uptime, then left alone. If the attacker's account is right, an unpatched website and long-unused mailboxes at the same provider added up to a large mailbox leak. A provider's web servers belong in your own attack surface inventory, and mailbox retention should be a setting you control.
Our attack surface management work finds forgotten sites and mail hosts on your domains, and our safeguarding and hardening team reviews how your hosted web and mail are separated and logged. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Security Affairs, ZDFheute (dpa), ORF, Stuttgarter Zeitung (dpa), Reuters via bdnews24, Brussels Signal, it-daily (dpa).