Is Sendblue Safe? What Its August 2026 Incident Report Says
TL;DR
On August 5, 2026, Sendblue disclosed unauthorized access to conversation records, including message content and phone numbers, through a database security-rules vulnerability, plus a phishing campaign targeting numbers tied to its customers' messaging. Sendblue fixed the flaw the day it was reported and disclosed publicly within days, which deserves credit. The durable lesson is the question set: ask any messaging vendor, us included, where message content lives, who can read it, and what happens when something goes wrong.
On this page
What happened at Sendblue?
Per Sendblue's August 5, 2026 incident report: On August 1 contacts received fraudulent SMS impersonating Sendblue customers asking for $49 deposits. These were sent from external Sinch numbers, not Sendblue's platform.
On July 31 a researcher reported a Firebase/Firestore security-rules vulnerability. Sendblue fixed it the same day but found unauthorized access to conversation records on July 7 and July 10, weeks before anyone reported the flaw.
All facts in this post come from that disclosure. The report itself is the source of record at sendblue.com/blog/sendblue-security-incident-update.
What data was involved?
Per the disclosure: message content, phone numbers, contact info, Sendblue line associations, org usernames, and messaging metadata. For some customers access was confirmed; others had reachable records. Sendblue is notifying affected customers directly.
Conversation records are the entire business relationship: what reps said, how prospects answered, and the numbers connecting them. The phishing campaign shows why this matters: attackers targeted Sendblue customer numbers and impersonated the businesses those contacts had been texting with.
What did Sendblue get right?
Sendblue fixed the vulnerability the day it was reported. It published a specific incident report within days: the scam domain, the sending numbers, a sample message, and exact access dates. It engaged Oneleet for third-party review, reported to authorities, and got Sinch and the payment domain to take action.
Many companies bury incidents in customer emails until forced public. Fast, specific disclosure is what you want from any vendor, and buyers should credit it. A vendor that discloses quickly shows what it'll do next time something breaks.
What should you ask any messaging vendor about security?
The useful output of an incident like this is a better question set, applied to every vendor you evaluate, including us. A vendor's practices matter more than a moment-in-time audit.
Before you put customer conversations on any platform, get answers to these in writing:
- Where is message content stored, and who inside the company can read it?
- Are customer workspaces isolated from each other, and how has that isolation been tested?
- How would you detect unauthorized access to conversation data, and how long would detection take?
- What is your commitment on breach notification: how fast, how public, how specific?
- Has the company had a security incident before, and how did it handle disclosure?
- Is there a working channel for security researchers to report vulnerabilities?
- Can I delete my data, completely, when I leave?
How Blue Reacher approaches security
Blue Reacher publishes its security practices: TLS encryption in transit, rotatable per-customer API keys, least-privilege production access, customer workspace isolation, immediate opt-out enforcement, on-request data deletion, and a responsible-disclosure channel at support@bluereacher.com. See the full page at /security.
The full compliance posture and control mapping are published at /trust. If your evaluation needs specifics beyond the published practices, book your Blue Funnel Map, a 15-minute call, bring the question set above, and you'll get direct answers in writing, including where we think the honest tradeoffs sit.
Frequently asked questions
Is Sendblue safe to use after the August 2026 incident?
The decision is yours to make with the full incident report in front of you. Sendblue fixed the flaw the same day, disclosed publicly, and engaged third-party review. The counterweight: conversation records, including message content and phone numbers, were accessed before anyone caught it. Read sendblue.com/blog/sendblue-security-incident-update and ask Sendblue the questions in this post.
What data was accessed in the Sendblue incident?
Per Sendblue's disclosure, the information involved may include message content, phone numbers, contact information, Sendblue line associations, organization user names, and messaging metadata, with unauthorized access identified on July 7 and July 10, 2026. Sendblue confirmed access for some customers and is notifying affected customers directly with account-specific detail.
Did the incident involve iMessage itself?
No. Nothing in Sendblue's disclosure points at the iMessage channel. The vulnerability was in Firebase/Firestore security rules, the permission layer on Sendblue's own cloud database, and the phishing messages were sent as SMS from external Sinch toll-free numbers outside Sendblue's platform. This was a vendor data-security event, and the same category of risk exists with any platform that stores your conversations.
What is the phishing campaign Sendblue described?
Fraudulent SMS messages impersonating Sendblue customers, sent from two external toll-free numbers, asking recipients to pay a $49 onboarding-call deposit through a scam payment domain. Sendblue reports that Sinch took the sending numbers out of service and the payment domain was taken down. If a contact of yours received one, they should not click the link or pay anything.
What's Blue Reacher's security posture?
The full compliance posture is published at /trust, with control mapping and supporting documents. Our practices at /security: TLS in transit, rotatable per-customer API keys, least-privilege production access, workspace isolation, immediate opt-out enforcement, data deletion on request, and a responsible-disclosure channel. Bring your questions to a demo call for direct answers.
Keep reading
More on choosing a platform
How Long Before a New iMessage Line Can Send?
Setup promises in this category run from 15 minutes to about two days, and one provider will not allow an outbound first message at all until a separate gate clears. Each vendor is timing a different step, which is why a launch date built on the number in the hero slips.
What Your iMessage Provider Actually Lets You Send
Buyers compare the monthly price of a line and then build the campaign. The constraint that stops the campaign is somewhere else: a new-conversations-per-day figure buried in a comparison table, and an acceptable use policy that names cold outreach as prohibited on every plan. Both are published. Neither is on the page you compared.
Project Blue Pricing in 2026: Full Breakdown
Project Blue's published pricing: $300 per month plus a $500 setup fee on monthly billing, $166.50 per line per month on annual, additional lines from $250. The numbers, what they buy, and the setup-fee math nobody neutral has written down.
Put this on your pipeline
Blue Reacher runs outbound iMessage for B2B sales teams, from your CRM, with setup handled for you.
Book a demo