What happened
On the evening of July 6, 2026, starting at 21:00 UTC, ThriveCart was targeted by a coordinated Layer-7 (application-layer) attack. The attack combined a high-volume connection-exhaustion flood against our custom-domain routing layer with a broad automated vulnerability-scanning campaign targeting ThriveCart and merchant-hosted domains.
Our security systems absorbed the majority of the attack without any customer impact. However, during a roughly 33-minute window, the flood’s intensity exceeded the capacity of a component that handles custom-domain traffic. During this window, some visitors on merchant custom domains experienced intermittent page-load slowdowns, sometimes requiring a refresh to access the checkout. It is estimated that the impact affected approximately 11% of legitimate traffic during the 33-minute window. This was reported on our Status Page, where automated notifications were sent out to subscribers.
We want to be clear about what was and was not affected:
- Not affected: The main ThriveCart checkout at thrivecart.com, payment processing, merchant dashboards, course and membership content, and all customer data. Our continuous payment monitoring passed every check throughout the incident, and every transaction that reached checkout completed normally.
- Affected: Shoppers visiting sales pages and checkouts on merchant custom domains saw intermittent errors during the impact window. Most errors were transient, and a page refresh typically resolved the issue.
- Security outcome: There was no breach and no data exposure. Every malicious scanning probe was blocked or harmless.
What caused it
Our custom-domain routing layer was pushed past the volume ceiling, so new connections were simply dropped with no response, causing the intermittent browser errors.
The attack was specifically designed to operate at the connection layer rather than the request layer. This is a meaningful distinction: most of our defenses operate after a connection is established, inspecting and filtering individual requests. A flood that exhausts connections before a single request is processed sits “below” those defenses. The characteristic fingerprint of this kind of attack is a drop in the ratio of requests to connections, which is exactly what our logs showed.
What we did
Once the incident was identified, our response was swift. We:
- Restarted the affected infrastructure to immediately clear the connection backlog and restore capacity
- Deployed targeted firewall rules to block the scanning component of the attack, reducing ongoing noise
- Restored full redundancy within about 40 minutes of the restart
- Communicated via our status page, updating customers from “investigating” to “resolved” within approximately 30 minutes of incident declaration
The attack tapered off that same evening, and all metrics returned to baseline.
What held strong
This attack met a resilient core platform:
Databases: Under no pressure. RDS and all data services operated normally throughout the entire event, including during peak attack intensity. There were no slowdowns, no errors, and no risk of data exposure.
Application servers: Our EC2 application fleet absorbed a meaningful surge in traffic volume, with CPU spiking under load but the fleet remaining stable and serving requests throughout. No application-tier outages occurred.
Core checkout: The main ThriveCart checkout at thrivecart.com returned near-zero errors across the full attack window. Our continuous payment-page monitoring passed every single check, and every transaction that reached checkout completed normally.
Security layers: Our WAF and request-filtering rules performed exactly as designed, blocking millions of malicious scanning probes across the day without any tuning required. The vulnerability-scanning campaign achieved nothing.
The impact was confined to one component. Everything we have invested in over the past year in platform stability, database resilience, and application-tier scaling held firm under real adversarial conditions.
What we’re changing
The highest-priority action is replacing or fundamentally rebuilding the custom-domain routing component. The new architecture will support automatic scaling, preserve real client IP addresses for per-source rate limiting, and eliminate the hard connection-queue ceiling that made this attack effective.
This incident has accelerated several infrastructure and process improvements that are now in progress:
1) Proactive threat intelligence
Rather than treating each scanning campaign as a one-off, we’re building a recurring process to monitor and act on scanner fingerprints before they escalate. The pattern of automated probes that preceded this attack is now a leading indicator we will track explicitly.
2) Permanent, managed firewall rules
Rules are being moved into our infrastructure-as-code management and made permanent. Defenses that only exist during an active attack don’t prevent the next one.
3) Application scaling headroom
We identified that our application server fleet had less scale-out room than it should during this incident. We’re increasing headroom so that surge capacity is available when needed.
4) Weekend and off-hours posture
A disproportionate share of significant attack activity has occurred during off-hours and on Fridays. We’re establishing a pre-weekend review process for security posture and on-call coverage.
Our commitment
We’re genuinely sorry for the disruption experienced by shoppers on merchant custom domains during this window. Protecting the ability for our merchants to sell – and for their customers to buy without friction – is foundational to what we do.
The good news: our core platform held, payment processing was never compromised, and there was no breach of any customer data. The architectural plan of action is clear and is our top infrastructure priority.
We will continue to share updates on our hardening progress. If you have questions, our support team is available and happy to help.
A note on what we’ve left out: In the interest of not providing a roadmap to bad actors, this post omits specific infrastructure capacity thresholds, internal component names, and detailed attack signatures. Our full internal post-mortem contains these details and is available to our team and relevant auditors.