Imagine if anyone could punch in a phone number from the largest U.S. cell carrier and instantly retrieve a list of its recent incoming calls—complete with timestamps—without compromising the device, guessing a password, or alerting the user.

Now imagine that number belongs to a journalist, a police officer, a politician, or someone fleeing an abuser.

This capability wasn’t a hypothetical.

Cover Image

I recently identified a security vulnerability in the Verizon Call Filter iOS app which made it possible for an attacker to leak call history logs of Verizon Wireless customers.

Call logs can be quite valuable, especially for nation states, as recently noted in coverage of the Salt Typhoon breach of telecom networks: https://www.nytimes.com/2024/10/25/us/politics/trump-vance-hack.html

Given that this data is of such value, you’d expect that both how it’s accessed, and who is given access would be closely guarded. However, as I found, this may not be the case.

High level overview:

In order to display your recent history of received calls in the Verizon Call Filter app, a network request is made to a server. That request contains various details such as your phone number and the requested time period for call records. The server then responds with a list of calls and timestamps for each.

So surely the server validated that the phone number being requested was tied to the signed in user? Right? Right?? Well…no. It was possible to modify the phone number being sent, and then receive data back for Verizon numbers not associated with the signed in user.

In short, anyone could lookup data for anyone.

This is of course a privacy concern for all. But for some this could also represent a safety concern.

Consider scenarios involving survivors of domestic abuse, law enforcement officers, or public figures—individuals who rely on the confidentiality of their communication patterns. Having their incoming call logs exposed is not just invasive; it’s dangerous.

Call metadata might seem harmless, but in the wrong hands, it becomes a powerful surveillance tool. With unrestricted access to another user’s call history, an attacker could reconstruct daily routines, identify frequent contacts, and infer personal relationships.

Timestamps can be cross-referenced with social media or public sightings to map physical movements. Repeated numbers expose private or burner lines, compromising whistleblowers, journalists, or abuse survivors.

This wasn’t just a data leak. It was a real-time surveillance mechanism waiting to be abused.

Technical details:

The Verizon Call Filter app uses the endpoint https://clr-aqx.cequintvzwecid.com/clr/callLogRetrieval to lookup call history for the authenticated user and display it in the app. 

This endpoint requires a JWT (JSON Web Token) in the Authorization header using the Bearer scheme and uses an X-Ceq-MDN header to specify a cell phone number to retrieve call history logs for.

A JWT has three parts: header, payload, and signature. It’s often used for authentication and authorization in web apps.

The payload in this case looked like:

{
    "sub": "SIGNED_IN_USER_PHONE_NUMBER_HERE",
    "iat": "1740253712",
    "iss": "df88f1ed1dfd9a903e4c8dca7f00089e134c6c4e0a566cd565147ba1dadf78a6",
    "secret": "REDACTED",
    "alg": "ECDSA-256",
    "exp": "1740255512"
}

sub stands for subject — it identifies who the token is about (usually the user ID). In this case that is a phone number of the signed in user.

What should have been happening, and did seem to take place on other endpoints for additional app functionality, is that the server would compare the phone number specified in the request to the user identifier (sub) in the JWT, to ensure that the user requesting the information should have access to it.

However, the /clr/callLogRetrieval endpoint was not validating that the phone number specified in the X-Ceq-MDN header matches the sub in the JWT payload, meaning it was possible to lookup call history logs for any phone number within the application by passing the desired phone number in the value of that header.

Example Vulnerable Request: HTTP Request

The issue I discovered impacted at least those who have the Verizon Call Filter service enabled (I did not test a number which had it disabled; I can’t rule out whether or not all Verizon numbers could have been impacted).

Based on https://www.verizon.com/support/call-filter-faqs/ and https://www.verizon.com/about/news/verizon-helps-customers-avoid-15-billion-robocalls I believe this service may be on by default for many/all Verizon Wireless customers, so in either case, it does seem this issue impacted either nearly all, or all customers.

While this endpoint only returned received calls for the specified phone number, I don’t believe that to be a major limitation on impact. For one, that’s still an immense amount of information. But also, for a targeted individual, this could stretch into a partial picture of outgoing calls as well, provided the outgoing calls were to other impacted Verizon customers.

Who is Cequint?

Interestingly, the domain name that hosts the API for this app is registered at GoDaddy, which is a bit unusual for a large company, especially one as big as Verizon.

WHOIS Data This led me to examine the domain name more closely, upon which I noticed it seemed to represent “CEQUINT VZW ECID”

VZW ECID would seem to be the Verizon Caller ID app, as the Android APK has the package name com.vzw.ecid https://play.google.com/store/apps/details?id=com.vzw.ecid&hl=en_US

But what about CEQUINT? That would seem to be a separate company.

The website http://www.cequint.com/ looks to be down, but crunchbase shows they are a telecom technology company specializing in caller ID services.

https://www.crunchbase.com/organization/cequint Cequint

As such, based on the GoDaddy registrar of the domain, and the Cequint keyword in the domain, I believe this issue may have ultimately lied in a server owned by Cequint.

This does raise questions: how much data does this obscure company without a website of their own have? And how well secured is it?

Timeline

  • 2/22/2025 - Discovered the issue and reported to Verizon
  • 2/24/2025 - Acknowledgment from Verizon of my report
  • 3/23/2025 - I requested an update as this appeared to me to be fixed
  • 3/25/2025 - Confirmation from Verizon that issue is resolved

I do want to credit Verizon for a quick response and fix. While I don’t have the exact date they fixed this issue, I believe it was sooner than when I retested the issue and noted on my side that it looked to be resolved. They were also prompt to acknowledge my report.