Stripo — Incident history 2026

SUMMARY

On 8 October 2026, between 22:20 and 23:18 UTC, the Stripo Plugin was unavailable: the editor did not load or respond. The outage lasted 58 minutes. No customer data was lost, and other Stripo products were not affected.

WHAT HAPPENED

The database server behind the Plugin lost time synchronization. Two time-sync services were running on the server at once: the standard daemon, which adjusts the clock gradually, and a legacy scheduled job that steps the clock abruptly. A misconfigured schedule made the legacy job run almost every minute. The repeated clock jumps destabilized the server until the Plugin's database became unavailable.

TIMELINE (UTC, 8 October 2026)

21:44 - Clock instability begins on the Plugin database server.

22:13 - Our monitoring raises the first alert for the server.

22:20 - The Plugin stops loading for customers.

22:40 - Monitoring reports the Plugin database as unavailable.

23:00 - First customer reports are received; the on-duty engineer is called in.

23:18 - Service restored. The Plugin is fully operational.

RESOLUTION

Our engineers identified the time-sync conflict and restored the server. The Plugin returned to normal operation at 23:18 UTC and has been under extended monitoring since.

WHAT WE ARE DOING TO PREVENT THIS

• Removing the legacy time-sync job so that this server, and every other production server, uses a single time source.
• Adding monitoring for clock drift so that this kind of fault is caught before it affects service.
• Changing alert escalation. Our monitoring alerted seven minutes before the outage, but the alert did not page an engineer. Critical alerts on production database servers will now page the on-duty engineer immediately, at any hour.

We apologize for the disruption and thank you for your patience. If you were affected and have questions, please contact our support team.

The Plugin is fully operational again. DevOps restored the Plugin DB host; we are monitoring and have seen no further errors since 23:18 UTC.

A postmortem with root cause, timeline, and action items is being prepared and will be published shortly.

Started: 2026-10-08 22:20 UTC

Impact: Plugin is unavailable for customers — the editor does not load / does not respond. We have received reports from several customers.

What happened: At 22:13 UTC Zabbix reported the agent on the Plugin database server as unavailable; at 22:40 UTC the PostgreSQL monitor for live-plugins failed as well. The Plugin stopped working for customers at ~22:20 UTC.

DevOps is investigating. Next update here as soon as we have more information.

Root cause

The incident was caused by an issue during a planned rotation of the access key used for the primary image storage service.

The new key was not correctly propagated to one of the services responsible for handling storage operations. As a result, requests from that service could not authenticate with the storage, causing image and document upload operations to fail.

We also identified a gap in our internal documentation related to the key rotation procedure, which contributed to the incident.

Resolution

The storage credentials were corrected and successfully propagated to all affected services. Once the configuration was updated, upload functionality returned to normal.

We have also updated the relevant internal documentation to include the previously missing configuration step.

Preventive actions

We are reviewing the credential rotation procedure to ensure that all dependent services are covered and that configuration changes are validated before and after rotation. We are also improving our internal documentation and verification procedures to reduce the risk of similar incidents in the future.

We apologize for the disruption and appreciate your patience while our team worked to resolve the issue.

This incident has been resolved.

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

We are currently experiencing an issue affecting some Stripo Plugin functionality. Some users may be unable to upload images or documents or update storage credentials.

Our team is investigating the issue and working to restore normal operation as quickly as possible.

Start time: Sep 18, 13:41 UTC

This incident has been resolved.

We are currently experiencing degraded performance in the Stripo Web Editor. Some users may experience long loading times when opening emails, unavailable editor settings and editing functionality, or a “No internet connection” error.

For users who already have an email open, changes should continue to be saved via autosave as long as the page is not reloaded.

Our team is actively investigating the issue and working to restore normal operation.

Start time: Sep 16, 13:25 UTC

The scheduled maintenance has been completed.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

Maintenance will begin as scheduled in 60 minutes.

We will conduct scheduled maintenance on September 6, 2026, to update libraries and apply new security patches to our servers as part of our SOC2 compliance efforts.

From 08:00 to 09:00 (UTC) — maintenance will affect the Stripo Account services. During this time, your Stripo account may be temporarily unavailable.

From 09:00 to 10:00 (UTC) — maintenance will affect the Stripo Plugin services. During this time, the plugin may be temporarily unavailable, including the ability to create, modify, or save email templates.

We apologize for any inconvenience this may cause and assure you that we will work to complete the updates as quickly as possible.

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.

This incident has been resolved.

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

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

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 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.

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.

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.

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.

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.

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.

This incident has been resolved.

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

There might be an issue with access to the customer’s account.

Time (UTC) : 2026-07-23T09:39:04

<small>Incident period: 6–18 July 2026 · Published: 21 July 2026</small>

<h1>Final Incident Report — Unauthorized access to stored integration credentials</h1>

<h3>Summary</h3>

Between 6 and 18 July 2026, an unauthorized actor gained access to an internal, non‑customer‑facing environment that had <em>read access to a restricted, read-only replica</em> 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.

<h3>What data was affected</h3>

Based on our completed investigation, the information identified as having been accessed included certain <b>third‑party ESP/export credentials</b> that customers had saved to connect their integrations, together with certain associated account records.

<b>Account authentication data</b>. 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.

<h3>What we have done</h3>

<em>1.</em> Contained the incident by cutting off and decommissioning the internal environment involved.

<em>2.</em> Extended encryption at rest to all stored ESP/export credentials, including those that were not already encrypted (<b>keys held in a managed AWS KMS</b>).

<em>3.</em> Stopped returning credentials to the browser when integration screens are opened.

<em>4.</em> 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.

<em>5.</em> Purged old/inactive credentials retained after they were no longer in use.

<em>6.</em> For Klavio, HubSpot, Zoho, and AWeber, we automatically revoked all authorization tokens.

<em>7.</em> 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.

<em>8.</em> Proactively reset all user passwords and invalidated sessions.

<em>9.</em> 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.

<h3>Who was not affected</h3>

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.

<b>Long‑inactive accounts</b>. 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.

<h3>Payment data</h3>

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.

<h3>Working with our ESP partners</h3>

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.

<h3>What we recommend our customers do</h3>

<em>1.</em> 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.

<em>2.</em> 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.

<em>3.</em> Your Stripo password has already been reset — set a new one at your next sign‑in.

<h3>Closing</h3>

We sincerely regret that this incident occurred. We've contacted affected customers directly and remain available to answer follow‑up questions on request. Contact: security@stripo.email.

<hr/>

<small>Jul 20, 2026 - 18:15 UTC</small>

<big>What we've fixed</big>

Following our initial communication, we have implemented a number of <b>additional security enhancements</b>:

<em>1.</em> <b>Credential protection audit</b>. We reviewed how credentials are stored across our systems and implemented additional encryption for credential data where enhanced protection was identified as appropriate.

<em>2.</em> <b>Implemented additional browser-side protections to address an identified browser-related exposure scenario</b>. 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.

<em>3.</em> <b>Completed a full logging audit</b>. We reviewed our logging systems end-to-end and updated our logging configuration to prevent credential values from being recorded in application logs.

<em>4.</em> <b>Cleaning up stale data</b>. 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, <em>we have not identified any indication of impact on the Stripo Plugin</em>. 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 <em>backup environment</em>. 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.

<big>Compliance certifications</big>

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.

<big>Ongoing investigation</big>

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.

<hr/>

<h1>Stripo Security Incident</h1>

<big>How this started</big>

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.

<big>Current status</big>

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:

<em>1.</em> Revoke the old key there; generating a new key doesn't automatically disable the old one.

<em>2.</em> Generate a new key in your ESP account.

<em>3.</em> Update the new key in Stripo under <em>Project Settings → Integrations</em>.

<em>4.</em> 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.

<big>Ongoing investigation</big>

Our investigation is continuing. Should we identify any confirmed findings that are material to affected customers, we will communicate them without undue delay.

The scheduled maintenance has been completed.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

Maintenance will begin as scheduled in 60 minutes.

We will conduct scheduled maintenance on May 3, 2026, to update libraries and apply new security patches to our servers as part of our SOC2 compliance efforts.

From 07:00 to 08:00 (UTC) — maintenance will affect the Stripo Account services. During this time, your Stripo account may be temporarily unavailable.

From 08:00 to 09:00 (UTC) — maintenance will affect the Stripo Plugin services. During this time, the plugin may be temporarily unavailable, including the ability to create, modify, or save email templates.

We apologize for any inconvenience this may cause and assure you that we will work to complete the updates as quickly as possible.

This incident has been resolved.

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

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 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.

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

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

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.

The scheduled maintenance has been completed.

Verification is currently underway for the maintenance items.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

Maintenance will begin as scheduled in 60 minutes.

We will conduct scheduled maintenance on March 28, 2026, to update libraries and apply new security patches to our servers as part of our SOC2 compliance efforts.

From 08:00 to 09:00 (UTC) — maintenance will affect the Stripo Account services. During this time, your Stripo account may be temporarily unavailable.

From 09:00 to 10:00 (UTC) — maintenance will affect the Stripo Plugin services. During this time, the plugin may be temporarily unavailable, including the ability to create, modify, or save email templates.

We apologize for any inconvenience this may cause and assure you that we will work to complete the updates as quickly as possible.

The scheduled maintenance has been completed.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

Maintenance will begin as scheduled in 60 minutes.

We will conduct scheduled maintenance on February 1, 2026, to update libraries and apply new security patches to our servers as part of our SOC2 compliance efforts. During this maintenance window, your Stripo account and Stripo Plugin may be unavailable. This includes the ability to create, modify, or save email templates.

We apologize for any inconvenience this may cause and assure you that we will work to complete the updates as quickly as possible.