Summary
On February 25, 2026, at 13:39 UTC we implemented a configuration change that enabled caching on a shared system component supporting our social crawling and publishing services. The caching was not configured to clearly separate data by account and request. As a result, in some cases the system reused previously stored responses for the wrong account, which led to certain data being saved under an incorrect account. At no point during this incident did unauthorized actors gain access to client or user accounts, nor were any changes initiated by unauthorized actors.
At 14:37 UTC on February 25, 2026, we reverted the caching configuration, which immediately stopped the incorrect behavior. We then conducted remediation activities to correct affected data and remove any erroneous records.
Customer Impact
During the incident window, customers may have experienced:
- False Supervision alerts showing profile changes that did not occur, and in some cases profile information associated with other accounts was displayed. Yext dismissed all false alerts but in the Supervision UI the status may show as accepted. No action was taken on any of the alerts.
- A small number of inbound LinkedIn Direct Messages (DMs) were temporarily saved under incorrect accounts. These DMs have been deleted from the incorrect accounts.
- A subset of assets with incorrect profile data display that required recrawling to restore accuracy.
Data Privacy and Security
Based on our investigation to date:
- There is no evidence of permanent corruption of source-of-truth systems.
- For the mis-associated inbound LinkedIn DMs, our internal review did not identify sensitive information exposure.
- The cross-account data mixing was limited in scope and duration and was addressed by disabling the caching configuration and completing cleanup and verification steps.
- No content publishing functionality was impacted.
- No posts were published to the wrong social networks.
Timeline (UTC)
- 13:39 Caching deployment initiated on VPC gateway infrastructure
- 13:52 Caching became active
- 14:37 Caching configuration reverted (issue stopped)
- 16:55 Customer reports received indicating incorrect profile alerts
- 17:16 Root cause confirmed as API Gateway caching returning improperly scoped responses
- Feb 26, 01:20 Incident marked resolved after remediation and monitoring completed
Root Cause
Caching was enabled on a shared system component that handles requests for multiple accounts. The caching rules were not configured to clearly separate data by account and request. As a result, in some cases the system returned previously stored information that belonged to a different account. Because downstream systems treated that information as valid, it led to incorrect alerts and actions being stored under the wrong account.
Mitigation and Recovery
We took the following actions:
- Reverted the caching configuration to stop further incorrect responses.
- Removed erroneous Supervision alerts from active queues.
- Deleted mis-associated LinkedIn DMs from incorrect accounts.
- Recrawled and restored affected profile data, followed by manual spot-check verification.
- Removed or suppressed affected internal activity records created as a result of the incorrect context during the incident window.
Preventing Recurrence
We are implementing additional safeguards, including:
- Stronger change controls for shared infrastructure, including enhanced review and risk assessment before enabling configuration changes that impact multiple accounts.
- Stricter safeguards around caching behavior, including enforced separation of data by account and validation requirements before caching can be activated.
- Expanded automated testing for shared gateway components to prevent cross-account data inconsistencies.
- Improved monitoring and anomaly detection to identify and escalate cross-account data issues more quickly, including automated checks for alert accuracy and account-level data consistency.