FileMaker Server Security Check Skill
Updated: 8 minutes ago
The Latin root of 'secure' is securus : se (without) and cura (care). Without care. That's an uncomfortable framing for a FileMaker Server, because a server set up without care is exactly what the automated attacks go looking for.
Yet very few of us set out to build a server without care. We install FileMaker Server, host the client's files, and it works. Then the next project starts. I've spoken with Developers who host servers for their clients and had no way of knowing which settings were letting them down. Not careless. Busy. And quietly relying on obscurity: a small client, a niche platform, a server nobody would bother with.
Claris has warned about a wave of automated attacks on FileMaker Server. Claris dates the activity from around 22 October, and notes that probing can come days before the real attempt, so check your logs from mid-October. Any server reachable from the internet is a target. The tools scan for port 443, then look for the easiest way into each hosted file through whatever answers: the Data API, OData, XML, ODBC, JDBC, WebDirect or the Admin Console. What they take is the everyday data in most FileMaker solutions: names, addresses, phone numbers and email addresses. Claris notes that's enough to impersonate your organisation in a phishing attack. A server with no internet access, or one reachable only through a VPN, isn't exposed.
So I built a FileMaker Server security check that brings what you need to know into one place, and does the checking for you. It's a Claude skill called cadenceux-fms-security, built from security reviews of production servers during that wave and from Claris's own guidance, and it's free on GitHub. It's one skill, offered as is, and it doesn't replace a professional assessment. More on that below.
In this post:
The Knowledge Nobody Keeps in Their Head
Securing a FileMaker Server isn't hard. Knowing what to check is.
The answers are spread across Claris's article on the automated attacks, the FileMaker Security Guide, the ports article, Server Help, the release notes, the National Vulnerability Database and CVE.org. Then there's the evidence on your own server: the Access, Event and API logs, thousands of lines each.
None of it stays still. A new CVE is published, or Claris adds a security fix to a release note. In the language of my Knowledge Delegation post, that's the perishable pile: true today, worth rediscovering tomorrow, and not worth carrying in your head between projects.
The skill carries it instead. Every source it checks against is listed at the end of this post, so nothing it tells you rests on its word alone.
Why Obscurity Stopped Working
For years, plenty of FileMaker Servers have leaned on being small and unknown. That only works if someone is choosing their targets, and nobody is.
The automated tools probe servers in bulk, and Claris notes the real attempt can follow days after the first probe. They find whatever answers on port 443 and ask each one for its file list, the same questions of every server. A small client isn't skipped, and neither is a niche platform: the tools already speak FileMaker.
Ottomatic. The team at Proof took every server Ottomatic hosts offline after a coordinated attack on FileMaker servers. It began by probing files with weak security, then escalated to the servers around them. Their brief describes password spraying against the Admin Console, Data API, OData and XML endpoints on servers worldwide, and says OttoFMS wasn't the cause. Proof is treating every Admin API key on Ottomatic servers as compromised, and the Data API and OData keys too wherever OttoFMS Webhooks were used. If you host there, replace yours. Credit to the Proof team for publishing it in the open.
Being unknown helped while finding you took effort. Now it takes a scan.
Nowhere Left to Hide
Obscurity wasn't the only cover to go in October. Three more incidents took away places Developers assumed were safe: the web software around the server, the portal clients log in to, and the Developer's own machine.
PHP, and the 70%. Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, allow remote code execution on unpatched servers. PHP is reportedly used by some 70% of web-facing servers, AI tools helped find the flaws, and within a week the US government's CISA said attackers were exploiting them. The Canadian Centre for Cyber Security alert lists the fixed releases.
Quest Diagnostics. The same week, the US lab-testing giant found unauthorised access to Quanum, the portal its healthcare clients use to order tests and look up results, and believes "certain patient records" were accessed. Quest paused the portal, hasn't said how the attackers got in, and told the AP it wasn't the PHP flaw. A portal where outside clients place orders and read results is the same shape as the WebDirect and Data API front ends many Developers build for their clients. A big name didn't hide it.
Claude Code in Cursor. For several hours, Cursor's extension marketplace carried a tampered copy of the Claude Code extension that tried to plant an SSH backdoor on developer machines. Cursor says those versions weren't developed by Anthropic. The target wasn't a server. It was the Developer's own machine, through a tool the Developer trusts.
Which begs the question: what's left to hide behind? Attack tools list your files for you, AI finds flaws faster than any of us can patch by hand, and the Developer's laptop is now on the list. Security through obscurity is no longer an option for the Claris FileMaker Community.
Delegate the Checking, Keep the Judgement
The same tools cut both ways. Agents are being deployed to attack FileMaker Servers, so deploy your own Agents to scan and protect them. This is Knowledge Delegation in practice.
What you delegate. The perishable pile: every port and web path, the Admin Console settings that matter, the accounts and privileges in every hosted file, the published CVEs for your exact version, and thousands of lines of access and event logs.
What you keep. The durable pile: what normal looks like on your server, which services your client actually uses, who an address belongs to, and whether a fix is really fixed.
The skill is built around that split. It asks which services are meant to be reachable before it judges anything, and who an address belongs to before it calls anyone an attacker. It finishes with a re-test, because expected is not verified.
One Skill, Not a Security Audit
Delegation has a limit, and this is it.
This is one skill. It runs a set of automated checks: the host from outside your network, the server's settings, the hosted files from their SaXML exports, and the server logs. The skill then writes one report.
I need to be really clear: the skill does not replace a security assessment by professionals, and a clean report is not a promise that your server is safe.
The skill is offered as is, with no guarantee of any kind and no support. You run it at your own risk, and only against servers you own, manage or have written permission to test.
Every report it writes carries the same note at the top.
The Attack, Step by Step, and Where the Skill Looks
Claris describes the pattern in Protecting FileMaker Server from automated attacks. Each step has a setting that stops it, and a check in the skill that finds it:
List the files. The tool asks the Data API for the hosted file list, which needs no sign-in unless Filter databases is on. The exposure check asks the same question from outside your network.
Try each file. Guest, auto-login (File Options > Open > Log in using), or a default Admin account with no password. Claris names Guest and auto-login as the two biggest ways in. The file audit reads each hosted file's Save a Copy as XML export for Guest, auto-login, default and generic accounts.
Spray passwords. Common passwords at generic account names, a few tries at a time from rotating addresses. FileMaker locks a file account for five minutes after five failed sign-ins, and spraying stays under that. The log review looks for the bursts, and the admin review checks who can reach the Admin Console.
Take the data. Records pulled through the Data API, 200 at a time, across every layout the account can reach. The log review looks for bulk downloads through the Data API or OData, and the file audit flags extended privileges an account doesn't need, including fmxml, fmrest and fmodata on [Full Access], which Claris says should be off.
No FileMaker Server flaw is involved. Every step works through configuration. Let that sink in. Steps 2 and 4 leave no failed sign-in, so a clean failed sign-in count proves nothing.
That makes the logs the evidence, and they don't last. The web-server log often keeps only the current day, and on a busy server Access.log may cover a couple of weeks. Turn on Top Call Statistics in Logs > Log Settings now: it's off by default, and it shows the heaviest record reads. Copy the logs off the server daily and keep at least 90 days. Then run one simple test: did any address behind the failed sign-ins later sign in successfully?
Five Python scripts do the heavy lifting, standard library only. In Claude Code, Claude runs them for you. In Claude.ai or the Claude desktop app, Claude gives you the commands and reads what you paste back. The skill never tries passwords or runs aggressive scans, and never asks for a password, API key or token.
Plan for When, Not If
One of my earliest, and wisest, mentors put it plainly: it's not 'if' a server gets hacked, it's 'when'. That 'when' could be this week, or next week . . .
Everything above keeps attackers out. How bad the day turns out is decided earlier, by the work done before the attack: a clear Disaster Recovery (DR) plan, agreed with the person who owns the data.
I've always told clients to back up as much as they're willing to lose. Security works the same way: set it up for the amount of time you're prepared to be down.
How much data can the owner lose? That's the gap between the last clean backup and the attack: an hour, a day, a week. The data owner sets it, not the Developer, and the backup schedule follows from their answer.
How long can the server be down? Containing the attack, preserving the logs, restoring files, rotating every password, closing the gaps and re-testing all take time. If the owner expects the server back by the afternoon, the plan, the DR server and the people have to be ready before the attack, not during it.
Where's the clean copy? Claris advises keeping at least one backup copy on a separate system that isn't reachable from the server's network, and testing a restore. A backup the attacker can reach is part of the attack. Make at least one copy versioned or immutable, so the server's own credentials can't delete it, and keep the Encryption at Rest passwords and admin credentials in a password manager, so a restore never depends on the old server. My FileMaker Disaster Recovery (DR) post covers the 3–2–1 rule and restore testing in more depth.
Who does what, and in what order? Contain first: Block New Users, block port 443 at the firewall except for known addresses, and close any file that uses Guest or auto-login. Expect that to stop WebDirect and API users too, so decide beforehand how the work carries on, even if it's a temporary form and a CSV import. Then copy the logs off the server, work out what was read, rotate credentials and reopen. If personal data may have been read, treat every record on the layouts that were read as exposed, and bring in whoever owns privacy for the organisation straight away. In Australia that's the Notifiable Data Breaches scheme, which expects an assessment within 30 days of suspecting a breach.
Example: One client's only off-site backup was four weeks old when a fire hit their office. A fire and an attack ask the same question: how much can you lose?
The skill helps on both sides of the day. The server configuration review flags a server with no off-network backup or untested restore, and if the evidence points to an attack under way, the skill switches to containment steps in that order. The expectations are a different matter. How much the owner can lose, and how long they can be down, sit firmly in the durable pile. No Agent can agree them for you.
Examples From a Sample Report
I ran the check early in November against my own FileMaker Server 26 in Docker, the same setup as my FileMaker Server via Linux Docker post, this time with ODBC/JDBC turned on. The report is written for the person who owns the server, not for a FileMaker specialist, so it's one you can hand to your client. It opens with a summary:
Result. 🟢 No sign of attack
To fix. 3 Critical · 3 High · 4 Medium · 1 Low · 5 to check
Then What to fix, one finding and one action each:
🔴 Critical: the file signs in anyone who opens it with a full-access account (auto-login). In File > File Options > Open, untick Log in using.
🔴 Critical: anyone who can reach the server can see the name of your data file without signing in. In the Admin Console, Configuration > FileMaker Clients, turn on Filter databases, then turn on Deny Guest and auto-login.
🟠 High: the Admin Console sign-in page opens for any address that can reach this Mac. Publish the container's ports on 127.0.0.1 only, or in Administration > Restrict Access, allow only your own address.
🟡 Medium: all four FileMaker ports (80, 443, 5003 and 2399) answer on every network address of this Mac. Anyone on the same Wi-Fi or office network can reach the server. Publish the ports on 127.0.0.1 only, or allow-list your own addresses.
🟡 Medium: the file's privilege sets allow XML and PHP, which are off on the server, plus the Data API, OData and ODBC (fmxdbc) for a set no named account uses. In Manage > Security > Extended Privileges, untick each one nobody uses.
Example: Port 2399 answered from outside the container, and inside it the check confirmed ODBC/JDBC was really listening. A port is judged by what answers on it, not by whether it connects.
The report also shows What passed, because a report of only problems reads as worse than the server is:
Local-only FileMaker ports. ✅ All 16 closed, including 16000–16004, 1895 and 5013
Remote management. ✅ SSH, Screen Sharing, Remote Desktop and WinRM all closed
Admin API. ✅ Refuses requests without a sign-in
Known security issues. ✅ None published for this server version (checked live against NVD)
And it says what it didn't check. Every test ran on the same Mac, so the report says so and explains how to check what other devices on the network can reach, rather than passing it by silence.
Live CVE Checks From NVD and Claris
CVEs are the most perishable part of the pile, so the skill never relies on memory for them. On the first request of a session, it fetches FileMaker CVEs live from the National Vulnerability Database (NVD), merges in the security fixes Claris lists only in its release notes, and matches them to your exact version. Offline, it falls back to a dated built-in list and says how old it is.
python3 scripts/fms_advisories.py 22.0.3For a server on 22.0.3 that lists ten published issues, highest CVSS first, each with the release that fixes it and the Claris article behind it. Where NVD names a fix only on a newer line, the skill says exactly that, rather than guessing whether your line is affected.
It also reads the FileMaker Pro builds that connect to the server from Access.log, and lists staff computers to update.
How Claris ADT Enhances the File Audit
The file audit reads Save a Copy as XML exports. That needs nothing beyond FileMaker Pro and a [Full Access] account, which is the point: any FileMaker Developer can run it today.
python3 scripts/fms_file_audit.py <folder of .xml exports>An export has one blind spot. It stores a salted hash of each password, so it can't tell you whether a password is blank. Without ADT, the skill closes that gap instead of testing it: reset every password nobody can vouch for, and the report marks blank passwords 'not verified; closed by resetting'.
The Claris Agentic Development Toolkit (ADT) fills that gap. When ADT is already installed, the skill uses its fm-cli skill to read accounts, privilege sets and extended privileges straight from the hosted files over fmnet://. ADT reports whether each account has a password at all, so blank passwords get a real answer. ADT signs in with its own stored credentials, so no password passes through the chat.
The export still does the rest of the file audit: Encryption at Rest, reference protection, and passwords typed into script steps. ADT is optional. The skill never asks you to install it for this check.
How to Download and Install the Skill
The skill lives at github.com/CadenceUX/cadenceux-fms-security-skill. Pick the route that matches how you use Claude.
Claude Code. From the cadenceux plugin marketplace:
claude plugin marketplace add https://github.com/CadenceUX/cadenceux-skills.git
claude plugin install cadenceux-fms-security@cadenceuxClaude.ai and Cowork. Customize → Plugins → Add marketplace from GitHub → CadenceUX/cadenceux-skills, then install cadenceux-fms-security.
Claude desktop app (macOS). Download cadenceux-fms-security.skill and double-click it.
Claude.ai in a browser. Customize → Skills → upload cadenceux-fms-security.zip.
Note: Don't use GitHub's green Code → Download ZIP button or a release's Source code (zip). Those are snapshots of the repository, not a packaged skill, and Claude won't install them as one.
Beyond Claude. Every skill I publish follows the open Agent Skills standard, and goes beyond it with plugin, marketplace and release packaging. Anthropic developed the format and released it as an open standard, and a growing list of agent products now read it. You're welcome to use my skills in your chosen supported harness, against your chosen model. I build and test them with Claude, so anything else is yours to check: the skills are released as is . . .
The Cursor incident applies here too. Install skills from their own repository or release, and read what a skill's scripts do before you run them. These ones are plain Python, standard library only, so that read is quick.
Then ask Claude in plain words: 'Security-check my FileMaker Server at fms.example.com.' It starts with intake, and asks you to confirm you're authorised before it touches anything. Run the exposure check from outside the server's network, and keep the report private. It names accounts, addresses and weaknesses.
This is released under CC BY 4.0. Use it, fork it, adapt it. Attribute it.
Claris and CVE References
This is the pile the skill carries for you, and the sources its facts are checked against:
Protecting FileMaker Server from automated attacks (Claris KB 000049228), whose checklist also covers VPNs, Remote Desktop, a WAF and Encryption at Rest
Community Live 53a: Lock down your FileMaker Server now (Claris, 29 Oct 2026)
FileMaker Security Information (Claris)
Ports used by FileMaker Server (Claris KB 000026067)
National Vulnerability Database (NVD), where the skill fetches FileMaker CVEs live
CVE.org search for FileMaker, the CVE Program's own records
And the incidents above:
FileMaker Systems Attack Brief, October 2026 (Proof, on Ottomatic)
Critical vulnerabilities impacting PHP (Canadian Centre for Cyber Security, AL26-026)
Lab testing giant Quest Diagnostics confirms patients' personal and health data was compromised during breach (TechCrunch)
Quest Diagnostics reports cyber breach affecting 'certain patient records' (The Associated Press)
Security notice: malicious version of the Claude Code extension in the Cursor marketplace (Cursor)
Takeaway
Securus: without care. The servers these attacks find weren't necessarily set up without care. More often they were set up without the full picture, then left to obscurity, and obscurity no longer hides anything.
The full picture now sits in one place. Delegate the checking to an Agent, keep the judgement, and the care comes back to you.
And because it's 'when', not 'if', agree with the data owner how much they can lose and how long they can be down, before an attack decides it for them.
It's still one skill. It doesn't replace a security assessment by professionals, and it comes as is. Run it, fix what it finds, and run it again.
More to come . . .
Comments