Stripo outage history

We are aware of an issue with the Stripo Plugin: the editor may fail to initialize and does not load for end users. Our team has identified the affected service and is working on a fix. We will post an update as soon as we have more information.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

At 13:45 UTC the AWS host running the database and cache for our plugin environment failed. Auto-recovery restarted it by 14:00 UTC, but the cache service and several microservices required manual restarts. Full recovery: ~15:00 UTC. **Impact \(UTC\).** Autosave was unavailable 13:48–13:57, then severely slow \(~86 s per request vs. under 7 s normally\) until ~14:40. Some plugins using external AutoSave callbacks saw saves fail. Co-editing was degraded 14:16–15:00. Editor initialization also failed for some users early on. **Data.** No evidence of loss: crash recovery completed correctly, all patches that reached the database were persisted, and duplicate resubmissions were safely rejected. Contact us with a timestamp if you suspect otherwise. **Cause.** Hardware failure on the underlying AWS host. It escalated because autosave retries external callbacks synchronously inside the request, exhausting the database connection pool; the cache had no auto-start on reboot; and connection pools did not self-heal. No alarm covered host status or cache availability, so detection came from user reports. **Fixes.** Alerting on host status checks and cache availability; cache auto-start with a health check; connection pool recovery; moving external callbacks out of the request path; alerts on pool saturation, error rate and callback latency; a redundancy review for this environment. We apologize for the disruption. If the impact on your users differed from the above, please contact our support team.

We are investigating reports of users being unable to log in, seeing missing team members, or experiencing slow loading of emails. Our team is working to identify the cause.

We have identified the root cause: an internal caching service (Redis) ran out of memory and began rejecting writes. As a result, permission checks bypassed the cache and put excessive load on the account service, causing slow responses, login failures, and missing account data. We have increased the cache capacity and are preparing a permanent fix.

Cache capacity has been increased and the system is recovering. Response times are returning to normal as caches warm up. A permanent fix is being deployed.

The permanent fix has been deployed to all production clusters and all systems are operating normally. During the incident (July 30, 22:48 UTC – July 31, ~04:30 UTC, with residual slowness until ~08:49 UTC), some users experienced login failures, missing team member data, and slow loading of emails. No data was lost. We have added memory-usage alerting to detect this class of issue before it affects users. We apologize for the inconvenience.

On July 28, between approximately 1:28 PM and 1:58 PM (UTC), the Stripo Plugin failed to initialize for embedded integrations. The issue was caused by degraded performance of an internal statistics service, which slowed down plugin initialization requests. Our team restarted the affected service and temporarily disabled statistics collection for plugin initializations to restore normal operation. The plugin is now loading as expected. We apologize for any inconvenience this may have caused.

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-07-25T09:18:22

This incident has been resolved.

On July 24 between 09:20 and 09:50 UTC, real-time co-editing in the plugin editor was temporarily unavailable. During a scheduled release, a database schema update took longer than expected and briefly overloaded the database, which caused the co-editing service to restart. Our team identified the cause and fully restored the service by 09:50 UTC. No customer data was lost, and all other Stripo functionality remained available throughout. We've since added safeguards to our release process to prevent a recurrence.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-07-23T09:39:04

[Comment from Opsgenie]Dmitry Kudrenko acknowledged alert: "Partial Outage in work of Stripo Account Backend part"

This incident has been resolved.

Stripo Security Incident How this started We received two customer reports regarding unusual activity associated with ESP accounts. While an individual report could reasonably have been attributed to a variety of causes, including configuration issues, legacy integrations, or provider-specific factors, the second report involved a different ESP provider and exhibited similar characteristics. At that point, we determined that the observed pattern warranted a comprehensive security review and initiated a broader investigation. Current status As we identified accounts with stored ESP credentials, we reached out asking those customers to rotate their keys as a priority. This was not a single, complete pass: as our investigation continued, we identified additional accounts that required the same notification, and we've been contacting them as they're confirmed. If you have ESP credentials connected to Stripo and haven't rotated them yet: 1. Revoke the old key there; generating a new key doesn't automatically disable the old one. 2. Generate a new key in your ESP account. 3. Update the new key in Stripo under Project Settings → Integrations . 4. Review your ESP or CRM account's recent activity: login history, contact list changes, and any campaigns or sends you don't recognize. One reminder while all this is underway: we will never ask you to send a key, token, or password by email or in a support chat. Ongoing investigation Our investigation is continuing. Should we identify any confirmed findings that are material to affected customers, we will communicate them without undue delay.

Jul 20, 2026 - 18:15 UTC What we've fixed Following our initial communication, we have implemented a number of additional security enhancements : 1. Credential protection audit . We reviewed how credentials are stored across our systems and implemented additional encryption for credential data where enhanced protection was identified as appropriate. 2. Implemented additional browser-side protections to address an identified browser-related exposure scenario . Stored credentials are no longer sent back to the browser when the integrations screen is opened. This, combined with the storage enhancement above, significantly reduces potential exposure risks associated with credential handling. 3. Completed a full logging audit . We reviewed our logging systems end-to-end and updated our logging configuration to prevent credential values from being recorded in application logs. 4. Cleaning up stale data . We deleted old ESP connections that had been kept after they stopped being used, and we're in the process of removing old, unused keys still on file. Based on our investigation to date, we have not identified any indication of impact on the Stripo Plugin . Stripo does not store customers' financial or payment information. Accordingly, based on our investigation to date, we have not identified any impact on financial or payment data maintained by Stripo. Based on the information currently available, we have not identified any impact on our primary production systems. The activity identified to date appears to have been associated with a backup environment . We've implemented additional security measures for that environment and are continuing to assess whether there is any broader impact as part of our ongoing investigation. Compliance certifications We maintain an independently audited security program, including SOC 2 and ISO certifications. As part of this investigation, we identified opportunities to further strengthen certain technical controls related to the handling of export credentials. We have implemented additional safeguards addressing the matters identified during our investigation. We are also incorporating the findings from this investigation into our security program, risk assessment processes, technical controls, and future audit activities. These findings have informed additional technical safeguards and will continue to be incorporated into our security controls and audit program. Security certifications demonstrate that an organization's security program has been independently assessed against recognized standards. Like any security framework, they support continuous improvement as new risks and implementation considerations are identified. Ongoing investigation Our investigation remains ongoing. As part of this work, we continue to review access activity relating to the database instances where the relevant data is stored. Should we identify confirmed findings that are material to affected customers, we will communicate them without undue delay.

Incident period: 6–18 July 2026 · Published: 21 July 2026 Final Incident Report — Unauthorized access to stored integration credentials Summary Between 6 and 18 July 2026, an unauthorized actor gained access to an internal, non‑customer‑facing environment that had read access to a restricted, read-only replica containing a limited subset of production data. Based on our completed investigation, the actor executed read queries that resulted in access to certain information stored within that environment, including certain third‑party ESP/export credentials that customers had stored in Stripo for their integrations, together with certain account records. Upon identifying the activity, we isolated and decommissioned the environment involved, implemented remediation measures, and completed our investigation into the incident. The incident was reported solely through a client request and could not have been detected through our standard monitoring. What data was affected Based on our completed investigation, the information identified as having been accessed included certain third‑party ESP/export credentials that customers had saved to connect their integrations, together with certain associated account records. Account authentication data . Stripo passwords are stored hashed and salted — never in plain text, in line with security best practices, so they were not exposed in a usable form. Because a determined attacker could, in theory, attempt to crack salted hashes over time, we did not take chances: we proactively reset every Stripo password even though there is no indication that the hashes can be practically recovered. Each user simply sets a new password at their next sign‑in. What we have done 1. Contained the incident by cutting off and decommissioning the internal environment involved. 2. Extended encryption at rest to all stored ESP/export credentials, including those that were not already encrypted ( keys held in a managed AWS KMS ). 3. Stopped returning credentials to the browser when integration screens are opened. 4. Reviewed application logging and removed credential values from the limited scenarios in which they could appear. While our investigation did not identify evidence that application logs formed part of the attack path, we nevertheless implemented this additional safeguard as part of our broader remediation efforts. 5. Purged old/inactive credentials retained after they were no longer in use. 6. For Klavio, HubSpot, Zoho, and AWeber, we automatically revoked all authorization tokens. 7. Conducted a full review across our infrastructure perimeter: audited all security groups and access paths to system nodes, rotated the passwords for all databases, restricted the read‑only replica to internal‑only access, and reviewed access held by internal services and staff, tightening it under least‑privilege principles. 8. Proactively reset all user passwords and invalidated sessions. 9. Added monitoring and alerting for authentication to internal tools, external database connections, and bulk reads of sensitive tables. We operate under recognized security and data‑protection standards, including our SOC 2 program. As part of our ongoing security program, we continue to strengthen our technical and organizational controls based on the findings of this investigation. Who was not affected Customers who exported only to file formats (HTML, AMP HTML, PDF, EML, image, etc.) never stored any credentials with us and are not affected. Credentials were also not accessed for the following providers: CleverTap, Customer.io, Follow Up Boss, Google Cloud, MailerCloud, MailerLite, Mailtrap, Make, Mindbaz, n8n, Netcore, OneSignal, Optimove, Postup, Pubrio, Rapidmail, Reteno, Selzy, Sender.net, Ticketor, Unione, Insider, Voizee, WhatCounts, Yespo. Plugin and self‑hosted deployments were not affected — the environment and replica involved are part of Stripo Cloud infrastructure, not the self‑hosted product or the Stripo plugin. Long‑inactive accounts . Under our data‑retention policy and in line with our GDPR obligations, inactive customer accounts and their personal data are routinely deleted, so information belonging to long‑inactive customers was not present in this environment and could not have been exposed. Payment data Based on our investigation, no full payment card numbers (PANs) or CVV codes were identified as having been accessed. Card payments are processed by our payment providers (Stripe and PayPal), and Stripo does not store full payment card numbers or CVV codes. Working with our ESP partners Because these are third‑party credentials, we are proactively contacting the ESP providers involved, in the spirit of partnership and to protect our mutual customers, so affected credentials can be revoked on their side as an additional safeguard. What we recommend our customers do 1. If your provider is not in the “Who was not affected” section above and you haven't already: rotate the ESP credentials connected to your Stripo account — revoke the old key at your provider, generate a new one, and update it in Stripo (Project Settings → Integrations). For OAuth‑based integrations, revoke Stripo's authorization at your provider and reconnect. 2. Review your ESP/CRM activity from early July onward — sign‑ins, contact‑list changes, and any campaigns, sends, or exports you don't recognize. Rotating a key stops future use but doesn't undo activity that already occurred. 3. Your Stripo password has already been reset — set a new one at your next sign‑in. Closing We sincerely regret that this incident occurred. We've contacted affected customers directly and remain available to answer follow‑up questions on request. Contact: [email protected].

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-07-07T15:26:22

This incident has been resolved.

There might be an issue related to exporting of email templates as PDF files from the editor. Time (UTC) : 2026-07-01T03:52:37

This incident has been resolved.

There might be an issue related to sending test messages to specified email addresses and/or related to testing email templates with Email on Acid. Time (UTC) : 2026-06-18T13:43:15

This incident has been resolved.

There might be issues related to using any of the methods of Public API. Time (UTC) : 2026-05-28T06:28:00

This incident has been resolved.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-05-03T07:18:04

This incident has been resolved.

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-04-28T02:02:57

This incident has been resolved.

There might be an issue related to the rendering of UI components inside the customer’s account. Time (UTC) : 2026-04-26T16:19:37

This incident has been resolved.

We are currently experiencing increased response times in the Plugin API Gateway, which is impacting the speed and ability to initialize new plugins.

The issue has been identified and a fix is being implemented.

This incident has been resolved.

We are currently experiencing increased response times in the Plugin API Gateway, which is impacting the speed and ability to initialize new plugins.

A fix has been implemented and we are monitoring the results.

The issue with increased response times in the Plugin API Gateway has been resolved, and plugin initialization is now operating normally. Root cause: During a scheduled AWS infrastructure update to apply patches, which was expected to proceed without downtime and therefore was not communicated in advance, an unfortunate misconfiguration occurred, which we have already identified and fixed. Some pods were terminated before new ones were fully ready, leading to a significant accumulation of requests in the queue. Instead of being processed gradually, a large batch of queued requests was handled simultaneously, which exhausted available database connections and caused delays in processing new incoming requests. We are optimizing our deployment and scaling procedures to prevent similar situations in the future.

On April 8 between 09:51 UTC and 09:54 UTC, we experienced a short service degradation affecting both the Stripo application and plugin. The issue was caused by a malfunction in the AWS EKS networking stack (Amazon VPC CNI addon), which is managed by AWS and outside of our direct control. During this time, users may experience intermittent connectivity issues. The incident has been fully resolved, and all services are operating normally.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-03-29T07:10:04

This incident has been resolved.

There might be an issue with access to the customer’s account. Time (UTC) : 2026-03-17T10:51:04

This incident has been resolved.

There might be issues while uploading, changing or removing customer’s images inside the editor. Time (UTC) : 2026-02-26T08:48:57

This incident has been resolved.