What are the signs that a device is still vulnerable to auto-dial USSD abuse?

How to tell a device still auto-dials instead of asking first

The clearest sign is a user-controlled browser path that reaches the dialer without a permission step. If a page can trigger a call setup from a USSD string and the device immediately launches the action, the protection layer is not doing its job. A healthy device usually interrupts that flow with a prompt, chooser, or blocked action.

Another practical indicator is repeatable inconsistency. If one browser or Android build auto-dials while another on the same device family asks for confirmation, the vulnerability is likely tied to the browser, WebView, OEM dialer handling, or OS version rather than to the code itself.

What behaviors usually expose the weakness

Devices that remain vulnerable often show one of three patterns: they suppress confirmation entirely, they treat the code as if it were a normal telephone number, or they fail to distinguish between harmless display text and a live dialing action. That means the browser-to-dialer transition is too permissive, and the security control intended to stop silent dialing is missing or bypassed.

Testing should focus on observable behavior, not assumptions. A device that only misbehaves with certain browsers, older Android releases, or specific OEM dialers is still at risk if those combinations are present in your fleet. The sign you care about is not theoretical support for the bug, but whether an actual endpoint can still be pushed into dialing without explicit user consent.

Why the confirmation step matters more than the code itself

USSD abuse depends on a trust failure between the browser, the dialer, and the OS. The same code can be harmless when it is treated as plain text and dangerous when it is translated into a dial action. The security boundary is the confirmation moment, because that is where the user gets a chance to stop an unintended call or carrier action.

That is why mixed behavior across devices is such a strong signal. If the same harmless test input produces a prompt on one build and an immediate dial on another, the vulnerable device is not enforcing the expected boundary consistently. In practice, that means the issue is less about the specific code and more about whether the execution path still permits silent action.

Risk and Threat Considerations

When a device can still auto-dial USSD codes, a browser visit can become an unintended action path into carrier functions. That can expose users to account changes, balance checks, service toggles, or other effects that were never approved in the browser session.

Failure mechanism: The browser, WebView, or dialer converts a displayed string into an executable USSD request without an explicit consent gate, so the device treats remote content as an action instead of text.

Impact: An attacker can use a crafted page, link, or redirect to trigger unwanted carrier interaction, which can create fraud, privacy exposure, or device-specific service disruption.

Practitioner Guidance

What to verify: Test the same harmless USSD string across the browsers and Android versions you actually support, then record whether each path shows a confirmation prompt, a chooser, or an immediate dial. The useful evidence is the behavior difference, not just whether the test “worked.”

Decision rule: If any supported browser or build still auto-dials, treat that combination as vulnerable even if other devices block it correctly. Remediate the exposed path first, because a single permissive client can be enough for abuse in a mixed fleet.

Common mistake: Teams often validate only one browser on one phone model and assume the result generalizes. For this issue, the control is only real when the entire supported browser and OS matrix consistently requires user confirmation.

Practitioner takeaway: A device is still vulnerable if the browser-to-dialer path can execute a USSD string without an explicit user gate, especially when that behavior is inconsistent across browsers or OS versions.

Related resources from NHI Mgmt Group

• What are the signs that an endpoint security service may be vulnerable to abuse through process validation flaws?
• What are the signs that an organisation is still vulnerable to credential-based attacks?
• What are the signs that SaaS non-human identity abuse is still active after initial remediation?
• What are the signs that a build pipeline is vulnerable to living off the pipeline abuse?