CVE-2026-57189 in Asterisk
Summary
by MITRE • 10/27/2026
Asterisk is an open source private branch exchange and telephony toolkit. In affected deployments, an authenticated attacker may cause a `T.140 RED` out-of-bounds write during `generation accumulation` using carefully crafted packets, potentially allowing remote code execution or causing Asterisk to crash. The `chan_sip` channel driver must be installed and configured, and its `textsupport` option must be enabled; `textsupport` defaults to no. `The chan_sip driver was deprecated in Asterisk 20 and completely removed in all later versions.` Repository comparisons verify patch containment in Asterisk 20.20.1, 21.12.3, 22.10.1 and 23.4.1, and Certified Asterisk 20.7-cert11 and 22.8-cert3. The affected release-track scope remains unresolved: structured metadata includes later release tracks even though the advisory says the required `chan_sip` driver was removed there.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Asterisk, a widely deployed open-source private branch exchange and telephony toolkit, represents a critical security flaw within its legacy Session Initiation Protocol channel driver. Specifically, this issue manifests as an out-of-bounds write during the generation accumulation phase of T.140 RED processing when handling carefully crafted packets from an authenticated attacker. The technical root cause lies in improper memory management practices where input data is not sufficiently validated before being written to a buffer that has insufficient size allocation for the specific payload characteristics. This type of flaw is classically categorized under CWE-787, which denotes out-of-bounds write vulnerabilities, and often falls within the scope of CWE-120 if it involves buffer overflow conditions leading to memory corruption. The exploitation potential is severe because such memory corruptions can allow an attacker to overwrite adjacent memory structures, potentially achieving arbitrary code execution with the privileges of the Asterisk process or causing a denial of service through application crashes.
From an operational perspective, the impact of this vulnerability extends beyond simple data integrity issues due to its direct link to remote code execution capabilities. An authenticated adversary who can send SIP messages containing malicious T.140 RED packets could manipulate the stack or heap memory layout of the Asterisk server. This manipulation may facilitate the injection and execution of shellcode, granting the attacker full control over the underlying operating system. Alternatively, if exploitation for code execution fails due to modern mitigations like ASLR or DEP, the instability caused by the out-of-bounds write will likely result in a segmentation fault, leading to service disruption for all telephony endpoints relying on that specific Asterisk instance. The requirement for authentication does not mitigate risk entirely, as insider threats or compromised credentials can easily bypass this barrier, making it essential to treat authenticated vectors with equal severity to unauthenticated ones in many enterprise environments.
The remediation landscape is complicated by the deprecation and subsequent removal of the vulnerable component within newer versions of Asterisk. The chan_sip channel driver, which contains the flawed code path for T.140 RED generation accumulation, was deprecated starting with version 20 and has been completely removed in all later releases. Consequently, upgrading to any version beyond the affected range effectively eliminates this specific attack vector by removing the vulnerable code entirely. For organizations still running versions prior to these removals, such as Asterisk 20.20.1, 21.12.3, 22.10.1, and 23.4.1, or Certified Asterisk variants like 20.7-cert11 and 22.8-cert3, patching is the primary mitigation strategy. However, a critical nuance exists in the release track metadata; while newer tracks have removed chan_sip, some structured advisories may still list them as affected due to legacy tracking mechanisms, creating confusion about whether upgrades are strictly necessary for those specific versions if they no longer include the driver by default or design.
To mitigate this risk effectively, administrators must first determine their current Asterisk version and configuration state. If running a vulnerable release where chan_sip is installed, immediate application of the vendor-provided patch is required. For environments that have not yet upgraded to newer versions, disabling the textsupport option within the chan_sip channel driver serves as an effective temporary workaround since this vulnerability relies on T.140 support being enabled. Given that textsupport defaults to disabled in many configurations, verifying this setting can provide immediate relief without code changes. However, relying solely on configuration hardening is less robust than applying official patches or upgrading to a version where the chan_sip driver has been removed entirely. This approach aligns with ATT&CK techniques related to initial access and execution via SIP-based attacks, emphasizing the need for strict input validation and component lifecycle management in telephony infrastructure security architectures.