74,000 Networks Breached Through
One Vendor's Product

What Happened: The Breach in Plain Terms

In June 2026, SOFX and security researcher Bob Diachenko of SecurityDiscovery.com published findings on a massive compromise of Fortinet FortiGate devices: the firewall and VPN appliances that sit at the edge of corporate networks and control who can connect to what.

The scale: roughly 74,000 devices across 194 countries, covering more than 22,000 corporate domains. The affected organisations included Oracle, Samsung, Chevron, Foxconn, Comcast, Siemens, PwC, Accenture, and a Turkish defense contractor linked to NATO. Classified defense documents were exfiltrated from that last one.

Before getting into what went wrong, it is worth being precise about what kind of attack this was, because it shapes the lesson. This was not a supply chain attack in the classical sense. The attackers did not compromise Fortinet's software distribution pipeline, inject malicious code, or backdoor a vendor update. What they did was significantly less sophisticated, and that is what makes it more instructive.

It Was Not a Zero-Day. It Was a Mass Scan.

The attack methodology, as reported, did not rely on a previously unknown vulnerability. The attackers mass-scanned the internet for exposed Fortinet FortiGate login endpoints, then deployed credential-spraying tools running 25,000 simultaneous threads. After capturing VPN authentication hashes, they used a 45-GPU cluster to crack them.

This is brute-force infrastructure, not sophisticated exploitation. The attackers did not need to find a clever hole in the software. They found a very large number of identical login pages sitting exposed on the internet, and they hit all of them at once.

That distinction matters enormously. A zero-day attack is difficult to defend against before a patch exists. A mass credential-spraying campaign is, in theory, defendable: stronger authentication, not exposing management interfaces to the public internet, network segmentation. Many of the affected organisations apparently had none of these in place.

But the more important point is this: the reason the attackers could hit 74,000 targets with a single campaign is that all 74,000 targets had the same product in the same configuration on the same publicly routable address space. They shared an attack surface.

The Real Problem Is Shared Software at Scale

When a large number of organisations all run identical software in identical configurations and expose it in identical ways, they become a single target that scales. This is sometimes called vendor monoculture risk. It is not a new concept in security, but this breach illustrates it at a scale that is hard to ignore.

The attackers built one scanner, one credential-spraying tool, one hash-cracking rig, and they pointed it at an enormous homogenous surface. Oracle and a roofing company in Texas had the same login page. A NATO contractor and a mid-size logistics firm had the same authentication mechanism. The attack scaled because the target was uniform.

For small and mid-sized businesses, the reflexive response is often "this is an enterprise problem, not mine." It is not. Automated mass scanners do not distinguish between Oracle's network edge and yours. They scan IP ranges, find the same login pages, and add whatever responds to the target list. Your size does not protect you from a campaign designed to hit everything at once.

The relevant question for any business is: how much of your critical infrastructure and data pipeline runs through shared, mass-market, internet-exposed software? Because every other organisation using the same software is, in a meaningful sense, your breach neighbour.

This Applies to Your Business Integrations Too

Most businesses are not running Fortinet firewalls. But most businesses are running shared SaaS platforms for their integrations, data pipelines, and workflow automation. And those platforms have the same structural characteristic: a very large number of organisations' sensitive business data flows through them, the platforms are internet-facing by design, and a successful attack on the platform affects every customer simultaneously.

Think about what moves through a typical business integration stack:

• CRM records including every lead, deal, and customer contact you have
• Revenue data being synced between your accounting system and your ad platforms
• API credentials and authentication tokens for every connected service
• Customer order data flowing between your storefront and your ERP
• Conversion data being uploaded to Google Ads and Microsoft Ads

When that data transits through a shared iPaaS platform, it is sitting on infrastructure that is also handling the same data for thousands of other businesses. The credentials your workflow uses to authenticate with your CRM are stored on that platform's servers alongside the credentials of everyone else using the same connector.

This does not mean shared platforms are reckless choices. Major iPaaS providers invest heavily in security. The point is structural: when you share a platform with thousands of other businesses, a successful attack on that platform's infrastructure has consequences for all of you simultaneously, regardless of how well-secured your own account settings are.

What Custom-Built Integrations Look Like Differently

A custom-built API integration is not public-facing by default. It does not have a known login page sitting on a well-known domain for attackers to scan. It is not listed on a platform's customer directory. It does not store your credentials alongside thousands of other businesses' credentials.

Here is what changes when you build rather than configure:

One caveat that is worth stating clearly: custom-built does not mean invulnerable. Any software can have bugs. Any server can be misconfigured. Any credentials can be stolen if they are stored carelessly. But the risk profile is fundamentally different: instead of sharing a target with tens of thousands of other organisations, your attack surface is specific to you and proportional to your actual footprint.

For most small and mid-sized businesses, that is a meaningfully safer position to be in.

What We Build and Why It Matters

The integrations we build for clients are not configured through a shared cloud dashboard. They are purpose-built to do one specific job, scoped to the minimum permissions that job requires, and deployed in environments that our clients control.

Some examples of what that looks like in practice:

We are not selling security consulting. We are a digital marketing and automation agency. But the architecture decisions we make when building integrations, including where credentials live, how much access each integration gets, and whether your data transits through shared infrastructure, have direct security implications. We take those decisions seriously.

If you are currently running critical business data through shared integration platforms and you want to understand what a custom alternative would look like for your specific setup, that is a conversation worth having.

Frequently Asked Questions