Online guide
Guide
AI and LLMs Inside FileMaker: What Actually Works in 2026
Production use cases: semantic search, extraction, classification and RAG, with provider choice and UK GDPR notes.
11 min read · Updated April 2026
The October 2026 attacks on FileMaker servers and the hosting outage
What happened during the October 2026 attacks on FileMaker servers and the outage on one of our hosting providers' platforms. It covers how our plan worked and what we've done since.
Updated October 2026 · 4 min read · By Neptune Digital
| Records read on our servers | Some systems offline or read-only | Outage resolved |
|---|---|---|
| 0 | 25 to 27 Oct | 28 Oct |
In short
In October a wave of automated attacks hit FileMaker servers around the world, including servers we host. Claris, the company behind FileMaker, has confirmed it is aware of them. No attacker got into a real account and nobody read any records.
On Sunday 25 October one of our hosting providers took its whole platform offline while it investigated a security issue. Some of the systems we host run on that platform and they were offline or read-only until 27 October. Systems on other platforms stayed up throughout.
If your systems were affected, you'll have heard from us directly during the outage. If you didn't hear from us, your systems weren't affected and kept running as normal.
We marked the outage resolved on the morning of 28 October.
Timeline
| When | What happened |
|---|---|
| Thu 22 Oct, evening | We spot automated login attempts on some of our servers. FileMaker locks the targeted accounts and our checks of the logs show nobody got in |
| Fri 23 Oct | We confirm which setting hides file lists from outsiders and add a daily check of it across all our servers |
| Fri 23 Oct, late evening | One of our hosting providers tells us it has seen unusual login attempts on our servers |
| Sat 24 Oct, evening | The last nightly backup before the outage runs |
| Sun 25 Oct, afternoon | The provider takes its whole platform offline worldwide to investigate a security issue |
| Sun 25 Oct, late evening | The provider says its investigation has finished and it has started bringing systems back |
| Mon 26 Oct, early morning | We email affected clients that their systems are offline |
| Mon 26 Oct, morning | We start opening read-only copies, one system at a time |
| Mon 26 Oct, early evening | The provider tells us it can't guarantee all our servers will be back by 7am on 27 October |
| Mon 26 Oct, evening | Our team works through the night building replacement servers as a fallback |
| Tue 27 Oct, early hours | The provider starts bringing some of our servers back. We move each one back as it returns instead of using the replacements |
| Tue 27 Oct, early morning | We confirm most affected systems are back and working as normal |
| Tue 27 Oct, morning | The remaining affected systems are available for reference only while we finish our checks |
| Tue 27 Oct, afternoon and evening | Those systems go offline briefly while we move them from the read-only copy to the full database. They return to normal use, some with new passwords |
| Wed 28 Oct, late morning | We mark the outage resolved |
What it meant for affected clients
The read-only copies came from the backup taken on the evening of 24 October, so anything entered after that wasn't in them.
Some of the systems that came back later on 27 October returned with new passwords. Those clients got theirs by one-time link and we asked them to reset passwords for the rest of their team.
How our plan worked
Spreading the systems we host across more than one hosting provider meant the outage only reached systems on one platform. Everything else kept running.
We keep off-site backups of the systems we host and have a business continuity plan for an outage like this one. This meant we didn't have to wait for the provider. The first read-only copies were running on the morning of 26 October and more followed through the day.
When the provider couldn't guarantee a time for bringing everything back, our team worked through the night building replacement servers. The provider started bringing our servers back in the early hours of 27 October, so most systems went straight back to their usual servers. A few ran on the replacement servers until their own came back later that day.
We kept affected clients updated throughout with status page posts, direct emails and replies to support requests. We checked each system before telling its users it was ready.
What we've done
We turned on the setting that hides file lists, tested which setting controls it and added a daily check of that setting on every server we host. The provider whose platform went offline also gave us new administrator credentials for every restored server.
We reviewed the logs of our servers and of the web and database platforms we use. They show failed attempts and normal background traffic from the internet. We also reviewed our automation platform for security problems and wrote a security checklist for hosted servers and files. It covers weak or missing passwords, guest access and which services each file allows.
Thank you
We know how disruptive the outage was for the clients it affected. Thank you for your understanding, patience and support while we worked to get your systems back.
If you have any questions about what happened, please contact us at support@neptunedigital.co.uk.
