{"vuid":"VU#615987","idnumber":"615987","name":"Missing IPsec Integrity Protection for IMS SIP Signaling in Verizon VoLTE Deployments","keywords":null,"overview":"### Overview \r\nVoLTE deployments on Verizon’s IMS network have operated without negotiated SIP integrity protection. In observed test conditions, SIP signaling—including registration, call setup, and messaging—traveled without IPsec ESP encapsulation and without SIP Security Agreement headers, exposing it to interception and modification by on-path attackers.\r\n\r\nRecent carrier configuration updates, including Apple’s iOS 26.5 carrier bundle released on May 11, 2026, include IMS IPsec–related settings. However, such configuration entries do not confirm active deployment, successful negotiation, or functional protection in production.\r\n\r\n### Description\r\n**CVE-2026-10629**\r\nVerizon IMS deployments were observed transmitting SIP signaling without integrity protection. REGISTER exchanges lacked Security-Client, Security-Server, and Security-Verify headers, and no ESP-encapsulated SIP traffic was detected during subsequent signaling such as INVITE, MESSAGE, BYE, and UPDATE. This pattern persisted across devices, operating systems, and network conditions, indicating a deliberate network configuration rather than a transient issue.\r\n\r\nPer 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF must be protected using IPsec ESP following IMS AKA authentication, with negotiation occurring during registration. The absence of this protection allows attackers to manipulate SIP signaling undetected, enabling call hijacking, spoofing, denial-of-service, and misrouting of emergency calls.\r\n\r\nVerizon initially acknowledged the issue and stated that integrity support would be available upon request and extended broadly later in the year. However, the company has since ceased participation in coordination, including follow-up discussions and draft review, and has not provided verifiable evidence of mitigation. As remediation remains unconfirmed, this disclosure proceeds to inform users of an ongoing security exposure.\r\n\r\nIndependent verification would require observation of successful SIP security negotiation, ESP-protected traffic, or official confirmation from Verizon.\r\n\r\n### Impact\r\nWithout integrity protection, on-path attackers can intercept, replay, or alter SIP messages with no risk of detection. This undermines core VoLTE security assumptions and enables signaling spoofing, call disruption, and manipulation of emergency routing.\r\n\r\nAlthough recent configuration changes suggest potential progress, their operational status remains unverified. Until protections are confirmed, the risk persists.\r\n\r\n### Solution\r\nRemediation requires coordinated network and device-side changes. Verizon must enable and enforce SIP security negotiation and ESP protection in its IMS core infrastructure, and devices must receive and apply correct carrier configuration to support IPsec.\r\n\r\nVerification should confirm successful SIP security negotiation and ESP-protected signaling, either through observed headers, traffic capture, or operator confirmation.\r\n\r\nUntil then, organizations relying on high-assurance VoLTE should treat signaling as untrusted\r\n\r\n### Acknowledgements\r\nThe authors thank DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their technical analysis, coordination efforts, and identification of the iOS 26.5 configuration updates. Their work has advanced understanding of this issue and ensured disclosures remain grounded in observable evidence.\r\nThis report was prepared by Timur Snoke, with AI-assisted drafting to support clarity and accuracy.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://www.3gpp.org/DynReport/33203.htm","https://www.gsmaindex.com/standards/IR.92","https://datatracker.ietf.org/doc/html/rfc5247","https://datatracker.ietf.org/doc/html/rfc3329"],"cveids":["CVE-2026-10629"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-06-02T14:27:25.637433Z","publicdate":"2026-06-02T14:27:25.480924Z","datefirstpublished":"2026-06-02T14:27:25.648571Z","dateupdated":"2026-06-02T17:27:49.520988Z","revision":4,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":202}