Voice AI demo hit by $982 toll fraud attack after Twilio developer left endpoint open

An open endpoint on a demo that was never promoted

The project was a Twilio ConversationRelay voice assistant built with FastAPI. According to the post, ConversationRelay connects a phone call to a WebSocket, handles speech recognition and text-to-speech, and lets the application pass the caller's transcribed speech to a large language model. The app supported OpenAI, Google Gemini and Amazon Bedrock. A web interface let a user pick the model, personality and voice, then enter a phone number to receive an outbound call.

The weak point was the /api/call endpoint. It created a real phone call to any number submitted, using the author's Twilio credentials, with no access control. Kumar writes that he never promoted the hosted URL or shared it on social media, and assumed it had a small audience. But the GitHub repository was public and the deployment was tied to a public custom domain. He could not determine how the attacker found it, because the application did not retain the original client IP or referrer. His conclusion: "an internet-accessible demo is public even when its URL isn't promoted."

What the attack looked like

On August 15, 2026, an automated client began calling the endpoint. The traffic ran from 10:32 a.m. until 2:39 p.m. Central Time. According to the post, the figures were:

• 1,008 requests to /api/call, of which 921 created calls and 87 failed
• 903 completed calls
• 920 calls to Israel, across 156 unique Israeli destinations
• Twilio fraud-related cost of $971.50 and Google Gemini cost of $10.58, a combined $982.08

Of the 921 attempts, 920 went to a narrow destination range beginning with +972229. One hundred and four numbers were each called seven to ten times, accounting for 851 calls. The completion rate was approximately 98 percent, and the calls produced almost 30 hours of connected traffic in the four-hour window.

Twilio describes voice toll fraud, also known as International Revenue Sharing Fraud (IRSF), as abusing an application to generate calls to international premium-rate numbers controlled by a bad actor. Kumar says the volume, destinations, durations and automated audio were consistent with that pattern, though his logs could not show who controlled the numbers or received revenue.

How the incident was reconstructed

Kumar started with the Twilio CLI, querying voice call records for the incident date. Every call was outbound-api, used the same source number, and nearly every destination began with Israel's +972 country code. Usage records split the Twilio cost into outbound connectivity ($828.68), ConversationRelay ($137.34) and Voice Insights ($5.49), totaling $971.50.

A further charge on August 24 first looked like a second incident. The call records showed it matched six calls that began within 21 seconds of one another near the end of the August 15 attack. They lasted between 9 minutes 21 seconds and 10 minutes 1 second, averaging approximately 9 minutes 48 seconds. Kumar says this clustering suggested coordinated automation, and advises correlating usage records with underlying resource logs rather than relying on billing dates alone.

The app ran in Azure Container Apps with console logs sent to Log Analytics. A query of the incident window found the same 1,008 POST requests, 921 successes and 87 failures. The 921 successful requests matched the 921 Twilio call records exactly. Twilio's Request Inspector showed a representative fraudulent call fetching the app's /twiml endpoint and connecting to its ConversationRelay WebSocket, which ruled out an unrelated Twilio application in the same account.

The logs held only Azure's internal ingress address. The original X-Forwarded-For value was not logged, and no proxy retained access logs, so Kumar could identify the exploited endpoint but not the person or machine behind it.

Traffic pumping or scam?

Kumar then asked whether the calls were meant to scam people or to inflate traffic. He cites Twilio's Anti-Fraud Developer's Guide, which describes voice traffic pumping as outbound calls directed to destinations controlled by a fraudster, which may be answered by automated recordings or silence to keep them connected. The source text provided ends at this point.

What it means for demo builders

The case shows that a demo wired to a paid telephony API carries real financial risk once it is reachable online, regardless of how quietly it is shared. Per the post, a URL is "an address, not an access control." Kumar says the rest of the post covers the controls every public voice AI demo should have, and the endpoint code he shows is marked as one not to copy. Developers running similar demos should also keep request logs that preserve client IP details, since their absence here left the attacker unidentifiable.