Keep company files off the public internet

What the breach investigators measured

The Verizon 2026 Data Breach Investigations Report, published in May 2026 as the 19th edition, analysed more than 22,000 confirmed data breaches in 145 countries. Its headline finding is that exploitation of vulnerabilities is now the most common initial access vector, at 31% of breaches, while credential abuse, the previous leader, is down to 13%.

The same report measures how slowly the fixes land. Only 26% of critical vulnerabilities, defined as those in the CISA Known Exploited Vulnerabilities catalog, were fully remediated by organisations in 2025, down from 38% the year before. The median time for full resolution rose to 43 days, almost two weeks longer than the 32 days of the year before, and the median organisation had 50% more critical vulnerabilities to patch than the year before.

M-Trends 2026 from Google Cloud Mandiant, drawn from the incidents its teams investigated in 2025, lands in the same place from a different dataset. Exploits were the most common initial infection vector for the sixth consecutive year, at 32% of intrusions. Mandiant also reports that the mean time to exploit vulnerabilities has plummeted, with threat actors compromising systems, including edge and core network devices, before vendors release a patch. Once inside, the median time between an opportunistic initial access event and the hand-off to a secondary threat group fell from more than 8 hours in 2022 to 22 seconds in 2025.

AI moved the cost of an exploit

The reports above describe speed. Two disclosures from Anthropic describe why the speed keeps rising.

In its report "Disrupting the first reported AI-orchestrated cyber espionage campaign", published in November 2025, Anthropic describes an operation it detected in mid-September 2025 and attributes with high confidence to a Chinese state-sponsored group it calls GTG-1002. The operation targeted roughly 30 entities. The threat actor used Claude Code as autonomous agents that handled reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting and data exfiltration, executing 80 to 90 percent of all tactical work independently. The conclusion Anthropic draws is that the barriers to performing sophisticated cyberattacks have dropped substantially and will continue to do so.

On April 7, 2026 Anthropic announced Project Glasswing, a defensive programme built around a model it has withheld from general release. In the weeks before launch that model found thousands of high-severity zero-day vulnerabilities in every major operating system and every major web browser. The examples Anthropic gives are a 27-year-old flaw in OpenBSD that lets an attacker remotely crash any machine running it, a 16-year-old flaw in FFmpeg in code that automated testing had exercised five million times, and a chain of Linux kernel bugs the model found and combined on its own to go from ordinary user access to complete control of the machine. The framing from Anthropic itself is that the cost, effort and expertise needed to find and exploit flaws have all dropped dramatically.

M-Trends 2026 reports the same shift from the side of the defender: threat clusters have increasingly adopted AI tools for reconnaissance, social engineering and malware development, and Mandiant observed malware checking compromised machines for AI command-line tools so it could use them to search for configuration files.

Put the three together and the picture is clear. A newly disclosed flaw in anything that listens on the public internet is now found, weaponised and used by software, at a pace no 43-day patch cycle can match.

What a server on your own network buys you

The figures above are about services the whole internet can reach. A company file system that answers only to addresses inside your own network changes the first question an attacker has to answer, which is whether they can reach it at all.

With BucketDesk self-hosted, the application runs on a server you control: an EC2 instance in your own AWS account, or a Docker host in your office or data centre. It accepts no traffic from the internet. Staff reach it on DNS names inside your network, the same way they reach your other internal systems, and the only connections the server opens are outbound HTTPS requests to AWS in your own account. A proxy, a VPN, Direct Connect or VPC endpoints all work for that route.

That gives you three things. First, a new vulnerability disclosure becomes a scheduled update rather than a race: the people who can try the flaw against your server are the people already on your network. Second, your file system stops being a place the public internet can probe, so the 22-second hand-off that M-Trends describes needs a foothold on your network before it can start. Third, the blast radius of the server itself is bounded by IAM: BucketDesk runs as a scoped role in your AWS account that the access stack creates, and deleting the stack ends the access.

Two more properties matter for the long run. The licence is verified on your own server with a public key, so day-to-day use involves no call to BucketDesk, and your server contacts BucketDesk only when you ask it to start a trial or buy a licence. And every release, including security fixes, is published to the public image and the install kit on the day it ships, and updating is one command, with or without a licence.

What still needs doing

Running on your own network removes the public internet from the attack surface. It does not remove the work of running a server. The items below are yours whichever way you deploy.

• Patching: the update is one command, but someone has to run it, and the 43-day median in the DBIR is a reminder that the command rarely runs itself. Put the release notes feed on a calendar and treat a security release as a same-week job.
• IAM: the access stack creates a scoped role. Keep it scoped. Review which buckets and prefixes it can reach when you add a team, and delete the stack for any account you stop using.
• Backups and encryption: your files stay in your S3 buckets, so versioning, replication and Object Lock are the backup story. The disk of the server itself holds the database, logs and the offline cache, so encrypt that disk and back up the database on your usual schedule.
• Certificates and names: the install needs two DNS names on your network with certificates that the browsers your staff use will trust, and those certificates expire.
• Logs: the app writes one log file per day and keeps 14 days. Point your own log collection at that folder so an investigation can look further back.