Loading story…
Threema said a large-scale DDoS campaign caused repeated outages and degraded performance across its messaging platform, preventing users from connecting to servers and from sending or receiving messages. The company initially linked the disruption to capacity issues at a hosting partner, but later confirmed that the outage was caused by sustained denial-of-service attacks affecting both Threema and its colocation partner Nine. According to Threema, the attacks used high traffic volumes and constantly shifting patterns, complicating mitigation efforts and causing a full service outage followed by intermittent disruptions.
Threema reported that its services were unavailable from 19:30 to 23:30 CEST during the main outage, with additional intermittent issues continuing into the following morning before full recovery at 12:23 CEST. Threema Cloud was affected for about 17 hours, while Threema OnPrem remained unaffected because customers run that infrastructure themselves. The company said it was deploying specialized upstream DDoS protection and planned status-page improvements, including incident history and an RSS feed, while noting that it had not attributed the attack to a specific actor, though well-resourced state-backed operators could not be ruled out.
See attribution, scope, and your downstream exposure.
9 events from the most recent confirmed update back to the earliest known activity.
On Wednesday morning, Threema informed Threema Work customers about the incident by email. The company also communicated progressively through social networks and account managers.
During the disruption, Threema's system status page was also temporarily unavailable because of a separate technical issue. This reduced visibility into the incident while the outage was ongoing.
Threema later reported that a DDoS attack caused service unavailability from 19:30 to 23:30 CEST on August 12, affecting all Threema services. Users could not connect to Threema servers or send and receive messages.
Earlier on Tuesday, Threema said the outage was caused by a problem at a partner from which it rented server capacity. At that stage, the company had not yet publicly attributed the disruption to DDoS activity.
On the evening of August 11, Threema began experiencing service problems, with users reporting long message delays or failed sends. Based on available information at the time, Threema said the issue appeared to be a network failure on the partner side, and Nine later said the problem had been resolved before service restoration began.
In response to the incident, Threema began deploying specialized upstream DDoS protection to filter malicious traffic before it reached production systems. The company also said it planned to improve its status page with incident history and an RSS feed.
On August 14, Threema published an official post-mortem describing a large-scale DDoS campaign that targeted both Threema and its colocation partner Nine over two consecutive days. The company said it could not formally attribute the attack, though it noted state actors as a possible explanation.
Threema reported that all services were fully operational again at 12:23 CEST on August 13. By Wednesday, the disruptions had become noticeably smaller and communication was intermittently possible again before full recovery.
On the morning of August 13, Threema experienced a new wave of attacks and intermittent service interruptions as the campaign continued into a second day. Threema said it was actively working to mitigate the attacks and warned that temporary outages could continue.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See attribution, scope, and whether this vendor sits anywhere in your supply chain.
8 references tracked. Mallory keeps watching after this page renders.
xakep.ru
Open sourcescworld.com
Open sourcecybersecuritynews.com
Open sourcesecurityaffairs.com
Open sourcebleepingcomputer.com
Open sourcethreema.com
Open sourcecyberveille.ch
Open sourceheise.de
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Mastodon said its primary server, **`mastodon.social`**, was hit by a significant distributed denial-of-service (**DDoS**) attack that caused intermittent outages and left the instance temporarily unusable for some users. The company said it began investigating early Monday morning and later deployed countermeasures that restored access, while warning that some instability could continue because the attack was still ongoing. The disruption affected Mastodon’s flagship instance rather than the broader federated network, underscoring how decentralized social platforms can suffer localized availability failures without a platform-wide compromise. Reports noted that the incident followed a similar prolonged DDoS campaign targeting **Bluesky**, and emphasized that DDoS activity is intended to overwhelm services with junk traffic and degrade availability, not inherently to steal data.
Jun 29, 2026
Bluesky suffered a sustained **distributed denial-of-service (DDoS) attack** that caused intermittent outages and degraded performance across its website and mobile app for more than a day. The disruption began early Thursday and produced slow loading, blank screens, missing content, and repeated **"Rate Limit Exceeded"** errors, with users reporting problems accessing feeds, notifications, threads, search, user profiles, and popular areas such as Discover. Company officials said the platform was being hit hard by coordinated traffic and was actively mitigating the attack, which also affected key API servers and even parts of Bluesky’s status infrastructure. Bluesky said it had found **no evidence of unauthorized access to private user data**, while reports indicated the impact was concentrated on Bluesky-operated services and that other communities running their own infrastructure on the underlying decentralized protocol remained available.
Jun 29, 2026
Reporting described multiple, unrelated threat activities rather than a single cohesive incident. SOCRadar assessed a sustained DDoS campaign by **NoName057(16)** using the **DDoSia** toolset during March 2–8, 2026, logging **7,512** attack entries against **169 domains** and **153 IPs**, with **Germany** as the primary target (65.6% of entries) and **Israel** as a major secondary target (19.7%). The most notable pattern was heavy, systematic disruption of Germany’s public procurement ecosystem, including at least **17 procurement portals** (974 entries), alongside Israeli targeting across defense industry, finance, telecom, and municipal services. Separately, Flare reported an active **phishing campaign** using fraudulent domains impersonating Canadian institutions (including the Government of British Columbia and *Hydro-Québec*) to harvest personal and payment data; the infrastructure was linked to **RouterHosting LLC / Cloudzy**, a provider previously accused (in 2023) of supporting services used by multiple state-sponsored groups, including Iran-aligned actors. Two other items were not incident-specific: Hackmageddon published aggregated February 2026 attack statistics, and DataBreaches.Net summarized research on offender age distribution in cybercrime; both are higher-level analysis and do not materially add to the DDoS or phishing reporting.
Jun 29, 2026