External JS Tampered With in Apifox’s Public SaaS Desktop Client: Scope, Risks, and What Users Should Do

Apifox published an announcement on March 25 confirming that its public SaaS desktop client had dynamically loaded an external JavaScript file that was maliciously tampered with between March 4 and March 22, 2026. The company classified the incident as a supply chain attack.

The main concern here is not simply that “a website was compromised.” Once a desktop client includes an external online script in its execution chain, the risk reaches the user’s local machine directly. For development tools, a breach of this boundary typically has more serious consequences than an ordinary web script incident.

The Bottom Line

If you used the public SaaS Apifox desktop client between March 4 and March 22, 2026, the safest approach is not to wait and see, but to treat yourself as a “potentially affected user”:

1. Upgrade to 2.8.19 or later immediately.
2. Immediately rotate any sensitive credentials on your machine that may have been exposed.
3. Check sensitive local directories and history files.
4. Block the malicious domain apifox.it.com outright.

If you use Apifox Web or a self-hosted deployment, this incident does not affect you, according to the official announcement.

What Exactly Happened

According to the official announcement, the issue involved an external JS file dynamically loaded by the public SaaS desktop client. After being tampered with, the file contained malicious code and sent data to the domain apifox.it.com. Apifox stated that this malicious domain was hosted on Cloudflare at the time, existed for 18 days, and is now inaccessible.

More importantly, based on user feedback and security team analysis, Apifox believes there is a high likelihood that the tampered script read sensitive local files, such as:

• ~/.ssh/
• ~/.zsh_history
• ~/.bash_history
• ~/.git-credentials

If your development machine has stored SSH private keys, Git credentials, database passwords, cloud service Access Keys, or secrets in environment variables, this risk should not be dismissed as merely “theoretically possible.” Once this information is stolen, the downstream consequences often affect code repositories, servers, databases, and object storage—not just Apifox itself.

Who Should Prioritize Checking Their Systems

This incident does not mean “every Apifox user was compromised,” but the following users should act first:

• Anyone who used the public SaaS desktop client during the affected window
• Anyone who keeps SSH private keys on their local machine
• Anyone who has run commands containing secrets that were saved in shell history
• Anyone who stores credentials in git-credentials, plaintext environment variables, or script configuration files
• Anyone whose machine also connects to production systems, cloud resources, or customer environments

To put it plainly: the more your development machine can access, the more seriously you should take the potential consequences.

What Apifox Has Done

The official announcement says Apifox has completed an emergency fix, with two main actions:

First, it released the 2.8.19 patch and enabled automatic update notifications.

Second, it completely removed dynamic loading of external online scripts and switched to bundling them locally. This is important. The underlying problem was not just that someone abused a domain, but that “the desktop client allowed this online script execution path to exist at all.” Removing that path addresses the structural weakness rather than merely replacing the current malicious script.

What Users Should Do Now

1) Upgrade First—Do Not Delay

Upgrade the client to 2.8.19 or later first. This does not replace the checks below, but it at least closes the path for further exposure.

2) Take Credential Rotation Seriously

If you used an affected version during the relevant window, I recommend doing more than changing your Apifox password. Review all potentially related sensitive credentials across your development machine. Focus on:

• SSH private keys and related jump host credentials
• Git platform tokens and account passwords
• Database usernames and passwords
• Cloud platform Access Key / Secret Key
• Secrets stored in local .env files, scripts, or shell history

This is a hassle, but it usually costs less than investigating unauthorized logins and resource abuse afterward.

3) Check These Directories and Files

Focus your checks on:

• ~/.ssh/
• ~/.zsh_history
• ~/.bash_history
• ~/.git-credentials
• .env files, deployment scripts, and backup configurations in project directories

If they have contained real credentials, treat those credentials as “potentially leaked.” Do not gamble on it.

4) Block the Malicious Domain Outright

The official recommendation is to point apifox.it.com to 127.0.0.1. If you have not done so, add this entry to your hosts file:

127.0.0.1 apifox.it.com

Although the domain is now inaccessible, blocking it locally is still a low-cost precaution.

What This Incident Really Exposes

I think the most important lesson for the industry is not just about Apifox itself, but about a broader design issue:

A desktop development tool that can still “dynamically load external scripts online” is effectively extending the local machine’s trust boundary to a remote source.

Once that execution path is compromised, the impact is no longer limited to a frontend page. It may reach credentials, command history, and project configurations on the user’s machine that should never have been accessed. For an ordinary content site, this is malicious script injection; for a development tool, it can become a direct compromise of the development environment.

The lessons from this incident are clear:

• If something can be bundled locally, avoid injecting it online
• If you can limit dynamic loading, do not hand execution control to a remote source
• Development tool vendors must prioritize security boundary design, not just feature releases
• Developers should avoid scattering sensitive credentials across their machines

Final Thoughts

The announcement at least clarified several key points: the affected scope, the time window, the local files that may have been accessed, the fixed version, and recommended user actions. That is reasonably concrete. But for users, what matters is not whether they have finished reading the announcement—it is whether they have followed through.

If you used the public SaaS desktop client during those 18 days, the priority now is not more discussion. It is upgrading, checking your system, and rotating credentials.

Original article: Risk Advisory and Upgrade Announcement Regarding Tampering With an External JS File in Apifox’s Public SaaS Version