--- title: "Threema Outage: DDoS Attacks Cut Off Messenger for Two Days" date: 2026-08-14 author: "Sofia Ramirez" featured_image: "https://sqmagazine.co.uk/wp-content/uploads/2026/08/threema-messenger-ddos-attack-outage.jpg" categories: - name: "Cybersecurity" url: "/cybersecurity.md" tags: - name: "News" url: "/tag/news.md" --- # Threema Outage: DDoS Attacks Cut Off Messenger for Two Days Threema went completely unreachable for four hours on Tuesday, 08/11/2026, after a series of large-scale DDoS attacks hit the Swiss messenger and its hosting partner. The status page meant to explain the outage was offline too. ## What to Know? - Threema was unreachable between 7:30 p.m. and 11:30 p.m. CEST on Tuesday, with no messages sent or received. - The attacks also hit Nine, the Swiss colocation provider that rents Threema its server capacity. - Threema says the incident affected service availability only, and not the security of its systems or user data. - Threema OnPrem customers kept working through the outage because they run the messaging infrastructure on their own servers. - The company is adding upstream traffic filtering and rebuilding its status page with an incident history and an RSS feed. ## How It Happened? The disruption began Tuesday evening and ran until 11:30 p.m. CEST, when service came back. Attackers returned the next morning and kept shifting their traffic sources and patterns, fast enough that Threema had to rewrite its filters mid-attack, which produced short intermittent dropouts across the morning. Normal operations resumed at **12:23 p.m.** Threema described the defense in its [blog post on the outage](https://threema.com/en/blog/outage-august-2026) as a contest of resources, where the attacker tries to generate more traffic than the target’s filters can absorb while the target analyzes the pattern and blocks illegitimate requests without dropping real ones. “**A cat-and-mouse game ensues, with both sides continuously reacting to the other’s most recent action**,” the company wrote. > This week, Threema was targeted by DDoS attacks. Here’s what happened and the measures we’ve taken: > > — Threema (@ThreemaApp) [August 14, 2026](https://x.com/ThreemaApp/status/2088196947064566264?ref_src=twsrc%5Etfw) Both **Threema** and **Nine** took traffic at the same time, and the company has not said which one the attackers were aiming at. On Tuesday, before the attacks were public, Threema told users the trouble sat with a partner it rents server capacity from. Its post notes that attackers with state-level technical and financial resources can change methods faster than defenses adapt, without attributing this week’s traffic to anyone. Four things remain unexplained: - **Who ran the attacks. No individual, group, or country has been named by Threema or by Nine?** - **Whether Threema was the intended target or collateral damage from an attack on shared hosting?** - **How many of the messenger’s users lost access, and for how long each of them was cut off?** - **Why the status page failed during the first outage?** ## Encryption Was Never the Problem A flood attack takes a service off the air by exhausting its capacity, and that is all it does. It hands an attacker no keys, no message content, and no route into internal systems, which is why Threema’s disclosure separates availability from security. Nothing in the published accounts describes data access. That distinction matters less than it sounds to someone who paid for the app and could not open it. Threema costs **8 euros** on iOS and **6.50 euros** on [Android](https://sqmagazine.co.uk/iphone-vs-android-statistics/), and the purchase buys one company’s servers, with no federation and no alternative route to your contacts, so the users staring at a red connection bar on Tuesday had working mobile data and an app with nowhere to reach. The architecture that keeps Threema’s metadata exposure low is the same architecture that turns one bad night at a Swiss data center into a total blackout. ## Business Customers Split Two Ways **Threema Work** subscribers, who sit on Threema’s own infrastructure, went dark with everyone else and were emailed Wednesday morning about the unstable conditions, with account managers fielding inquiries as they came in. **Threema OnPrem** deployments were untouched, because those organizations host the messaging stack inside their own environments. Same vendor, same software, opposite morning, decided entirely by who owned the servers. Administrators who were affected have cleanup to do now: confirm that messages queued during the Wednesday morning dropouts actually delivered rather than assuming they did, and subscribe to the RSS feed once it exists, so future notices arrive over a channel that is not sitting behind the infrastructure under attack. The red bar in the app appeared regardless of whether the handset had working internet, which makes the device-level diagnosis the obvious wrong turn. ## SQ Magazine’s Takeaway An encrypted messenger’s threat model usually stops at confidentiality, and this week showed how much cheaper the other attack is. Stopping a conversation required no **ciphertext** at all, only enough traffic aimed at one Swiss facility. [Signal](https://sqmagazine.co.uk/signal-statistics/), which has picked up significant traction as an alternative, runs on the same centralized system. Threema’s upstream filtering was in final stability testing when the company published its account and was expected to reach production within hours, while the expanded status page with incident history and RSS is due within days. Threema says it absorbs this kind of traffic routinely and that users almost never notice, which sets the expectation for how often the next attempt arrives. Filtering upstream helps reduce the risk of another multi-hour blackout, though it will not prevent one, particularly against an attacker with the budget to keep changing shape.