Asterisk STIR/SHAKEN verification NULL pointer dereference enables remote denial of service

Asterisk is an open source private branch exchange and telephony toolkit. In versions up to and including 18.26.2, between 20.00.0 and 20.15.0, 20.7-cert6, 21.00.0, 22.00.0 through 22.5.0, there is a remote DoS and possible RCE condition in asterisk/res/res_stir_shaken /verification.c that can be exploited when an attacker can set an arbitrary Identity header, or STIR/SHAKEN is enabled, with verification set in the SIP profile associated with the endpoint to be attacked. This is fixed in versions 18.26.3, 20.7-cert6, 20.15.1, 21.10.1 and 22.5.1.

• Asterisk < 18.26.3 is affected; the corresponding fix is 18.26.3.
• Asterisk >= 20.00.0, < 20.15.1 is affected; the corresponding fix is 20.15.1.
• Asterisk >= 21.00.0, < 21.10.1 is affected; the corresponding fix is 21.10.1.
• Asterisk >= 22.00.0, < 22.5.1 is affected; the corresponding fix is 22.5.1.
• The certified branch >= 20.7-cert6, < 20.7-cert7 is affected; the vendor advisory identifies 20.7-cert7 as the fix.
• The supplied source description conflicts with the structured affected data and CNA advisory by naming 20.7-cert6 as a fixed version. For the certified branch, the structured affected data and vendor advisory should take precedence.

The affected component is asterisk/res/res_stir_shaken /verification.c in the STIR/SHAKEN verification path. The code searches the Identity header for a semicolon with strchr. If the required header section contains no semicolon, the returned pointer can be NULL, but the code still calculates len by subtracting that pointer from ctx->identity_hdr. The resulting invalid value is then used by ast_malloc() and memcpy(), which can crash Asterisk; the vendor advisory states that RCE may also be possible, but does not establish it as a reliably exploitable outcome. Exploitation requires a reachable affected endpoint with STIR/SHAKEN verification configured in its SIP profile and an attacker able to supply an arbitrary Identity header. The available evidence does not establish how reliably the resulting memory condition can be controlled, so RCE should not be treated as confirmed.

The issue is network-reachable when the relevant Asterisk endpoint can receive SIP traffic from an attacker. The stated conditions are that the attacker can set an arbitrary Identity header, or that STIR/SHAKEN is enabled with Verification configured in the SIP profile associated with the targeted endpoint. The supplied assessment describes low attack complexity, low required privileges, and no user interaction. The vendor advisory includes proof-of-concept material, and the record marks a public exploit as available. The available evidence does not establish in-the-wild exploitation; denial of service is demonstrated, while RCE remains a possible outcome.

The primary technical outcome is loss of Asterisk process or service availability while processing an unsuitable Identity header. Calculating a length from a NULL pointer and using that value for memory allocation and copying can cause a crash; the advisory also notes possible RCE, but does not demonstrate that RCE is reliably controllable. The direct affected scope is the Asterisk component handling the request, and the available evidence does not confirm data modification or access to confidential data. Operationally, a telephony service may be interrupted and may require failover or recovery if triggering requests are repeated.

• A suitably formed SIP request can crash or destabilize Asterisk, interrupting call processing and reducing telephony service availability.
• If the memory-safety condition can be controlled beyond a crash, possible RCE would expand the impact from service disruption to compromise of the host, but the advisory does not confirm a reliable RCE exploit path.
• The demonstrated direct impact is on Asterisk availability. The available evidence does not establish data disclosure or data modification.

1. Upgrade Asterisk to the exact fixed release for the deployed branch: 18.26.3, 20.15.1, 21.10.1, 22.5.1, or 20.7-cert7, as applicable. Do not assume that a fix in one branch covers another branch.
2. After upgrading, verify that the running package or build is actually the fixed release, especially for certified branches and repackaged distributions.
3. If an immediate upgrade is not possible, identify SIP profiles with STIR/SHAKEN Verification enabled and endpoints reachable from untrusted sources. Disabling or restricting the affected verification path may reduce exposure if operationally acceptable, but the record and advisory do not provide a confirmed vendor workaround.
4. After patching or changing configuration, test call handling and STIR/SHAKEN verification, then review res_stir_shaken error and crash logging.

• Inventory Asterisk deployments, including certified branches, and compare installed releases with the fixed boundaries documented in the advisory.
• Inspect SIP profiles to determine whether STIR/SHAKEN is enabled and whether Verification applies to endpoints reachable from untrusted sources.
• Establish whether an attacker on a relevant network path can control the Identity header before it enters the verification path.
• Review logs and crash reports for res_stir_shaken/verification.c, ast_stir_shaken_vs_verify, allocation failures for the encoded JWT, or segfault events.
• Absence of these log events does not prove that a system is safe; combine configuration, reachability, and version checks.