Black October is over, but there’s no sign that cybersecurity professionals can catch their breath. The first three days of November saw over 1,300 CVEs issued, 50 of which have a CVSS score of “Critical,” and the theft of cryptocurrency worth over $6 billion. AI has made the job of every security professional much harder, not just by probing for vulnerabilities at a scale heretofore unseen, but also by adapting its attack to newly discovered vulnerabilities in real time.
So, what happened at Proof?
Put simply, we think it was a “chained attack.” These are AI-driven attacks that find a small entry point into a system, then escalate into progressively deeper attacks. Attempts to attack our systems are nothing new; we’ve been defending against them for years. This one was different, and it led us to pull the plug on our entire network as the target of the attack shifted from poorly secured files to the network itself.
What about OttoFMS?
As part of our response to the attacks on our customers’ systems and our own, we’ve released a new version of OttoFMS that contains security enhancements, some planned before this attack and some based on our own audit of the software.
I want to be clear about one thing that relates to the role of OttoFMS in the attack: most of what OttoFMS does is expose features of FileMaker Server and related tools (Data Migration Tool, Developer Tool) and make them easier to use with a cleaner, better-documented API. OttoFMS wasn’t the first thing the attack probed – it principally used the Admin API, XML gateway, and DataAPI interfaces to attempt to gain entry into user files. The OttoFMS API was simply easier and more efficient to use, and we were concerned that it could be leveraged by threat actors.
The changes we've made fall into three buckets:
- Node.js update to address a known vulnerability (CVE-2026-111497).
- Planned enhancements. You'll notice some things unrelated to the recent incident, since we were already planning a new release.
- Security enhancements. This is a mix of "making things harder for future attackers" and "I wonder if this could be exploited? Let's harden or remove it just in case"
Specific to the attack, one change “Create a Data API Key (File Credentials)” now requires specifying at least one database and a non-empty username and password, which means a threat actor can no longer stuff credentials and then check whether they worked for any files. This doesn't prevent listing, testing, and potentially exploiting poorly secured FileMaker files; it just makes it less easy.
The miscellaneous security enhancements address things we found that theoretically could facilitate future attacks. We reviewed the software with one question in mind: if I were a black hat with the power of AI, how could I exploit this? AI has changed the game. Looking through some of the logs, it was fascinating to see how the AI probed and mapped the attack surface, and then learned how to use the various APIs to further its attacks using anything it could find. One thing that surprised me was that it even attempted to exploit WebDirect.
What’s next
As a company, we are adopting a security-first posture, and you should expect future versions of OttoFMS and all of our tools to reflect this. Many of our tools remained offline until we were confident in the security enhancements that were made, and some features may be missing until we can find ways of re-implementing them safely. But security is a shared effort, and we will continue to help our customers understand the vulnerabilities in their own systems and how to mitigate them. One customer noted, “in many ways, you’re the best company to help us with security because you truly understand the nature of the threats.”
If nothing else, this experience has shown one thing to be true: FileMaker is no longer "obscure," and the sense of safety from that perceived obscurity is a false one. This was a targeted attack, hitting every major FileMaker hosting provider worldwide. What’s novel is the role of AI in creating an exploit tool that was adaptable on the fly. But it had a familiar target: poorly-secured databases with over-privileged accounts, files with default credentials or no credentials at all, and accounts with unnecessary services enabled. Claris and Soliant put out similar recommendations to ours, and they’re best summed up as, "Lock your files, lock your servers, and lock your networks."
