Cloudanix VulnDB

CVE-2022-45197

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Dec 25, 2022

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

Software that connects to chat servers over encrypted links fails to verify it is really talking to the intended server, letting an attacker secretly read or change messages.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
Library
Class
Authentication Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The library performs no hostname validation on the TLS certificate presented by the remote XMPP server, allowing an attacker-controlled certificate to be accepted for any domain.

Why it matters to the business

Attackers can silently intercept, read, or alter all XMPP traffic, undermining the confidentiality and integrity of messaging, presence, and file-transfer flows used by dependent applications.

How an attack unfolds

An attacker positions a network device or rogue server between the client and the legitimate XMPP server, presents a certificate containing the target hostname, and the unauthenticated Slixmpp client completes the TLS handshake and proceeds to exchange stanzas over the attacker-controlled channel.

How to fix it

Upgrade slixmpp to version 1.8.3 or later; if an upgrade is not immediately possible, enforce certificate pinning or route traffic through a trusted proxy that performs proper hostname validation.

How to confirm the fix worked

Inspect the installed slixmpp package version and confirm it is 1.8.3 or newer; review application logs for successful TLS connections that previously would have used the vulnerable code path.

Typical attack path

  1. Place attacker-controlled endpoint or MITM device on the network path to the target XMPP server
  2. Obtain or generate a certificate containing the legitimate server hostname
  3. Wait for or trigger a Slixmpp client connection attempt
  4. Complete TLS handshake without hostname verification
  5. Read, modify, or inject XMPP stanzas at will

How to detect it

Search application and network logs for XMPP connections that completed TLS handshakes with certificates whose subject or SAN did not match the expected hostname; look for sudden changes in remote IP addresses or certificate fingerprints on established XMPP sessions.

What your security team should do

  • Prioritize upgrade of all slixmpp installations to 1.8.3 or later
  • Add dependency scanning rules to block future vulnerable releases
  • Enable TLS certificate logging for XMPP connections to detect anomalous certificates
  • Review downstream applications that embed slixmpp for exposure

The record

Slixmpp before 1.8.3 lacks SSL Certificate hostname validation in XMLStream, allowing an attacker to pose as any server in the eyes of Slixmpp.

Affected packages

Ecosystem Package Introduced Fixed
PyPI slixmpp 0 1.8.3
Debian:11 slixmpp 0 No fix
Debian:12 slixmpp 0 1.8.3-1
Debian:13 slixmpp 0 1.8.3-1
Mageia:8 python-slixmpp 0 1.8.3-1.mga8
SUSE:Package Hub 15 SP3 python-slixmpp 0 1.4.2-bp153.2.3.1
SUSE:Package Hub 15 SP4 python-slixmpp 0 1.4.2-bp154.2.3.1
Ubuntu:18.04:LTS slixmpp 0 No fix
Ubuntu:20.04:LTS slixmpp 0 No fix
Ubuntu:22.04:LTS slixmpp 0 No fix
Ubuntu:Pro:18.04:LTS slixmpp 0 No fix
Ubuntu:Pro:20.04:LTS slixmpp 0 No fix
openSUSE:Leap 15.3 python-slixmpp 0 1.4.2-bp153.2.3.1
openSUSE:Leap 15.4 python-slixmpp 0 1.4.2-bp154.2.3.1
openSUSE:Tumbleweed python-slixmpp 0 1.8.6-1.1

Related vulnerabilities