March 10th, 2026 Incident: FAQ

On March 9, 2026 at 19:28 UTC, a malicious actor impersonated an AppsFlyer administrator at our domain registrar and convinced the registrar’s support team to reset domain access credentials and authentication controls, including removing multi-factor authentication. Through that access, on March 9th, 2026, 23:26 UTC, the attacker modified our domain configuration, which caused disruptions across appsflyer.com and its subdomains.

AppsFlyer’s internal monitoring detected the anomaly at 00:22 UTC on March 10, and our teams worked quickly with the registrar to restore control of the domain. During the incident window, starting with 00:31 UTC, traffic for websdk.appsflyer.com was redirected to attacker-controlled infrastructure and a modified Web SDK was temporarily served to some website visitors.

All services were fully restored by 09:47 UTC on March 10.

Yes. The incident is fully resolved. Control of the appsflyer.com domain has been restored, and all AppsFlyer services are operating normally.

No. This incident did not originate from a compromise of AppsFlyer’s internal systems, infrastructure, or credentials, and no AppsFlyer employee was involved in or responsible for this incident. Our investigation confirmed that the incident resulted from an attacker impersonating an AppsFlyer administrator at our domain registrar, and convincing the domain registrar’s support team to reset domain access controls and authentication settings. This allowed temporary modification of the domain configuration outside of AppsFlyer’s infrastructure.

No. This was not a ransomware attack. No malicious code was deployed on AppsFlyer’s systems, no data was encrypted, and no extortion demand was received.

The attacker’s identity remains under active investigation. AppsFlyer is working with external forensic experts and law enforcement as part of the ongoing investigation.

The primary impact occurred during the incident window and involved services relying on the appsflyer.com domain. During that time:

* websdk.appsflyer.com was redirected to attacker controlled infrastructure, and a modified WebSDK was served to end users. (incident window March 10, approximately 00:31 – 09:47 UTC).
* Some AppsFlyer properties and services experienced a temporary service disruption due to the domain configuration changes. (incident window March 9, 23:26 – March 10th 09:47 UTC).
* Corporate email services experienced a brief disruption during the incident window.

AppsFlyer’s core systems, infrastructure, and customer data environments were not compromised, although the availability of certain services was temporarily affected during the incident window.

Customers whose web browsers loaded the AppsFlyer Web SDK or Smart Banner from websdk.appsflyer.com during the active window (March 10, 00:31 – 09:47 UTC) may have been exposed to the modified SDK.
The AppsFlyer Mobile SDK was not affected by this incident.

No. Based on our current analysis, AppsFlyer systems that process, store or transmit customer data were not compromised in this incident.

Customers who wish to validate whether their environment was exposed during the active window (March 10, 00:31 – 09:47 UTC) should check DNS query logs, network traffic, and Web SDK load requests for the following indicators:
Indicators of Compromise (IOCs)
Malicious Nameservers
ns1.gcorelabs.net — Attacker-controlled NS
ns2.gcdn.services — Attacker-controlled NS
Malicious IP
81.28.12.12 — IP serving tampered SDK via Gcore CDN
TLS Certificate CN
CN=*.gcdn.co — Wildcard cert on attacker infrastructure
TLS Certificate Org
G-Core Innovations S.a.r.l — Certificate issuer on attacker infrastructure
As previously communicated, the activity occurred within the client-side browser environment of website visitors, which means any related behaviour would appear in website or application logs rather than within AppsFlyer systems. We therefore recommend reviewing logs for any unusual activity.

Based on our current analysis, we have not identified evidence that personal data stored or processed within AppsFlyer’s systems was accessed or exfiltrated in this incident.  

For customers whose websites loaded the AppsFlyer Web SDK or Smart Banner during the incident window, a modified SDK was temporarily served through websdk.appsflyer.com. Because the Web SDK executes within the browser environments of website visitors, the code could have accessed data available within those browser sessions.  As this activity occurred within visitor browsers rather than AppsFlyer systems, AppsFlyer does not have visibility into actions that may have occurred within those browser environments.

Yes. As an additional precautionary measure, AppsFlyer revoked all V2 API tokens across the platform and disabled raw data access, and customers were required to generate new tokens to restore API access.
Customers who configured an IP allowlist for their account were not subject to automatic token revocation – such customers may evaluate whether manual rotation is appropriate for their environment.

AppsFlyer’s R&D team received an automated alert for domain issues at 00:22 UTC on March 10, 2026 – less than an hour after the DNS change. Investigation began immediately.

Upon detecting the incident, we took the following actions:

* Secured and restored control of the affected domain registrar account and are in the process of moving to a new domain registrar
* Restored multi-factor authentication on the registrar account 
* Notified law enforcement
* Redirected the Web SDK delivery path to verified, secure infrastructure and introduced a new dedicated Web SDK endpoint
* Reset all user session to hq1.appsflyer.com
* Disabled raw data access, and invalidated all V2 API tokens across the platform as a precautionary measure
* Engaged external forensic security experts to conduct an independent investigation alongside our own
* Worked with our managed partners to redirect their engagements to a new endpoint, to minimize impact on attribution
* Communicated proactively to all customers and partners throughout the incident, beginning within hours of detection and continuing as our understanding developed

Yes. All unauthorized DNS changes have been fully identified and reversed. All DNS records have been independently verified as restored to their legitimate configuration. Forensic investigation has confirmed no residual unauthorized changes or persistence on AppsFlyer’s systems.  However, because internet DNS caching can retain previously resolved records for a period of time, some environments may have continued resolving the earlier configuration even after restoration. For this reason, AppsFlyer introduced a new dedicated Web SDK endpoint and recommended that customers update their implementation to ensure traffic was routed through the correct infrastructure.

AppsFlyer undergoes annual third-party security audits and holds the following certifications: ISO 27001, ISO 27017, ISO 27018, ISO 27032, ISO 27701, and SOC 2. No deviations were identified during our most recent audits. Certificates and SOC 2 reports are available upon request from your Customer Success Manager.

Yes. MFA was configured on the domain registrar account prior to this incident. The attack succeeded because the impersonator manipulated the registrar’s support process and convinced the registrar’s support team to remove the existing MFA protection. The issue therefore arose from the registrar’s support process, not from a failure of MFA configuration on AppsFlyer’s part.

Yes. MFA is enforced for all users, regardless of location (remote or in-office), across all AppsFlyer systems.

AppsFlyer has already implemented a number of measures and is executing additional improvements to further strengthen domain and infrastructure security.

These actions include:
* Migrating domain management to a new registrar provider and hardened domain governance infrastructure, with stronger access controls and administrative safeguards.
* Implementing proactive DNS and domain monitoring, including automated alerting on unexpected DNS or registrar account changes.
* Strengthening registrar account security controls, including enhanced authentication requirements and restricted administrative access.
* Reviewing and tightening third-party vendor security requirements to ensure that domain registrars and DNS providers meet AppsFlyer’s security standards.
* Conducting a comprehensive post-incident review with external forensic experts to validate containment measures and identify additional improvements.

These steps are part of a broader effort to continuously strengthen AppsFlyer’s security posture and reduce the risk of similar incidents in the future.

Yes. AppsFlyer has engaged third-party forensic and security experts to independently validate the forensic investigation findings and assess the completeness of remediation. In addition, AppsFlyer’s ongoing annual audit and penetration testing program provides continuous third-party validation of its security controls and posture.

Yes. AppsFlyer’s systems are secure, the incident is fully resolved, and there is no evidence of ongoing risk to customer IT environments as a result of this incident. AppsFlyer’s core platform, customer data, and attribution infrastructure were not compromised. AppsFlyer has implemented additional safeguards and is executing structural improvements to domain management and DNS monitoring to further reduce the risk of similar incidents.

Yes. AppsFlyer has notified the appropriate law enforcement authorities and is cooperating with them as part of the ongoing investigation.

As a precautionary measure, AppsFlyer revoked all V2 API tokens across the platform, and customers were required to generate new tokens to restore API access. Based on our current analysis, we have not identified evidence that API tokens were accessed or used by the attacker. The revocation was implemented to eliminate any potential risk. AppsFlyer continues to review logs and related activity as part of the ongoing investigation.

Based on our current analysis, we have not identified evidence of suspicious activity or unauthorized access within customer accounts.  The incident involved manipulation of DNS records affecting certain web-facing services rather than access to AppsFlyer’s customer repositories. Comprehensive log analysis has found no evidence of unauthorized access to or exfiltration of customer data.  As we continue our analysis, we are working with external forensic experts to validate these findings.

Measurement inside AppsFlyer may be incomplete for activity that occurred during the incident window. Specifically:
Some clicks routed through affected endpoints were not logged
Some app opens and in-app events during the incident window were not received
Users who installed from an ad before the incident but opened the app for the first time during the incident window may appear unattributed

Additionally, users who were exposed to an ad during the incident window but clicked or opened the app after the window may also appear unattributed — or attributed to organic, or to a later touchpoint — as the original engagement was not recorded.

As a result, installs, conversion rates, and ROAS reported in AppsFlyer for this period may understate actual campaign performance.

Yes – Conversion postback flows were not interrupted during the incident window.
However, due to degraded engagement coverage during the window, some ad engagements were not recorded in real-time. As a result, users who engaged with an ad during that period may appear unattributed or attributed to organic – meaning partners may temporarily see fewer attributed conversions for that cohort.

No action is required from customers.

Possibly, for a short period though the impact is expected to be limited.
Machine-learning bidding systems rely on recent conversion signals. For the vast majority of apps – those on SDK v6.1 and above – session signals were routed to an unaffected endpoint and streamed normally throughout the incident.
For apps on older SDK versions or SDK-less integrations, this stream may have been partially degraded.

Some partners’ models may behave more conservatively for a short period as signal flow normalizes.
AppsFlyer has informed affected partners to account for the anomaly window. We recommend connecting with your partner account teams for any campaign-specific questions.