Asterisk corrige six CVE (CERTFR-2026-AVI-0805) : RCE conditionnelle, heap-UAF PJSIP

Le CERT-FR a publié le 25 juin 2026 l'avis CERTFR-2026-AVI-0805 qui répercute la salve de six bulletins de sécurité publiés le même jour par le projet Asterisk sur son dépôt GitHub. Le lot mélange un contournement d'autorisation ARI avec RCE conditionnelle, un use-after-free PJSIP déclenchable à distance par un client SIP, et plusieurs primitives plus discrètes côté ARI et chan_unistim. Toutes les branches maintenues sont concernées ; les correctifs sont en 20.20.1, 21.12.3, 22.10.1, 23.4.1 ainsi qu'en Certified Asterisk 20.7-cert11 et 22.8-cert3.

Le CERT-FR résume les impacts globaux par « exécution de code à distance, déni de service à distance, atteinte à l'intégrité des données et contournement de la politique de sécurité ». Aucune exploitation active n'est citée à la publication.

Les CVE de la salve

Détail des six avis publiés sur le dépôt Asterisk le 25 juin 2026 :

• CVE-2026-57200 — ARI REST-over-WebSocket read-only bypass (GHSA-wcvv-g26m-wx5c). Haut, CVSS 7.5. Un attaquant authentifié avec des identifiants ARI read-only contourne les contrôles d'autorisation via le canal WebSocket et obtient un chargement arbitraire de module et une RCE conditionnelle. Prérequis : serveur HTTP activé (désactivé par défaut), accès réseau au HTTP (typiquement localhost), credentials ARI valides.
• CVE-2026-57202 — ARI setChannelVar bypasses live_dangerously and permits FILE() writes (GHSA-vrfp-mg3q-3959). Haut, CVSS 8.1 (vecteur AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Un compte ARI read-only peut exécuter des fonctions de plan de numérotation en écriture (dont FILE()) malgré l'option live_dangerously désactivée dans asterisk.conf. Rapporté par gmrvh.
• CVE-2026-57187 — Heap-use-after-free in PJSIP TCP/SDP handling when TCP connection closes during SDP processing (GHSA-g8q2-p36q-94f6). Haut, CVSS 7.1. Un attaquant authentifié envoie un INVITE SIP sur un transport orienté connexion (TCP/TLS) puis ferme la session avant qu'Asterisk n'émette son 200 OK — la condition UAF se déclenche à la fermeture pendant le traitement SDP. Impact direct : crash du serveur Asterisk (DoS).
• CVE-2022-37325 (correctif manquant) — chan_ooh323 Q.931 party-number parser (GHSA-h5hv-jmgj-92q2). Haut. Le correctif d'une faille H.323 publiée en 2022 n'avait pas été correctement appliqué à la branche courante du parseur Q.931 dans chan_ooh323 — la régression est corrigée dans la salve du 25 juin.
• CVE-2026-57194 — Out-of-bounds read in Q.931 Information Element Parser (H.323 Addon) (GHSA-746q-794h-cc7f). Modéré. Lecture hors limites dans le parseur Q.931 du module H.323, exploitable par un pair H.323 malveillant pour provoquer un crash ou exfiltrer de la mémoire adjacente.
• CVE-2026-57186 — chan_unistim DIALPAGE digit handling can overflow phone_number and crash Asterisk (GHSA-3g56-cgrh-95p5). Modéré. Dépassement de tampon dans la gestion des chiffres composés sur la page DIALPAGE des téléphones Unistim ; crash du processus.

Le mapping CVE ↔ GHSA est tiré directement des fiches GitHub liées ci-dessus. CVE-2026-57184 apparaît dans la liste de CVE relayée par le CERT-FR mais n'est pas associée publiquement à un GHSA dans les six bulletins listés sur le dépôt — consultez l'avis CERT-FR pour la correspondance officielle.

Périmètre concerné

• Asterisk 20.x antérieures à 20.20.1
• Asterisk 21.x antérieures à 21.12.3
• Asterisk 22.x antérieures à 22.10.1
• Asterisk 23.x antérieures à 23.4.1
• Certified Asterisk 20.x antérieures à 20.7-cert11
• Certified Asterisk 22.x antérieures à 22.8-cert3

Le projet annonce sur asterisk.org que tous les correctifs sont disponibles via les canaux habituels (tarballs, paquets distributions, image conteneur officielle).

Statut de l'exploitation

Aucun PoC public n'est référencé dans les six bulletins à la publication, et aucun éditeur de feed de threat intel n'a signalé d'exploitation active. Le profil d'attaque le plus tangible est CVE-2026-57187 : il suffit d'un compte SIP autorisé à envoyer un INVITE sur TCP/TLS pour faire tomber le service. Sur une plateforme de centre d'appels où plusieurs centaines de trunks SIP sont enregistrés, un seul compte compromis suffit à orchestrer un DoS répété.

Les CVE ARI (57200 et 57202) exigent des credentials valides ; elles sont essentiellement un risque côté mutualisation — opérateurs ou intégrateurs qui exposent une instance ARI partagée entre plusieurs équipes avec des comptes read-only censés ne rien pouvoir faire de dangereux. La promesse live_dangerously: no ne tient pas pour ces deux entrées.

Que faire

1. Mettre à jour vers la version corrigée de votre branche : 20.20.1, 21.12.3, 22.10.1, 23.4.1, ou Certified 20.7-cert11 / 22.8-cert3. Les paquets sont publiés sur downloads.asterisk.org et dans les dépôts communautaires. Pour les conteneurs, repasser sur le tag publié le 25 juin et purger le cache.
2. Si vous ne pouvez pas patcher immédiatement, désactiver le serveur HTTP d'Asterisk (http.conf → enabled = no) neutralise les CVE ARI 57200 et 57202 — c'est le défaut historique du produit, beaucoup d'installations l'activent uniquement pour ARI. Pour CVE-2026-57187, restreindre pjsip aux transports UDP en attendant le patch, si la topologie le permet.
3. Auditer les comptes ARI : tous les comptes marqués read-only sont à reclassifier tant que le patch n'est pas appliqué. Le bypass setChannelVar ne laisse pas de trace évidente côté logs applicatifs — la signature côté réseau est un volume anormal d'appels REST vers /ari/channels/{channelId}/variable.
4. Surveiller les crashs de processus Asterisk sur les passerelles exposées à internet. Un schéma INVITE sur TCP suivi d'un RST immédiat avant 200 OK, répété, est la signature d'une tentative d'exploitation de CVE-2026-57187 — auditd ou un watchdog sur pjsip détectent la séquence.
5. Pour les opérateurs hébergeant Asterisk pour plusieurs clients : forcer la mise à jour côté tenant, journaliser la version effective de chaque instance après bascule, et notifier les clients dont l'ARI était exposée derrière un reverse proxy authentifié.

Contexte

C'est la deuxième vague Asterisk de l'année documentée par le CERT-FR après l'avis CERTFR-2026-AVI-0538 du printemps. La cadence n'est pas surprenante pour un produit dont l'audit communautaire est actif et dont les surfaces — SIP, H.323, ARI, chan_unistim — exposent chacune un parseur historique différent. Le pattern récurrent reste l'ARI : surface REST récente, modèle de permissions à granularité grossière, et options de sécurité (live_dangerously) qui ne tiennent pas leurs promesses lorsqu'elles sont contournées par un canal alternatif (WebSocket, fonction de variable).

Pour les opérateurs de téléphonie d'entreprise et les hébergeurs de plateformes de centre de contact, l'avis du 25 juin renforce une règle déjà connue : un compte ARI n'est jamais vraiment read-only tant qu'Asterisk n'a pas durci le séparateur entre lecture et écriture au niveau du moteur de dialplan lui-même. En attendant cette refonte, la défense en profondeur passe par le réseau (HTTP désactivé, ACL stricte sur /ari) plutôt que par la configuration applicative.