I see there is a webinar tomorrow (today is Wednesday, October 28, 2026) about the apparent problem that FileMaker sites (FMS, too?) are getting hacked.
Just wondering if anyone is experiencing anything like that and, if so, what the problem was and how you addressed it.
Our servers seem fine, no issues.
Thanks guys,
Hi Oliver,
Yes—there is an active, coordinated global campaign targeting internet-facing FileMaker Servers right now (which began escalating around October 22).
Even if a server looks normal on the surface, attackers are running automated password-spraying and endpoint probing against the Admin Console, Data API, OData, and XML endpoints, as well as attempting to pivot into surrounding infrastructure and log files.
Proof published a detailed incident brief yesterday explaining the scope of the attack after they had to take their Ottomatic hosting fleet offline on October 25 as a protective measure: FileMaker Systems Attack Brief, October 2026 | Proof
Key takeaways & immediate steps even if your server seems fine:
Access.log: Don't rely solely on server performance—check your logs for bursts of failed login attempts or repeated probes from unfamiliar IPs. (David Hind-Smith also just shared a free community tool at https://www.hind-smith.com/Oddity/ that includes a FileMaker log checker to scan for brute-force attempts).[Full Access] and API service accounts for strong, unique passwords.Definitely worth checking your logs today—many servers are being actively probed without triggering obvious downtime. Stay safe!
thank you!
fmcloud.fm has experienced attacks on multiple servers recently, some random, some not so random. Some systems got breached, in large part because customers allowed guest access to services that shouldn't have guest access.
Note that FileMaker's security is actually quite solid. User errors and weak passwords are being probed and exploited. Note also that some recommendations given by Claris are not practical for public facing servers.
I checked the access.log and found absolutely nothing of concern on a public-facing AWS FMS 21 server. We do plan to upgrade the server to 22 shortly but were going to do that anyway.
We use WebDirect and the DataAPI, but no Web Publishing.
I watched the webinar presentation today, Wim Decorte presented a diagram of calls from outside peaking at some time, 
.
They suspect that AI agents were used to put together these attacks. Claris has high volumes of robots consulting help files and KB files to learn how FileMaker/Server work. And the AI was used to create code to attack FMS Servers. Wim opinion is those massive attacks may go on for 18 months.
I suggest all FMS owners to download the recording of the presentation and watch it carefully to protect your data.
Or upgrade to FMS 2026 which apparently doesn't suffer from these vulnerabilities as I read it.
On a server I manage, the FileMaker Data API is off (Admin page / Connectors / FileMaker Data API: Disabled)
However under Plug-Ins, I notice the FileMaker Data API Plug-ins are Enabled (Admin page / Connectors / Plug-Ins / FileMaker Data API Plug-ins).
Is that a secure setting or should I also disable the Data API Plug-Ins too?
Is there anything written about this? The youtube video (Link ) is over an hour long...
I didn't watch the video (who has time when just a white paper or simple posting will do fine), but I did see a posting about this. If I can find it, I'll post a link.
Well, the issues they addressed are not about PHP old versions or node.js - not minimizing those, but about trying to get inside FMS to get inside FileMaker Apps and try to log in and browse data to see if there is something of interest. They pointed out security holes inside apps that may help them break-in like :
They gave advises on how to harden the security of FMS and apps.
These are issues that appear in the mail that they have been sending. I think it's great that they took the time to produce the video. I also agree there should be a white paper which they can use as a document reference.
All of the things they are suggesting are best practices that are always recommended. If you haven't already been doing these things, start straight away.
Search for: /fmi/webd/ +guest to see that this issue isn't really new with AI. It's just that AI lowers the bar for attackers to nothing more than a prompt.
By the way, when I do prompt Claude with that search it slaps my wrist. It says, "I won't run this search. A /fmi/webd/ guest query is a way to find live FileMaker WebDirect servers that accept guest logins."
If you aren't allowing Data API access then disable plugins. It shouldn't make a difference but it's a toggle switch so there is no overhead in being safe.
What's wrong with DataAPI (security wise) if you use a strong FM password?
It would seem this should be relatively safe.
However,
curl https://example.com/fmi/v1/data/databases/
will return a list of open databases, which is something of a security leak.
The solution to this is reportedly to turn on Filter Databases in the admin panel / Configuration / FileMaker Clients.
This is a bug-bear of mine. The leaking of names gives hostile visitors information that can be used to strengthen the attack. So preventing that is a good thing.
The annoyance is that filter databases setting adds overhead for clients using FileMaker accounts (rather than other authentication methods) who must login to the server then login to application - if the developer doesn't provide them a simpler route.
The easiest way to reduce the friction is to reduce the security on the server - not a good outcome!
We've always used filter databases on our cloud hosted FM servers and the curl does result in a 404 error. However, we've been analysing our server logs and had a Data API probe in late August, that managed to 'guess' the names of some hosted FileMaker files, followed by a burst of about 70 POSt sessions, which all failed with an 802 error. So it would appear that filter databases isn't 100% effective at hiding file names.
@AndyHibbs, did these files have common names? A probe would try a bunch of common names, including the names of everything in the templates area and the sample database.
Malcolm, it was slightly unusual. The names of the files were very different, one of them was exposed to WebDirect and thankfully none had the Data API or OAuth extended permissions enabled. The server is our SBA server, so cohosting does take place on this and none of the other unrelated files were 'guessed'. I'm intrigued how the filenames could have been guessed, whether it picked up on a file name from WebDirect and could then search by wildcards based on a this?
Where possible we have now restricted access to known IP addresses, but this is of no use to mobile users or commerce. Worrying times!
How did you restrict access to known IPs?
In AWS, for example, you can do this using their firewall tool. But this tool is not good for lots of users and fine-grained access.
Looking forward to hearing how you do this access restriction.
Thanks,