Executive Summary
The CERT Coordination Center publicly disclosed VU#615987 — tracked as CVE-2026-10629 — documenting that Verizon's Voice over LTE (VoLTE) network transmits SIP signaling without the IPsec ESP integrity protection mandated by 3GPP TS 33.203 and GSMA IR.92. Call audio (RTP media) remains encrypted, but the control-plane messages that set up, route, and tear down VoLTE calls travel without cryptographic integrity protection.
An on-path attacker can intercept, replay, or modify SIP traffic between the User Equipment (UE) and the carrier's P-CSCF — enabling call hijacking, caller-ID spoofing, denial of service, and manipulation of emergency-call routing. Verizon was notified on April 30, 2026, classified itself as Not Affected on May 11, 2026, and subsequently disengaged from coordination without providing verifiable mitigation evidence. The exposure affects tens of millions of U.S. subscribers and, per CERT/CC, signaling should be treated as untrusted until carrier-side fixes are independently verified.
Background: VoLTE, IMS, and the IPsec Mandate
Voice over LTE (VoLTE) carries voice as packet data over a carrier's IMS (IP Multimedia Subsystem) core. The two planes that matter here are independent: the media plane (RTP audio, secured by SRTP) and the signaling plane (SIP, which performs registration, call setup, and teardown). 3GPP TS 33.203 and GSMA IR.92 specify that after a successful IMS AKA authentication, the User Equipment (UE) and the carrier's P-CSCF must negotiate an IPsec ESP Security Association and encapsulate all subsequent SIP traffic inside it.
Negotiation is performed via the SIP Security Agreement mechanism (RFC 3329), exchanged in the REGISTER dialog using three headers:
Security-Client— mechanisms the UE supports (e.g.ipsec-3gpp)Security-Server— mechanism, SPI values, and ports chosen by the P-CSCFSecurity-Verify— integrity echo, verified inside the protected channel
Without that negotiation, the entire post-registration SIP dialog travels in the clear with no integrity check — even if the radio bearer is encrypted, the IMS overlay is not.
What the Researchers Observed on Verizon
The Kyung Hee team captured SIP traffic across multiple devices, operating systems, and radio conditions on Verizon's VoLTE network. The same pattern reproduced everywhere — ruling out device-side anomalies and pointing squarely at carrier-side P-CSCF configuration.
Observation 1 — Missing SIP Security Agreement Headers
Verizon's REGISTER exchanges did not include the Security-Client, Security-Server, or Security-Verify headers. With no SA negotiation, no IPsec parameters are ever established between UE and P-CSCF.
REGISTER sip:ims.mnc012.mcc311.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bK...
From: <sip:[email protected]>;tag=...
To: <sip:[email protected]>
CSeq: 1 REGISTER
Contact: <sip:[2001:db8::1]:5060>
Expires: 600000
# MISSING: Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; ...
# MISSING: Require: sec-agree
# MISSING: Proxy-Require: sec-agree
Content-Length: 0Observation 2 — No IPsec ESP on Post-Registration SIP
All subsequent control-plane methods — INVITE, MESSAGE, BYE, UPDATE — were transmitted without ESP encapsulation. A compliant deployment would carry these inside the negotiated SA; the Verizon captures showed plain SIP at the IMS layer.
This is not a bug in a single device or a build regression — it is a carrier-level policy outcome. The P-CSCF either does not advertise ipsec-3gpp, does not enforce Require: sec-agree, or accepts unprotected SIP after AKA. The fix has to land in the IMS core; no device-side workaround restores the missing integrity guarantee.
Standard vs Observed
| Element | Required by 3GPP / GSMA | Observed on Verizon |
|---|---|---|
Security-Client in REGISTER |
UE advertises mechanism + SPI + ports | Absent |
Security-Server in 401/200 |
P-CSCF returns selected mechanism | Absent |
Security-Verify on protected leg |
Echoed inside ESP for verification | Absent |
| IPsec ESP on SIP (UE ↔ P-CSCF) | Mandatory post-AKA | Not observed |
| SRTP on media (RTP) | Profile-dependent | Encrypted (unaffected) |
Attack Execution — What an On-Path Adversary Can Do
The flaw requires an on-path position on the SIP signaling channel — for example a rogue/relayed small cell, a compromised IMS transit element, or any actor sitting between the UE and the P-CSCF. With that vantage, the steps look like this:
REGISTER with IMS AKA. Verizon's P-CSCF authenticates the UE but does not negotiate IPsec ESP — SIP-SA headers are absent in both directions.INVITE, MESSAGE, BYE, UPDATE traffic crosses the path with no ESP wrapper and no MAC. The adversary can read, modify, drop, or replay any frame undetected.INVITE with arbitrary From — caller-ID spoofing. Inject BYE / CANCEL — drop active calls. Rewrite the SDP in an INVITE — redirect media. Modify Request-URI on an emergency call — reroute E911.Public Proof-of-Concept Status
As of June 9, 2026, no public proof-of-concept code, exploit script, or demonstration video has been released for CVE-2026-10629. The CERT/CC advisory references only the underlying standards (3GPP TS 33.203, GSMA IR.92, RFC 3329) and credits the Kyung Hee research team without linking a published paper.
The absence of a public PoC is not equivalent to absence of capability. The on-path primitives required — rogue base stations / IMSI catchers, SIP tampering tools (e.g. sipvicious, custom Scapy modules), and rogue IMS gateways — are widely available. A motivated adversary with physical proximity or transit access can reproduce the conditions independently. Treat this as exploitable in targeted scenarios today.
Vendor Position
Verizon argues that the GSMA and 3GPP provisions cited are not strictly mandatory and that carriers have discretion in how they implement protections. CERT/CC and the researchers dispute this reading, citing TS 33.203 §7 and GSMA IR.92 as requiring IPsec ESP for IMS / VoLTE signaling.
Verizon initially indicated integrity-protection support would be made available later in 2026 but stopped participating in coordinated disclosure and provided no verifiable mitigation evidence. The carrier's self-classification remains "Not Affected" — a status CERT/CC and the disclosing researchers do not accept.
Real-World Impact
The most consequential impact is not eavesdropping on a single call — it is the erosion of trust assumptions across every system that relies on the cellular signaling path. Caller-ID-based fraud screening, SMS-delivered second factors, and emergency-call routing all assume an integrity-protected control channel. CVE-2026-10629 invalidates that assumption for Verizon VoLTE subscribers until network-side remediation is verified.
Mitigation Guidance
For End Users (Verizon Subscribers)
There is no device-side toggle that fixes this — the remediation must land in Verizon's IMS core. What individual subscribers can control is how much they rely on cellular signaling for trust decisions.
End-User Actions
For Enterprises and High-Assurance Users
Organizational Actions
For Verizon (The Actual Fix)
- Enable and enforce
sec-agreeat the P-CSCF; advertiseipsec-3gppand require it on protected legs. - Drop or challenge any post-AKA SIP that is not encapsulated in the negotiated ESP SA.
- Publish independently verifiable evidence of rollout — conformance test results and captures — so CERT/CC can move the advisory off "unconfirmed remediation."
Detection Notes
Verification Approaches
REGISTER carries Security-Client and whether the P-CSCF responds with Security-Server.
sip && (sip.Security-Client || sip.Security-Server). Absence on a registration flow is the indicator.
ip.proto == 50 / ipv6.nxt == 50) on the UE↔P-CSCF leg post-AKA. None = no SA negotiated.
BYE / CANCEL on long-lived sessions, sudden SDP redirect mid-call, or caller-ID inconsistency with carrier-side records.
MITRE ATT&CK Mapping
| Technique | Name | Relevance |
|---|---|---|
T1557 |
Adversary-in-the-Middle | On-path tampering of SIP signaling between UE and P-CSCF |
T1565 |
Data Manipulation | Modification of INVITE, SDP, or Request-URI in transit |
T1036 |
Masquerading | Caller-ID spoofing via forged From headers |
T1499 |
Endpoint Denial of Service | Injection of BYE / CANCEL to drop active calls |
T1071.001 |
Application Layer Protocol: Web | Attack delivered via standard SIP / IMS protocol surface; no custom channel needed |
References
- CERT Coordination Center (CERT/CC) — VU#615987, Missing IPsec Integrity Protection for IMS SIP Signaling in Verizon VoLTE Deployments —
https://kb.cert.org/vuls/id/615987 - NIST National Vulnerability Database — CVE-2026-10629 —
https://nvd.nist.gov/vuln/detail/CVE-2026-10629 - 3GPP TS 33.203 — Access security for IP-based services (technical standard)
- GSMA IR.92 — IMS Profile for Voice and SMS (technical standard)
- IETF RFC 3329 — Security Mechanism Agreement for the Session Initiation Protocol (SIP) (technical standard)
Vulnerability Assessment
Deep technical analysis of vulnerabilities affecting your infrastructure — beyond CVSS scores to real-world exploitability and impact.
Attack Surface Intelligence
Passive mapping of your external presence — every exposed service, endpoint, and piece of infrastructure visible to the public internet.
Threat Hunting
Proactive detection of compromise indicators, APT activity, and post-exploitation artifacts across your email and identity infrastructure.
Dark Web Monitoring
Continuous surveillance of stolen credential markets, threat actor forums, and data leak channels. Know when you're being targeted before it becomes an incident.
.png)
.png)