Depuis la fin du mois d’octobre 2026, de nombreux opérateurs (dont Claris) signalent une recrudescence d’attaques automatisées visant les serveurs (incluant les Serveurs FileMaker) directement accessibles depuis Internet.
Il ne s’agit pas d’une faille du logiciel Claris : ces attaques exploitent des réglages de serveur trop permissifs et des mots de passe faibles. Cet article résume ce que l’on sait de cette campagne, la façon dont elle procède, et les mesures de protection recommandées par l’éditeur.
Une campagne d’attaques en cours depuis le 22 octobre 2026
Dans une publication de son support technique intitulée « Protecting FileMaker Server from Automated Attacks », Claris indique avoir observé une activité suspecte débutant aux alentours du 22 octobre 2026. Les attaquants scannent Internet à la recherche de serveurs exposés sur le port 443 (un port classique du web notmament utilisé par FileMaker Server), tentent de connaître les bases présentes sur ces serveurs, puis recherchent, pour chaque base hébergée, le point d’entrée le plus accessible : Data API, OData, XML, ODBC/JDBC, WebDirect, ou la console d’administration (Admin Console).
Claris précise explicitement que cette vague n’exploite aucune vulnérabilité du logiciel FileMaker Server : elle ne réussit que là où un serveur ou une base est configuré d’une manière qui laisse une porte ouverte.
Une telle attaque se défend avec les réglages standards de FileMaker Server.
Un serveur sans accès à Internet, ou placé derrière un VPN, n’est pas concerné : seul un serveur joignable depuis Internet peut devenir une cible potentielle.
A ce jour nous n’avons observé qu’une tentative, déjouée, sur un de nos serveurs gérés par Active Développement.
Comment procède l’attaque
D’après la description publiée par Claris, l’activité observée suit un déroulé en plusieurs étapes, sans qu’aucune d’entre elles ne repose sur une technique exotique : elles s’appuient sur des interfaces standards du serveur.
Repérage
Des outils automatisés sondent un grand nombre de serveurs à la fois. La tentative d’intrusion proprement dite peut intervenir plusieurs jours après ce premier repérage.
Lister les bases hébergées
Lorsque le réglage « Filter databases » (filtrage des bases) n’est pas activé, l’outil peut obtenir via la Data API la liste des bases hébergées par un serveur sans avoir besoin de s’authentifier au préalable.
Tenter l’accès
Pour chaque base identifiée, l’attaque teste d’abord l’accès invité (compte Guest), puis une liste restreinte de mots de passe courants sur les comptes existants.
C’est la technique dite du « password spraying », qui consiste à essayer un petit nombre de mots de passe fréquents sur un grand nombre de comptes et de serveurs. Les tentatives sur une base sans accès invité échouent et apparaissent comme des échecs d’authentification dans le journal d’événements du serveur.
Extraction en cas de succès
Lorsque l’accès invité ou un mot de passe faible fonctionne, l’outil se connecte via une interface programmatique et tente de lire les enregistrements accessibles depuis les tables et présentations ouvertes à ce compte.
Face à une telle situation une revue totale des jeux de privilèges peut être utile (par défaut la programmation autorise les acccès à un maximum d’informations à chaque privilège une fois connecté), y compris l’export de données et l’accès par API : même un jeu de privilèges en lecture seule suffit à exposer tous les enregistrements visibles par ce compte.
Les données ainsi récupérées peuvent inclure noms, adresses, téléphones et adresses email, de quoi alimenter ensuite une campagne de phishing usurpant l’organisation concernée.
Les bonnes pratiques recommandées par Claris
Claris propose une liste de vérifications pour fermer les points d’entrée exploités par cette campagne. Elles reposent sur des fonctionnalités standards de FileMaker Server, disponibles dans les versions récentes du produit.
Utiliser des mots de passe robustes et uniques
C’est la mesure la plus importante : Chaque base hébergée doit exiger un compte et un mot de passe. Claris considère comme non sécurisés : un compte Guest doté du jeu de privilèges Full Access, un compte Full Access sans mot de passe, ou un mot de passe mémorisé dans les options du fichier. Les mots de passe doivent être différents entre les comptes des bases, l’Admin Console, et les serveurs de développement et de production.
Supprimer l’auto-login et l’accès invité
Ce sont les deux points d’entrée les plus exploités. L’auto-login permet à quiconque atteint la base de se connecter avec le compte mémorisé automatiquement ; un accès invité, surtout associé à un jeu de privilèges par défaut, offre un accès sans aucune authentification. Si un accès invité doit être conservé temporairement, Claris recommande de lui associer un jeu de privilèges dédié et restrictif : impression et export désactivés, menus réduits au minimum, accès aux présentations limité. Une mesure présentée comme provisoire, pas comme une solution durable.
Activer le filtrage des bases hébergées
Ce réglage, accessible dans l’Admin Console (Configuration > FileMaker Clients), limite la liste des bases visibles à celles pour lesquelles l’utilisateur dispose déjà d’un compte, dans FileMaker Pro, FileMaker Go, WebDirect, et sur l’endpoint « Database Names » de la Data API. Combiné avec le réglage serveur DenyGuestAndAutoLogin, cet endpoint exige alors systématiquement des identifiants. Ce filtrage ne protège pas une base qui autorise déjà l’accès invité ou l’auto-login : il masque seulement les autres bases de la liste.
Désactiver les services inutilisés
Data API, OData, XML, ODBC/JDBC et WebDirect ne devraient rester actifs que s’ils sont réellement utilisés. Un contrôle rapide dans l’Admin Console (services activés, trafic réel dans les journaux) permet de couper ce qui ne sert pas, et de réduire d’autant la surface exposée sur Internet.
Restreindre l’accès à l’Admin Console
L’onglet « Restrict Access » de l’Admin Console permet de limiter son accès à des adresses IP précises plutôt que de le laisser joignable depuis tout le réseau. Claris recommande en complément un identifiant et un mot de passe propres à l’Admin Console, distincts de ceux d’un groupe d’authentification externe, et de les renouveler après tout incident suspecté.
Mettre à jour vers une version récente de FileMaker Server
Les versions à jour embarquent les derniers correctifs de sécurité et les réglages les plus récents, comme le drapeau serveur DenyGuestAndAutoLogin. Les notes de version officielles permettent de vérifier la version installée au regard de la dernière version disponible.
Mettre le serveur derrière un VPN ou un pare-feu applicatif
Un serveur uniquement joignable via un VPN n’est pas exposé à ce type d’attaque. À défaut, limiter au pare-feu les adresses IP autorisées sur le port 443, et envisager un pare-feu applicatif ou un limiteur de débit placé devant le serveur, réduit fortement le risque.
Pour aller plus loin
Cet article résume les recommandations rendues publiques par Claris. Pour le détail complet, la documentation officielle de l’éditeur reste la référence :
- Communiqué de Claris, « Protecting FileMaker Server from Automated Attacks » : support.claris.com/s/article/Protecting-FileMaker-Server-from-automated-attacks
- Claris FileMaker Security Guide (guide de sécurité officiel) : help.claris.com/en/security-guide
- Réglage « Filter databases » : help.claris.com/en/server-help/content/config-client-filter-databases.html
- « Require passwords for hosted files » : help.claris.com/en/security-guide/content/require-passwords.html
- Restreindre l’accès à l’Admin Console : help.claris.com/en/server-help/content/restrict-access.html
- Notes de version de FileMaker Server : help.claris.com/en/server-release-notes
Comme pour toute campagne de ce type, la meilleure protection reste de vérifier, sans attendre un incident, la configuration réelle de son serveur et de ses bases au regard de cette liste.
