In East Africa, USSD is not legacy technology. It is critical infrastructure. Millions of people across Rwanda, Uganda, Kenya, and Tanzania rely on *182# and similar short codes for banking, mobile money, and payments every day. USSD works on any phone, requires no internet, and reaches populations that smartphones and banking apps cannot.
Yet USSD applications are among the most under-tested systems we encounter. They sit behind telecom gateways, out of reach of the standard web and mobile-app tooling most assessments rely on, so they are quietly left out of scope, despite moving real money for millions of customers every day. That gap is exactly where attackers look.
Why USSD is a security target
USSD services handle real money and real data. A typical USSD banking session involves authentication, account balance checks, fund transfers, bill payments, and airtime purchases. A vulnerability in any of these flows can lead to financial loss and regulatory consequences.
Unlike web applications that benefit from decades of security tooling and research, USSD has a smaller security community and fewer off-the-shelf testing tools. This creates a false sense of security for many organisations.
Common USSD vulnerabilities
From our experience testing USSD platforms for financial institutions, these are the vulnerability categories we find most often:
Session management flaws
USSD is session-oriented at the protocol level, but sessions are short-lived and the application layer must track state across menu interactions. We frequently find session tokens that are predictable, sessions that do not expire properly, or sessions that can be hijacked by manipulating parameters at the gateway level.
Authentication bypasses
USSD services often authenticate users by MSISDN (phone number) passed from the telecom gateway. If the application trusts this value without additional verification, an attacker with access to the gateway or API layer can impersonate any customer by simply changing the MSISDN parameter.
Insecure API backends
USSD front-ends typically communicate with backend APIs (often the same APIs used by mobile banking apps). We test both the USSD-specific gateway interface and the underlying API to find issues like missing authorisation checks, IDOR vulnerabilities, and data exposure.
Input validation failures
USSD menus accept numeric input, but the backend processing may be vulnerable to injection attacks if input is not properly sanitised before being passed to databases or downstream systems.
PIN handling weaknesses
How the USSD application handles PINs is critical. We look for PINs transmitted in cleartext, PINs logged in application logs, lack of brute-force protection, and PINs that are not properly hashed at rest.
No end-to-end encryption
USSD has no application-layer encryption. Traffic is protected over the air by the mobile network's radio ciphering, then crosses the operator's core network, the USSD gateway, and any aggregator between the operator and the bank without protection of its own. Every PIN a customer types into a USSD menu is visible to those intermediaries unless the institution adds compensating controls. This is a property of the protocol, not a configuration error, so the mitigation is architectural: minimise the sensitive data that traverses the channel, secure the bank-side integration links, and treat every intermediary as part of the attack surface.
A related problem is ownership. A USSD service typically spans three organisations: the bank, an aggregator, and one or more mobile network operators. Each assumes someone else has tested the chain end to end. In our experience, the contract boundaries between those parties are exactly where testing responsibility goes unassigned.
Real impact: In one engagement for an African bank, we found that manipulating a single parameter in the USSD gateway API allowed us to view any customer's account balance and recent transactions. The fix took the development team less than a day. Without testing, this vulnerability could have remained undetected indefinitely.
Our USSD testing methodology
Testing USSD services requires a different approach than standard web application testing. Our methodology covers:
- Gateway interface testing: intercepting and manipulating USSD requests at the telecom gateway integration point
- Session analysis: mapping how sessions are created, maintained, and destroyed
- Authentication testing: verifying that MSISDN validation cannot be bypassed
- Authorisation testing: ensuring users can only access their own accounts and transactions
- Backend API testing: full assessment of the APIs that power USSD menus
- PIN and credential handling: verifying secure storage, transmission, and brute-force protection
- Business logic testing: attempting to manipulate transaction flows, bypass limits, or exploit race conditions
For regulators and compliance teams
For institutions regulated by BNR, Regulation No 50/2022 mandates annual penetration testing and bi-annual vulnerability assessments. The regulation does not name individual delivery channels, but the intent is clear: testing must cover the systems that hold and move customer money. If USSD banking is one of those systems, your penetration testing scope should say so explicitly. A web-only assessment leaves a critical attack surface untested, and a scoping gap like that is difficult to defend in a supervisory review.
When requesting proposals from security firms, ask specifically whether they have experience testing USSD platforms and what their methodology covers. Not all penetration testing providers have the expertise to test these systems effectively.
USSD testing should be part of your broader VAPT programme. For BNR-regulated institutions, our BNR compliance guide explains the full requirements. For mobile money platform security beyond USSD, read mobile money security testing. For API-level vulnerabilities behind USSD gateways, see API security in banking.
How we can help
IMIZI Cyber is an offensive security firm based in Kigali, and USSD is a core part of how we test financial platforms for regulated institutions across Africa: banks, fintechs, telecoms, government ministries, and other supervised enterprises. Many penetration testing providers do not test USSD at all. We do, with the methodology and tooling to assess gateway integrations, session management, and the transaction-flow manipulation that standard web application testing misses entirely.
For details on our full testing methodology and deliverables, see our penetration testing service page. Contact us to include USSD in your next security assessment.