OTP flooding and SMS pumping: how attackers run up your SMS bill, and how to stop them

If your app, website or loyalty programme sends a one-time password (OTP) by SMS, someone can make it send thousands of them. You pay for every message. This is known as SMS pumping, SMS toll fraud or artificially inflated traffic, and a related problem, OTP flooding, can lock real users out or bury them in messages.

This post explains how both work and what stops them.

How SMS pumping works

1. An attacker finds a form that sends an SMS: sign-up, login, password reset, "send me a code", or a loyalty programme join page.
2. A script submits it over and over, using phone numbers in ranges the attacker profits from, often premium or high-cost destinations.
3. Each message is billed to you. Part of the money ends up with the people running the scheme through the messaging chain.

The attacker doesn't need to break into anything. They are using a feature exactly as built, just at a scale nobody planned for.

How OTP flooding works

Here the target is a person rather than your bill. A script requests codes for one real phone number again and again. The owner gets a stream of messages, may miss a genuine one, and may be pushed into approving something by mistake.

Signs it is happening

• Messaging costs rise suddenly without a matching rise in sign-ups.
• Many codes are sent but few are ever entered.
• Requests come in for phone numbers in countries you don't serve.
• Numbers arrive in sequences, such as the same prefix with the last digits counting up.
• Bursts of traffic outside normal hours.

Controls that work

No single control is enough. These work best together.

Limit how often codes can be sent

Rate-limit by phone number, by device, by IP address and by account. Add a growing wait between resends. Cap the total per number per day.

Only send where you do business

If your customers are in a few countries, block SMS to the rest. This one change removes a large part of the risk for most businesses.

Check the number before sending

Validate the format and the number type. Many providers can tell you whether a number is mobile, landline or virtual, and its country, before you pay to send to it.

Make automation harder

Add a bot check (a CAPTCHA or an invisible challenge) before a code is sent, not after. Watch for signs of scripted traffic: the same device fingerprint, no normal page interaction, impossible speed.

Watch the ratio

Track codes sent against codes successfully entered, per country and per hour. Alert when it drops. Set a spending alert with your SMS provider.

Offer alternatives to SMS

Email codes, authenticator apps and passkeys cost nothing per message and are harder to abuse. SMS can stay as a fallback rather than the default.

Protect the user too

Don't confirm whether a number has an account. Limit codes per number so one person can't be flooded, and never ask users to read a code back to anyone.

A hypothetical example

A restaurant group launches a loyalty programme where guests join by entering their phone number and receiving a code. Within days, the messaging bill is far higher than expected, but member numbers have barely moved. Most requests are for numbers in countries where the group has no restaurants.

The fix is a combination: send codes only to the countries where it trades, limit resends per number and per device, add a bot check to the join page, and alert when codes sent and codes entered drift apart.

Where to start

1. Find every place your product sends an SMS.
2. Restrict destination countries.
3. Add rate limits and a spending alert.
4. Then add bot checks and monitoring.

Phishing & account abuse covers this alongside account takeover and fake sign-ups. The same controls belong in any loyalty or sign-up flow from the start.

Sources

• OWASP Automated Threats to Web Applications
• OWASP Multifactor Authentication Cheat Sheet