41 Million Smart Communications Subscriber Mobile Numbers Possibly Exposed by Critical Vulnerability

Overview

Today I’m disclosing a significant security vulnerability affecting Smart Communications (TEL) mobile subscribers in the Philippines. This vulnerability exposes customers’ mobile phone numbers through insecure API communications, potentially contributing to the recent surge in SMS spam and SIM swapping attacks that have plagued Filipino mobile users.

Discovery Timeline

• December 12, 2024: Initially discovered the vulnerability while analyzing network traffic with Wireshark
• April 15, 2025: Formal notification sent to Smart Communications with detailed findings
• April 18, 2025: No response received; publishing initial disclosure with limited technical details
• May 18, 2025: If no vendor response, technical details and proof of concept published

Disclosure Timeline

• May 18, 2025: Disclosure submitted to HackerOne Disclosure Assistance with Report ID #3151783 with Severity: Medium (4 - 6.9)
• May 18, 2025: Disclosure submitted to Google Play Store Review.

Technical Details

Information Diclosure via Unencrypted API call

The vulnerability exists in an API endpoint used by Smart Communications Mobile App. When users access the app, the server responds with a JSON payload containing a key called x-nokia-msisdn which contains the user’s full mobile phone number in plaintext.

This communication happens over standard HTTP rather than HTTPS, making it trivially interceptable on any network. The lack of encryption is especially concerning given the sensitive nature of the information being transmitted.

(click image to view full resolution)

Since http://app1.smart.com.ph/ also returns Bearer which is the bearer header authentication and x-application-token which is the JWT token; we can now exploit this fusther to get the information from https://app1.smart.com.ph/api/v2/quick-view?number=639190000000 without user login. We also able to reuse the token since it expires only after 5 days. Also note the query number query parameter is inconsequential – just a mere logging or security by obscurity.

(click image to view full resolution)

The response show all the same data from the app wthout login which includes:

Name	Field
Current load	"balance": "34.00"
Load expiration	"expiration": "08-DEC-2025 12:48AM"
Rewards point	"balance": "190.55",
Subscriptions	"name": "UNLI 5G DATA 599",
Sim registration	"register_sim_banner": null,

(click image to view full resolution)

Android Permission Bypass

Apps can now reliably steal a user’s mobile number with their consent, without needing to request the android.permission.READ_PHONE_STATE permission.\

Attack Vectors

1. Network Monitoring: Anyone on the WiFi network can intercept this traffic using common tools like Wireshark, instantly revealing mobile numbers of all Smart customers using their apps on that network.

2. Malicious Mobile Apps: While CORS protections prevent website-based exploitation, any application installed on the user’s device can directly query the vulnerable API to retrieve the x-nokia-msisdn value without requiring special permissions.

3. Hotspot Exploitation: Users sharing their mobile connection via hotspot are vulnerable to malware on connected devices accessing this API through the established connection.

Through additional reverse engineering using Frida and MITM proxy tools (you can also use PCAPdroid and apk-mitm for casual verfication), I was able to map numerous API method calls that transmit this sensitive information, suggesting the vulnerability is pervasive throughout their systems.

Impact Assessment

Based on the evidence gathered, I strongly believe this vulnerability has been actively exploited for years and represents a primary vector for how SMS spammers and SIM swap scammers have been able to:

• Gather comprehensive databases of active Smart mobile numbers
• Target specific subscribers with high confidence in number validity
• Execute sophisticated phishing campaigns with user-specific information
• Potentially facilitate SIM swap attacks by providing the first piece of information needed

CVSS Score

The unofficial CVSS score for this vulnerability is:

AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N/E:P/RL:X/RC:U/CR:L/IR:L/AR:L/MAV:N/MAC:L/MPR:N/MUI:X/MS:U/MC:N/MI:N/MA:N

This translates to a Medium severity vulnerability with network-based attack vectors requiring low complexity to exploit, with no authentication needed.

Recommendations for Users

While waiting for Smart Communications to address this vulnerability:

1. Limit app usage on hotspot: When possible, avoid sharing internet via hotspot to other devices such a laptops, tvboxes. etc.
2. Be cautious with app permissions: Minimize the number of applications installed on your device, particularly those requesting network access.
3. Monitor for suspicious activity: Be vigilant for unusual SMS messages, unexpected account access, or other signs your number may have been compromised
4. Consider secondary authentication: Where possible, use app-based authentication methods rather than SMS-based verification

Vendor Response

As of publication, Smart Communications has not responded to the vulnerability disclosure submitted on April 15, 2025. The vulnerability remains open and unaddressed.

Smart Communications has no publicly published contact information for vulnerability disclosure, so we also made best efforts to contact key persons that can act on our disclosure without success.

Name	Position	Response
Ronald Ryan Ruiz	Cyber Security Solution Architect, Strategist	No Response
Ma. Kristina Angela Ycasas	Cyber Security Operations (IAM) - Information Security Supervisor	No Response
Noel Perlas	VP - App Product Design & Management @ Smart Communications, Inc. / UI/UX Design	No Response
Favian Ong	IT Security Manager at Smart Communications	No Response

No response was received within 30 days of the initial disclosure (by May 18, 2025).

Responsible Disclosure

This disclosure follows standard responsible disclosure practices, giving the vendor appropriate time to address the issue before publishing technical details that could facilitate exploitation. The limited information provided here is sufficient to alert users to the risk without enabling new attack vectors.

Recommended Vulnerability Mitigation Plan

My suggestion for fast mitigation plan since this vulnerabiliy is already actively exploited long before this research is conducted.

Immediate Actions (0-7 days)

1. Implement HTTPS/TLS

   • Immediately deploy SSL certificates for all API endpoints, especially app1.smart.com.ph
   • Configure secure TLS 1.3 protocols with modern cipher suites
   • Implement HSTS (HTTP Strict Transport Security) to prevent downgrade attacks

2. Emergency Authentication

   • Deploy basic API authentication requirements for all endpoints (no dashboard without login)
   • Implement token-based authentication for mobile apps
   • Revoke and rotate any existing shared secrets (shorter jwt token lifetime)

3. Response Headers

   • Remove sensitive data from HTTP headers (especially x-nokia-msisdn, use session based id and pass the actual value via internal API call)
   • Implement proper Content-Security-Policy headers
   • Ensure Referrer-Policy is set to restrict information leakage

4. Communication

   • Acknowledge receipt of vulnerability report to researcher
   • Prepare customer communication strategy
   • Brief executive leadership on situation severity

Short-Term Actions (7-30 days)

1. API Architecture Overhaul

   • Implement proper OAuth 2.0 authentication flow for all APIs
   • Create secure token exchange that doesn’t expose subscriber identifiers
   • Implement rate limiting to prevent mass enumeration
   • Add request signing to prevent tampering and unauthorized access

2. Mobile App Updates

   • Push emergency updates to all mobile applications
   • Store sensitive data in secure app enclaves/keystores
   • Implement additional app-level encryption for sensitive communications

3. Monitoring & Detection

   • Deploy API monitoring for unusual access patterns
   • Implement alerts for potential mass-harvesting attempts
   • Create detection mechanisms for abnormal API usage

4. Subscriber Protection (especially for known user of the velnerable app)

   • Enhance SIM swap protection procedures
   • Implement additional verification steps for high-risk transactions
   • Review SMS spam filtering algorithms

---

I will update this post with any vendor response or patch information when available.