Unsafe HTML interpolation in Asterisk /httpstatus can enable reflected cross-site scripting

Asterisk is an open source private branch exchange and telephony toolkit. Prior to versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2, user supplied/control values for Cookies and any GET variable query Parameter are directly interpolated into the HTML of the page using ast_str_append. The endpoint at GET /httpstatus is the potential vulnerable endpoint relating to asterisk/main /http.c. This issue has been patched in versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2.

Asterisk is affected on the following release branches:

• 23.x: versions below 23.2.2 are affected; 23.2.2 is patched.
• 22.x: versions below 22.8.2 are affected; 22.8.2 is patched.
• 21.x: versions below 21.12.1 are affected; 21.12.1 is patched.
• 20.x: versions below 20.18.2 are affected; 20.18.2 is patched.
• Certified branch 20.7: versions below 20.7-cert9 are affected; 20.7-cert9 is patched.

The status of branches not listed is not established by the available evidence. A fix for one branch should not be treated as proof that parallel branches are unaffected.

The affected component is Asterisk's embedded HTTP server, specifically the handler associated with asterisk/main /http.c and GET /httpstatus. Any GET query parameter, including its name and value, can be rendered into the page, and Cookie names and values are also rendered directly into HTML table rows. The implementation uses ast_str_append to insert the data without HTML encoding or sanitization before output. This is CWE-79, Improper Neutralization of Input During Web Page Generation, commonly called cross-site scripting. The client controls these values and may be unauthenticated, but the advisory requires a user to interact with or view the resulting page. The exact browser context, deployment access controls, and chained impacts are not established by the available evidence.

• The affected endpoint is HTTP GET /httpstatus; actual reachability depends on how the embedded HTTP service is deployed. The CNA advisory describes adjacent-network reachability, while the normalized data also records network reachability, so exposure should be verified in the deployment rather than inferred from one scoring view.
• The supplied data indicates that no special privileges are required, and the advisory states that the client may be unauthenticated.
• The complexity is described as low, but user interaction is required because a user must render or view the page containing the reflected data.
• The normalized record sets public_exploit to false and leaves known_exploited unset. This is record status, not proof that exploitation is impossible or did not occur outside the available data.

Technically, the flaw can turn request-controlled data into active content in a browser that renders the status page. A successful XSS path may expose data available to that browser context or cause actions as the interacting user; the advisory also notes possible credential or token theft and CSRF chaining. No evidence establishes server-side code execution, direct privilege escalation, denial of service, or compromise without the required user interaction. Organizational consequences therefore depend on which users can reach and view /httpstatus and what credentials or sessions their browsers hold.

Successful exploitation could cause attacker-controlled script to run in a user's browser when the status page is rendered. The vendor advisory identifies possible follow-on paths including credential or token theft and CSRF chaining, but these are potential consequences rather than confirmed outcomes for every deployment. The available evidence does not establish a service-availability impact or direct server-side privilege escalation. Organizational impact depends on which users can reach and view /httpstatus and what credentials or sessions their browsers hold.

1. Upgrade Asterisk to the patched release corresponding to the deployed branch:

• 23.x branch: 23.2.2.
• 22.x branch: 22.8.2.
• 21.x branch: 21.12.1.
• 20.x branch: 20.18.2.
• Certified 20.7 branch: 20.7-cert9.

1. After upgrading, verify the package or build actually running on each node and recheck the GET /httpstatus handler. Do not use a fix in one branch to conclude that a parallel branch has been remediated.
2. If immediate upgrading is not possible, identify instances exposing the embedded HTTP service and reduce access to /httpstatus according to organizational network policy, such as limiting it to trusted administrative networks where appropriate. This reduces exposure but is not a vendor-confirmed fix.
3. The supplied record and advisory do not document a specific temporary mitigation. Continue tracking the branch-specific fix rather than inferring an open-ended version boundary.

• Inventory every Asterisk instance and compare each deployed release branch with the affected and patched boundaries in the affected summary.
• Determine whether the embedded HTTP server is enabled, whether GET /httpstatus is available, and which networks can reach it.
• Review reverse proxy, firewall, and related access controls to determine whether untrusted users can send requests to the endpoint.
• Review Asterisk, reverse proxy, or web gateway access logs for requests to /httpstatus, especially unusual query strings or client-supplied Cookies. This is precautionary supporting telemetry, not a vendor-confirmed indicator of compromise.
• In a test environment, inspect a safe response to confirm that request-controlled query and Cookie values are HTML-encoded before rendering. The absence of suspicious log entries does not prove that an instance is safe.