Summary
Signaling exposure in IMS (VoLTE) via P-Access-Network-Info, exposing cell identifiers that can be mapped to approximate location. Observed in live production within Telia Norway’s network.
A telecom network exposed location-related data through its own signaling. No exploit. No intrusion. No bypass. Just standard protocol behavior returning more information than it should.
This case was uncovered by security researcher Harrison Sand at Mnemonic, in collaboration with NRK.
The approach was not particularly advanced. They initiated calls under normal conditions and inspected the signaling exchanged as part of call setup. The data was not visible in the device UI, but it was present in the signaling itself — observable with standard network analysis tooling when inspecting the network layer rather than the application layer.
That distinction matters. This was not about breaking into a system. It was about observing what the system was already returning.
At first glance, it looks like a local misconfiguration. In practice, it points to a broader class of architectural issues. The mechanism behind it is not specific to one operator and can exist beyond a single network, depending on configuration and boundary enforcement.
No exploit required
Reproducing the behavior required an active SIM, a device, and the ability to inspect signaling at the network level. No authentication was bypassed, no privileges were escalated, and no protocol boundaries were crossed.
The key observation was that during normal call setup, signaling responses contained additional context about the recipient — not because something was injected, but because it was already part of the response.
What actually happened
During call setup:
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;
utran-cell-id-3gpp=242020af11e8b115
This is not an obscure field. It is part of the 3GPP-defined SIP extensions used in mobile networks (RFC 7315).
The P-Access-Network-Info header describes the access network used by the device (3GPP TS 24.229), and is intended for use within trusted network domains.
The value identifies the serving cell — which can be mapped to a physical location.
What SIP signaling actually is
SIP (Session Initiation Protocol) is a control-plane protocol used to establish and manage sessions (RFC 3261).
It is not specific to mobile networks. SIP has been used for decades in VoIP systems, enterprise telephony and unified communications. What has changed is that in modern mobile networks, SIP is now embedded into the core infrastructure through IMS.
That shift is important.
Because SIP is no longer just an application protocol. It is part of the telecom control plane.
A typical call setup looks like this:
INVITE sip:+4700000000@operator.net SIP/2.0
SIP/2.0 100 Trying
SIP/2.0 180 Ringing
SIP/2.0 200 OK
ACK
Each of these messages is exchanged across multiple network components and can carry additional headers describing the context of the connection.
What IMS actually is (and why it matters here)
IMS (IP Multimedia Subsystem) is the control layer of modern telecom networks.
It sits between the access network (LTE / 5G) and the service layer, and is responsible for how sessions are established, routed and managed. Voice (VoLTE / VoNR), WiFi calling and other communication services all depend on IMS.
Architecturally, IMS separates access from service logic. That makes signaling — not payload — the authoritative layer for how communication is handled.
And SIP is the protocol that carries that signaling.
So when something leaks in SIP, it is not happening at the edge.
It is happening inside the core control plane of the network itself.
This is also why this is not just a Telia-specific issue. IMS architectures are standardized (3GPP), structurally similar across operators, and often built on overlapping vendor implementations. The behavior you see in one network can exist in others depending on configuration and boundary enforcement.
A real signaling fragment
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP ...
To: +4700000000
From: +4700000001
Call-ID: XXXXXXXXXXXXXXXX
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;
utran-cell-id-3gpp=242020af11e8b115
The issue is not the message itself.
It is the presence of contextual access data in signaling delivered beyond its intended scope.
Where this should have stopped
Headers like P-Access-Network-Info are defined as private and limited in scope (RFC 7315). They are intended for use within trusted domains, where network components need context about how a device is connected.
In a typical architecture, the header is added near the access edge, used internally for routing and policy decisions, and then removed or controlled before leaving that trust boundary.
That boundary is critical.
If it is not enforced consistently, internal context becomes externally visible.
Where the boundary likely failed
Possible failure points include incomplete header stripping at session border controllers (SBC), misconfigured trust boundaries, or signaling inspection layers that pass through more information than intended.
The open question is not whether the data was exposed — it clearly was. The question is how far it propagated.
This is now under regulatory scrutiny. The Norwegian Communications Authority (NKOM) has opened a formal supervisory case and described the situation as a serious security deviation.
The root cause will likely come down to where, in the signaling path, boundary enforcement failed.
Scale
This is not an isolated edge case.
SIP signaling is one of the most heavily exercised parts of a mobile network. Every call attempt, every registration, every session refresh generates signaling traffic.
At any given moment, large operators handle massive volumes of these messages continuously.
If a field like this is present in responses, it is not an isolated event. It is repeated constantly — across users, across sessions, across time.
In this case,the issue reportedly existed over an extended period.
That changes the nature of the problem entirely.
Detection
This is where it becomes uncomfortable.
Because this is exactly the type of issue that traditional monitoring struggles with.
There is no exploit signature. No anomaly in protocol behavior. No obvious failure in the system.
From a protocol perspective, everything looks valid.
SIP messages are still correctly formed. Sessions are still established. Services continue to function.
From the outside, nothing is broken.
Which means detection depends on something more subtle: understanding which parts of the signaling should never leave a given boundary.
If this sounds familiar, it’s because it is — this is exactly how metadata leaks tend to behave in distributed systems. More on that here: Metadata, identity and the shadows we leave behind
Either that visibility was missing, or the data was visible but not classified as sensitive.
Both scenarios are realistic in complex telecom environments. This reflects a broader pattern in distributed systems, where valid signaling and control plane behavior can expose more context than intended — explored in more detail here: Why signaling leaks are the hardest class of failures to detect
What this actually is
This is not a vulnerability in the traditional exploit-driven sense.
It is a case of valid protocol behavior returning more information than intended, consistently and at scale, over an extended period of time.
That is significantly harder to detect than an active exploit, because nothing is explicitly “wrong” in the way the system operates.
Practical impact
Cell identifiers can be mapped to approximate location.
In dense environments, that can mean 100–200 meters.
NRK demonstrated that police personnel, journalists and ordinary customers could be located in practice using this method.
The same mechanism applied to individuals working in national security, telecom regulation and data protection authorities, and could have been used to track political figures.
“We take this very seriously. The fact that location data has been openly accessible is deeply concerning.”
— Martin Albert-Hoff, Norwegian National Security Authority
At that point, this is no longer theoretical.
Closing
This condition was not hidden and did not require exploitation. It existed within normal signaling behavior and persisted over time as part of standard operation.
From an engineering perspective, this highlights a recurring class of issues: context leakage within trusted domains that becomes externally visible due to incomplete boundary enforcement.
If such exposure can occur once in a production environment, it must be assumed possible elsewhere.
The question is not whether the protocol allows it, but whether anyone is actually enforcing where it should stop.