Verizon VoLTE Signaling Risk: What VU#615987 Actually Shows

CERT/CC says Verizon VoLTE SIP signaling has lacked IPsec integrity protection. The useful question is not panic, but what evidence proves mitigation.

2026-06-03 GIGATAP Team #security
#security advisory#VoLTE#Verizon

Verizon’s VoLTE signaling issue is not just a standards dispute. CERT/CC’s VU#615987 says SIP signaling in Verizon IMS deployments has historically lacked IPsec-based integrity protection, leaving registration and later signaling messages without cryptographic guarantees that they were authentic or unmodified.

Source: CERT/CC Vulnerability Notes, https://kb.cert.org/vuls/id/615987

The practical point is narrower than the headline risk and more useful: users should not treat Verizon VoLTE signaling as high-assurance until network-level IPsec enforcement is observed or Verizon confirms production deployment. A device-side configuration change may be a sign of movement. It is not proof of end-to-end protection.

What changed#

CERT/CC published Vulnerability Note VU#615987 on June 2, 2026. The note describes missing IPsec integrity protection for IMS SIP signaling in Verizon VoLTE deployments.

According to the source material, researchers observed live traffic over multiple weeks or months and consistently found no SIP Security Agreement headers and no ESP traffic. That matters because IMS/VoLTE signaling protection is expected to be negotiated during SIP registration and then carried through IPsec ESP for later signaling.

The report frames the absence as systematic, not a transient device or network condition. The observed pattern appeared across device models and network conditions. That does not automatically prove every Verizon VoLTE session is exposed in the same way, but it makes the finding harder to dismiss as a one-off capture artifact.

Verizon’s statement, dated May 11, 2026, said the referenced GSMA and 3GPP provisions appear not to be mandatory and that carriers have discretion to adopt the protocols. CERT/CC also notes that the reporter disputed this characterization, citing 3GPP TS 33.203 and GSMA IR.92 provisions that the reporter says describe mandatory IMS/VoLTE SIP signaling protection.

There is also a newer signal: researchers observed IMS IPsec-related entries in Apple’s iOS 26.5 carrier bundle, released May 11, 2026. That may indicate device-side support is now present or being prepared. The source is careful here, and the caution is warranted. A carrier bundle entry is not the same thing as production network enforcement.

Why this security advisory matters#

The risk is about signaling integrity. If SIP signaling is sent without cryptographic integrity and authenticity guarantees, an on-path attacker may be able to observe, modify, replay, or inject SIP messages without either endpoint detecting the change.

CERT/CC names potential impact areas including call hijacking, spoofing of SMS-over-IMS, denial of service through forged SIP messages, and manipulation of emergency call routing. These scenarios do not require compromise of the user’s phone, SIM, or Verizon backend. They depend on an attacker being positioned on the relevant path, such as through a compromised base station, femtocell, or IMS intermediary.

That distinction matters for security operations. This is not a normal app-level privacy risk where changing an app setting or using a better password directly reduces exposure. It sits below the user interface, inside carrier signaling architecture. The meaningful mitigation is carrier-side enforcement of integrity protection, not user behavior alone.

For enterprises, the operational lesson is simple: do not assume VoLTE signaling is a trusted channel for high-assurance workflows. Voice calls and SMS-over-IMS may still function normally while the signaling layer lacks the integrity properties that a security team might assume are present.

What to check before acting#

The strongest evidence of mitigation would be captured ESP traffic after SIP registration and visible use of the relevant SIP Security Agreement headers. Official confirmation from Verizon that IPsec integrity protection is enforced in production would also materially change the assessment.

Operators and security teams should separate three different facts:

  • Device support: a phone or carrier bundle may contain IMS IPsec configuration.
  • Network availability: the carrier may support the feature for some users or under some conditions.
  • Network enforcement: production sessions actually negotiate and use integrity-protected ESP traffic.

Only the third point reduces the risk described in the CERT/CC note.

For individual users, there is no clean client-side fix described in the source. Keeping devices updated is still sensible, especially if carrier bundle changes are involved, but updates alone should not be treated as proof that Verizon’s IMS network is enforcing IPsec integrity protection.

For organizations, the practical check is policy-level rather than forensic for most teams: avoid using carrier voice or SMS signaling as a strong authentication or safety-critical control where stronger channels are available. Where mobile network assurance matters, ask carriers for explicit evidence of IMS SIP integrity protection rather than accepting general network-integrity language.

Related reading from GigaTap: OpenSSF’s April signal: make security artifacts operational; 100% package test coverage is the point, not the slogan; Open Source Security Needs More Than Code.

What not to overclaim#

This advisory does not prove that every user was actively attacked. It does not establish a public exploit campaign. It also does not show that the iOS 26.5 carrier bundle change has already fixed the issue in production.

The source supports a sharper and more defensible claim: observed Verizon VoLTE SIP signaling lacked the expected IPsec integrity protection, and until network-level enforcement is verified, the risk remains credible for unprotected deployments.

The standards dispute is also unresolved in the material provided. Verizon characterized the provisions as discretionary. The reporter disputed that and cited 3GPP and GSMA sections as mandatory for IMS/VoLTE signaling protection. Readers do not need to resolve the legal or certification argument to understand the security point: without integrity protection, SIP signaling can be changed on path without the protection model users and operators would reasonably expect.

The right posture is therefore skeptical but bounded. Treat this as a real security advisory about carrier signaling assumptions. Do not inflate it into proof of exploitation. Do not downgrade it to paperwork because the exploit surface is not visible to normal users. The useful evidence now is operational: whether SIP security negotiation and ESP traffic are actually present in Verizon VoLTE sessions after the reported changes.