On August 5, 2026, Sendblue disclosed a security incident: unauthorized access to conversation records via a Firebase security-rules vulnerability. Here's what Sendblue reported, the data involved, and how to evaluate your iMessage API provider.
On August 5, 2026, Sendblue published an incident report disclosing a security incident affecting its iMessage platform. Because we're regularly asked how Blooio compares to Sendblue, and because messaging data is sensitive by nature, we've summarized what Sendblue reported — in their own words — and what it means if you send customer messages through an iMessage API. Everything below is drawn from Sendblue's own public incident report, which we've also archived further down in case it changes.
In its report dated August 5, 2026, Sendblue wrote that on July 31, 2026 an external security researcher reported a vulnerability in its Firebase/Firestore security rules. Sendblue says it treated the issue as a SEV-0 incident and fixed it the same day. Its investigation then identified unauthorized access to certain Firebase/Firestore conversation records on July 7 and July 10, 2026.
Per Sendblue, the information involved may include:
Sendblue states that for some customers it confirmed records were accessed, while other customers had records that were accessible through the affected paths without confirmation that they were retrieved. Sendblue says it engaged a third-party cybersecurity partner (Oneleet), began notifying affected customers, and started reporting the incident to U.S. and European authorities. For the authoritative account, read Sendblue's incident report.
Separately, Sendblue reported that beginning around August 1, 2026, some contacts received fraudulent SMS messages impersonating Sendblue customers and requesting payment through a suspicious link. Sendblue says those messages were not sent through its platform — they originated from external toll-free numbers — and that it has since had the sender numbers taken out of service and the payment domain removed. If you or your contacts receive a message like this, don't click the link, submit payment, or share personal or financial information.
The root cause Sendblue describes is a vulnerability in its Firebase/Firestore security rules. Firestore security rules are the access-control layer that decides which client can read or write which documents. When those rules are too permissive, records that should be private can become readable by unauthorized clients directly from the database — without ever passing through server-side checks. Sendblue's report indicates a researcher identified exactly this class of issue, and that conversation records were reachable through the affected paths.
Misconfigured Firestore rules are a well-documented and preventable category of cloud security issue. That's part of why messaging teams increasingly ask their providers a pointed question: where does my message data actually live, and who can reach it?
It's worth being precise here. Sendblue publicly states that it is SOC 2 Type II certified, and describes HIPAA and TCPA support. SOC 2 Type II is a meaningful, independent attestation — a third-party auditor reviews an organization's controls over a period of time. But a certification describes controls as they were assessed; it is not a guarantee that every configuration, such as a set of database security rules, is airtight at every moment. Sendblue's own disclosure shows that even a SOC 2 Type II–certified provider can experience unauthorized access to customer data. Compliance and security overlap, but they are not the same thing.
If you send customer conversations through any messaging provider — Sendblue, Blooio, or anyone else — this is a good moment to ask a few questions:
If your contacts' phone numbers and message content live in a datastore, the security of that datastore matters as much as the API sitting on top of it.
Security is a first-class priority at Blooio. A few specifics we can point to today: webhook payloads are signed with HMAC-SHA256 using a per-endpoint secret you can rotate at any time; access to internal systems follows least-privilege principles; and all API traffic is served over TLS. We're also candid about where we are on formal attestations — Blooio is not currently SOC 2 certified, and we won't claim otherwise. What we do commit to is transparency: if a security incident ever affected your data, we'd tell you plainly and quickly, because that's how disclosure should work.
If this disclosure has you reconsidering where your messaging data lives, Blooio is built to make switching painless. You can start a free trial with no credit card, get an iMessage-enabled number in minutes, and run Blooio in parallel with your current provider during cutover. For the details, see the full Blooio vs Sendblue comparison or our Sendblue migration guide.
Start a free Blooio trial — no credit card, an iMessage-enabled number in minutes, and a painless migration from Sendblue.
Start free trialThis article summarizes Sendblue's own public incident report (published August 5, 2026) and Sendblue's public security documentation, both linked and archived above. Blooio is an independent service and is not affiliated with, sponsored by, or endorsed by Sendblue. "Sendblue" is a trademark of its respective owner. If you believe any information here is inaccurate, contact us at support@blooio.com and we'll review it promptly.
Getting an RCS agent approved to send has less to do with the API and more to do with configuration choices made before the first launch request is ever submitted.
Sending a single message is straightforward. Ensuring reliable delivery of millions of messages presents a significant engineering challenge.
If your business relies on SMS, message delivery is more challenging than ever. Carriers use advanced methods to detect spam and noncompliant traffic. Businesses that don't follow A2P 10DLC rules risk having messages filtered, delayed, or blocked.
