{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/615987#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### Overview \r\nVoLTE deployments on Verizon’s IMS network have historically lacked IPsec-based integrity protection for SIP signaling, contravening well-established requirements in 3GPP TS 33.203 and GSMA IR.92. As a result, SIP messages—including registration (`REGISTER`), call setup (`INVITE`), and messaging (`MESSAGE`)—were transmitted in plaintext without cryptographic guarantees of integrity or authenticity. Passive analysis of live traffic over multiple months confirmed the consistent absence of SIP Security Agreement headers and ESP traffic, indicating a systematic configuration decision rather than an isolated anomaly.\r\n\r\nIn response to repeated follow-up inquiries, Verizon stated on [insert date] that integrity support is “currently available at their request” and will be extended to all UEs “starting later this year.” Separately, the researchers recently observed that Apple’s iOS 26.5 carrier bundle (released May 11, 2026) includes IMS IPsec-related configuration entries—an indication that device-side support may now be active or enabled in newer software. While this change is promising, its real-world impact remains uncertain: there is no evidence yet that Verizon has modified its network to *enforce* IPsec, that the configuration is being activated per session, or that integrity is functionally operational in production deployments. Absent explicit verification (e.g., captured ESP traffic or official confirmation), this may reflect preparatory software changes rather than an end-to-end security upgrade.\r\n\r\nThe vulnerability remains active for the vast majority of Verizon VoLTE users during the unprotected period, and until network-level enforcement is observed and confirmed, the risk of on-path signaling manipulation endures.\r\n\r\n### Description  \r\n**CVE-2026-10629**\r\nSIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network.\r\n\r\nAccording to 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF in IMS networks must be protected using IPsec ESP with mandatory integrity following IMS AKA authentication. This protection is negotiated via SIP Security Agreement headers (`Security-Client`, `Security-Server`, `Security-Verify`) during registration and results in integrity-protected ESP traffic for all subsequent signaling messages.  \r\n\r\nHowever, observations conducted over several weeks on Verizon’s network showed no such headers in use. The `REGISTER` exchange lacked any security negotiation, and post-registration SIP traffic—including `INVITE`, `MESSAGE`, `BYE`, and `UPDATE`—traversed the network in plaintext over standard UDP/TCP, with no ESP encapsulation. This pattern was consistent across device models and network conditions, indicating a systemic configuration decision rather than a transient issue. The absence of integrity checking means any modification to SIP messages—including redirection of emergency calls or injection of fake message payloads—would go undetected by both the UE and the IMS core.\r\n\r\nNo technical justification for this deviation from globally adopted security practices has been provided by Verizon, and prior engagement failed to elicit a substantive response beyond the recent, non-binding commitment to future deployment.\r\n\r\n### Impact  \r\nThe lack of IPsec integrity protection enables on-path attackers—including those controlling femtocells, compromised base stations, or IMS intermediaries—to intercept, modify, replay, or inject SIP messages without detection. These capabilities permit call hijacking, spoofing of SMS-over-IMS, denial-of-service through forged `BYE` or `CANCEL`, and manipulation of emergency call routing—without requiring compromise of the UE, SIM, or backend infrastructure. Because SIP signaling lacks cryptographic integrity, all such modifications go unnoticed by both the UE and the IMS core, undermining core security assumptions of VoLTE. While the recently observed iOS 26.5 configuration change may signal progress toward a more secure implementation, its operational impact is yet to be demonstrated; until then, the risk remains real and unmitigated for users on unprotected deployments.\r\n\r\n### Solution \r\nUntil the vulnerability is fully mitigated by Verizon, users and enterprises should continue to assume VoLTE signaling is untrusted for high-assurance operations.\r\n\r\n### Acknowledgements  \r\nThanks to DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their thorough technical report, persistent follow-up efforts, and the additional observation regarding iOS 26.5. Their work has significantly advanced the understanding of this issue and helped keep the discussion grounded in observable behavior.  \r\nThis AI-assisted document was written by Timur Snoke.","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"},{"category":"other","text":"After reviewing the issue you raised, it appears the GSMA and 3GPP provisions you referenced are not mandatory, allowing carriers the flexibility to adopt the protocols at their discretion.  Verizon takes the integrity of its network very seriously and appreciates your outreach and concern with regard to this issue.","title":"Vendor statment from Verizon"},{"category":"other","text":"CERT/CC notes that the reporter disputed Verizon’s characterization of the referenced GSMA and 3GPP provisions as “not mandatory.” The reporter cited 3GPP TS 33.203 Sections 6.1.2–6.1.3 and GSMA IR.92 Clauses 7.3 and 14.3, which describe mandatory IMS/VoLTE signaling protection requirements involving IPsec integrity protection for SIP signaling.\r\n\r\nThe reporter further asserted that GSMA certification processes for VoLTE interoperability and deployment rely on compliance with these specifications. According to the report, observed network behavior indicating the absence of SIP Security headers and ESP traffic may be inconsistent with those specifications or may indicate the use of alternative compensating controls that were not disclosed during coordination.\r\n\r\nVerizon did not provide additional technical details regarding compensating security mechanisms or clarify which specific provisions it considered optional within the context of the reported behavior.","title":"CERT/CC comment on Verizon notes"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/615987"}],"title":"Missing IPsec Integrity Protection for IMS SIP Signaling in Verizon VoLTE Deployments","tracking":{"current_release_date":"2026-06-02T14:36:01+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.42"}},"id":"VU#615987","initial_release_date":"2026-06-02 14:27:25.480924+00:00","revision_history":[{"date":"2026-06-02T14:36:01+00:00","number":"1.20260602143601.2","summary":"Released on 2026-06-02T14:36:01+00:00"}],"status":"final","version":"1.20260602143601.2"}},"vulnerabilities":[{"title":"SIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network.","notes":[{"category":"summary","text":"SIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network."}],"cve":"CVE-2026-10629","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#615987"}],"product_status":{"known_not_affected":["CSAFPID-97368c6e-5e9f-11f1-8c68-0afff74df6a7"]}}],"product_tree":{"branches":[{"category":"vendor","name":"Verizon","product":{"name":"Verizon Products","product_id":"CSAFPID-97368c6e-5e9f-11f1-8c68-0afff74df6a7"}}]}}