On August 6, 2026, FlyWP identified a large-scale security incident affecting FlyWP infrastructure and more than 700 customer servers and the WordPress sites hosted on them. Our security and engineering teams immediately activated our incident-response process and began containment, investigation, remediation, and recovery.

Our investigation identified the primary access path: an administrator account associated with a former FlyWP employee remained active after the employee left the company. The account retained permission to push SSH keys onto customer servers. The account was subsequently compromised and used by the attacker to access affected FlyWP infrastructure.

We also identified a separate access-control failure involving our marketing infrastructure. Our marketing site held Cloudflare R2 credentials with read access to a bucket containing FlyWP production database backups. The attacker obtained those credentials and downloaded a FlyWP production database backup.

The downloaded backup contained customer data. Sensitive credentials, tokens, and secrets stored in the database were encrypted, and the encryption keys were stored separately. We have no evidence that the attacker was able to decrypt those values. Nevertheless, because the backup was downloaded, we treated it as exposed and rotated every credential contained in it.

The incident is contained, affected infrastructure has been restored and validated, and FlyWP has been operating normally since August 9, 2026. Additional monitoring, security hardening, and post-incident forensic work remain ongoing.

At-a-Glance Incident Summary

Incident detected	August 6, 2026
Containment & remediation	August 6–8, 2026
Affected infrastructure	700+ customer servers and the WordPress sites hosted on them
Primary root cause	A former FlyWP employee’s administrator account was not deactivated during offboarding and was subsequently compromised.
Additional security failure	Marketing infrastructure had R2 credentials with read access to production database backups
Production database backup	Accessed and downloaded by the attacker
Customer data in backup	Customer data was present; sensitive credentials, tokens, and secrets were encrypted, with encryption keys stored separately
Customer environments	Attackers gained SSH-level access to affected environments
Observed attacker activity	SSH key installation, WordPress administrator creation, hidden plugin installation, remote command execution capability, site discovery, and search-result cloaking
Magic Login	Disabled during containment, redesigned and security-hardened, then re-enabled August 18
Current status	Incident contained; FlyWP operational; additional monitoring and hardening ongoing

What Happened?

Initial Access

Our investigation identified the primary access path: an administrator account associated with a former FlyWP employee remained active after the employee left the company. The account retained permission to push SSH keys onto customer servers.

The account was subsequently compromised and used by the attacker to access affected FlyWP infrastructure.

We know which account was compromised, what permissions it held, and how those permissions enabled access. We do not yet know how the credentials for the former employee’s account were originally obtained, and that part of the investigation remains ongoing.

This was an internal access-management and offboarding failure. It was our responsibility, and we have taken steps to strengthen access controls and prevent similar situations in the future.

Security Incident Timeline

Incident window: August 6, 2026, 12:09:39 UTC – 18:22:00 UTC.

All timestamps below are UTC and based on platform, application, and forensic logs.

12:09:39 — First confirmed indicator

A password reset request was submitted against an unprivileged account. This is the earliest confirmed indicator of the account-takeover activity.

12:11:52 — First confirmed unauthorized account access

The attacker successfully authenticated to the internal unprivileged account and generated an API key. The key was not used for state-changing operations; the observed activity was limited to enumeration.

12:16:32 — Infrastructure reconnaissance

A path-traversal attempt was recorded against our infrastructure. Subsequent forensic review identified this as reconnaissance and capability testing.

14:00:59 — Administrative account compromised

Forensic analysis confirmed that the attacker obtained access to the administrative account used for the subsequent intrusion activity.

14:39:58 — First confirmed access to a customer server

The earliest confirmed unauthorized access to a customer server occurred at this time.

The attacker began:

• Enumerating SSH keys already installed on customer servers.
• Adding attacker-controlled SSH keys.
• Observing platform activity and behavior.

17:10 — SSH key additions at scale

The attacker began adding SSH keys to customer servers at scale using the compromised administrative account.

17:57 — Attack identified

Our team identified the activity as an active attack and immediately activated the incident-response process.

18:22 — Containment

Access was revoked for the compromised account and other associated accounts identified as compromised. The compromised account and associated access mechanisms were revoked, and the immediate attack activity was contained.

What the Attacker Did

On affected servers, our investigation identified activity including:

• Installing unauthorized SSH keys.
• Creating WordPress administrator accounts.
• Installing hidden WordPress plugins.
• Placing PHP files capable of remote command execution.
• Placing files used for search-result cloaking and SEO manipulation.
• Performing automated discovery of sites hosted on affected servers.
• Maintaining unauthorized access through authentication mechanisms, including Magic Login during part of the incident.
• Accessing and downloading a FlyWP production database backup through exposed R2 credentials.

Two malicious files identified during the investigation included:

Malicious Files

_wphe_payload.php
_cloak_payload.php

These files were removed during remediation.

Because attackers obtained SSH-level access to affected servers, anything readable by the relevant server or system accounts may have been accessible. Depending on the environment, this could include wp-config.php, .env files, database credentials, Stripe credentials, SMTP credentials, third-party API tokens, WooCommerce data, and other application data.

Production Backup Access

Our investigation identified a separate access-control failure.

Our marketing site held Cloudflare R2 credentials that could read a bucket containing FlyWP production database backups. A lower-trust marketing environment therefore had access to production backup data that it did not need.

The attacker obtained those R2 credentials and downloaded a FlyWP production database backup.

The backup contained customer data. Sensitive credentials, tokens, and secrets stored within it were encrypted, and the encryption keys were not stored alongside the backup. We have no evidence that the attacker was able to decrypt those values.

We nevertheless treated the downloaded backup as exposed and rotated every credential contained in it.

Who Was Affected?

The incident affected 700+ customer servers and the WordPress sites hosted on them.

We reviewed affected environments individually and swept them for unauthorized access mechanisms, malicious files, and other indicators of compromise.

We identified the affected customer environments, and affected customers were notified directly with information about their affected server(s).

Customers who did not receive an affected-environment notification can use that communication as an indication that their environment was not identified as part of the affected set.

What Customers Should Do

The recommended actions depend on whether your server was identified as affected.

If Your Server Was Affected

Treat everything readable from that server as potentially exposed.

We recommend rotating:

• SSH keys
• Database credentials
• WordPress administrator passwords
• Application passwords
• Deployment credentials
• .env and application secrets
• SMTP credentials
• Stripe and payment-provider credentials
• Cloud/server-provider credentials
• FlyWP API tokens
• Other third-party API tokens

Also review and rotate credentials or authorization associated with:

• Cloudflare
• GitHub
• SMTP providers
• Backup providers
• ManageWP
• Social login providers
• Other services whose credentials were stored on the affected server

Review Your WordPress Sites

Check for:

• Unexpected administrator accounts
• Application passwords
• Unknown plugins or themes
• Recently modified files
• Unexpected PHP files
• Scheduled tasks and cron entries
• Unexpected redirects
• Search-engine behavior
• Google Search Console activity
• Unusual login activity
• Unexpected emails, orders, or transactions

If you use WooCommerce, also review recent orders and customer activity for anything unusual.

If Your Server Was Not Affected

You do not need to perform a broad credential reset solely because of this incident.

We still recommend maintaining normal security practices:

• Review administrator accounts.
• Review application passwords.
• Keep WordPress, plugins, and themes updated.
• Review unusual files or redirects.
• Monitor login activity.
• Rotate credentials if you identify suspicious activity.

What About Backups?

Customers should not assume that restoring an older backup automatically removes the risk.

If a backup was created from an affected environment after malicious activity occurred, restoring it could reintroduce compromised files, administrator accounts, plugins, SSH keys, or other unauthorized access mechanisms.

Before restoring a backup from an affected server:

1. Identify when the backup was created.
2. Determine whether that date falls within the potential compromise period.
3. Validate the backup for unauthorized files, users, plugins, and access mechanisms.
4. Rotate credentials after restoration.
5. Re-scan the restored environment before returning it to production.

If you are unsure which backup is safe to restore, contact FlyWP Support.

What We Did to Contain and Remediate the Incident

Once we identified the incident, our priority was to stop unauthorized access, protect customer environments, and restore affected infrastructure safely.

We:

• Revoked unauthorized access mechanisms.
• Disabled affected authentication paths.
• Terminated active sessions where necessary.
• Disabled Magic Login during containment.
• Rotated authentication salts and relevant credentials.
• Rotated FlyWP API credentials.
• Rotated credentials contained in the downloaded production database backup.
• Reviewed affected servers individually.
• Removed malicious files and payloads.
• Removed unauthorized SSH keys and other access mechanisms.
• Reviewed SSH access.
• Removed unauthorized WordPress administrator accounts and plugins where identified.
• Applied required security updates.
• Hardened affected infrastructure.
• Validated remediated environments before restoration.
• Added additional post-incident monitoring.

By August 8, we had restored and validated the affected infrastructure. By August 9, the immediate incident response and remediation work had been completed, and FlyWP returned to normal operation.

What Happened to Magic Login?

We disabled Magic Login globally during the incident as a precautionary containment measure.

During our investigation, we determined that the attacker was able to retain access through Magic Login after the initial access sweep. We therefore kept the feature disabled while we investigated and redesigned the authentication mechanism.

We then:

• Rotated relevant authentication secrets.
• Terminated active sessions.
• Hardened access controls.
• Redesigned the affected authentication flow.
• Added additional validation and monitoring.
• Performed additional security testing.

Magic Login was re-enabled on August 18, 2026, after these security measures and validation were completed.

What We Changed

This incident exposed two specific failures that required architectural and process changes.

Automated Offboarding & Access Reviews

We are moving away from relying solely on manual offboarding.

Employee access is being reviewed and strengthened so that account deactivation and permission removal are enforced as part of the offboarding process. We are also increasing the frequency and scope of privileged-account reviews.

Scoped Backup Credentials

We removed the previous broad access model and are restructuring backup credentials so that low-trust application infrastructure cannot access production backups unless explicitly required.

Production backup access is being isolated and scoped according to least-privilege principles.

Hardened Team RBAC

We strengthened Role-Based Access Control for FlyWP team members to provide more granular control over which users can access specific resources and perform privileged actions.

Activity Logs

We introduced Activity Logs to provide greater visibility into actions performed within FlyWP and make it easier to identify and investigate unexpected activity.

Support PIN Verification

We introduced Support PIN verification to add an additional layer of protection when customers interact with FlyWP Support.

FlyWP Plugin Security

We forced an update of the FlyWP Plugin across affected environments to ensure affected sites were running the latest secured version.

Authentication Hardening

We rotated relevant authentication secrets, strengthened access controls, and redesigned Magic Login before re-enabling it.

Monitoring & Detection

We expanded monitoring and post-incident review so suspicious activity can be detected and investigated more quickly.

Indicators of Compromise

We are publishing the confirmed indicators that technical customers can use to investigate their environments.

Known Malicious Files

_wphe_payload.php
_cloak_payload.php

SSH Public-Key Fingerprint

SHA256:x+Q5AMGF77+FRq2rEzz6SAnjiVH+6yYXxHZr2/rdOL0

Source IP Addresses

194.110.115.15
84.201.6.54

Malicious Plugin Location

wp-content/mu-plugins

Malicious Cron Entries

No malicious cron entries were detected.

File Hashes

d2c1ea5e5ad3b009f6dc1d01fb359eba06b5d5fdd2cc22af6810645bb3790919
f65d24f5de1a0365b14231f9fd301695913fb3f2ed3ee8d73c52082f5e319f31
bdfca77a9323e86f1b64992b284d406638cced9e2816480314808e0af950ad55
a3fd2367270d0facf6ea048c6b7463f7088b9c9152346f1c4cdb9553c38416fd

Frequently Asked Questions

Support for Affected Customers

We recognize that affected customers may need assistance reviewing their environments and rotating credentials.

Affected customers can contact FlyWP Support for help with:

• Reviewing affected servers.
• Identifying suspicious files or accounts.
• Rotating FlyWP credentials.
• Reviewing SSH access.
• Reviewing WordPress administrator accounts.
• Validating backups before restoration.
• Investigating suspicious activity.

Current Status

The incident is contained, and FlyWP is operating normally.

Affected infrastructure has been restored and validated. Additional monitoring and security hardening remain in place.

Magic Login has been re-enabled following additional security hardening and validation.

Our post-incident forensic review continues, including investigation into the earliest attacker activity, how the former employee’s credentials were obtained, and the remaining indicators of compromise.

If our investigation identifies material new information that affects customers, we will communicate it through the appropriate channels.

What We Learned

We identified two concrete failures.

First, we failed to fully deactivate a former employee’s privileged account during offboarding. That account retained a permission that allowed SSH keys to be pushed onto customer servers.

Second, we allowed a low-trust marketing environment to hold credentials capable of reading production database backups. That access was broader than it should have been.

We are addressing both failures through automated and enforced offboarding, stronger privileged-access reviews, scoped backup credentials, production-backup isolation, stronger RBAC, improved authentication controls, expanded activity logging, and additional monitoring.

Our Commitment to Security

We know that customers trust FlyWP with infrastructure that powers their websites and businesses. We take that responsibility seriously.

We are sorry for the disruption, risk, and concern this incident caused.

We failed to deactivate a former employee’s privileged account. We also failed to properly isolate production backups from a lower-trust environment. Those failures are ours, and we are accountable for fixing them.

Our commitment is straightforward:

Contain the incident. Be honest about what happened. Help affected customers secure their environments. Fix the failures that allowed the incident to happen. And make FlyWP more resilient as a result.

We will continue to provide updates when there are material developments from the ongoing forensic review.