It was found that SSLSocket in Smack did not perform hostname verification. An attacker could redirect traffic between an application and an XMPP server by providing a valid certificate for a domain under the attacker's control.
It was reported  that Smack (XMPP client library) is vulnerable to MitM attacks with a crafted SSL certificates.
Quote from :
Smack is using Java's `SSLSocket`, which checks the peer certificate
using an `X509TrustManager`, but does not perform hostname verification.
Therefore, it is possible to redirect the traffic between a Smack-using
application and a legitimate XMPP server through the attacker's server,
merely by providing a valid certificate for a domain under the
In Smack versions 2.2.0 to 3.4.1, a custom `ServerTrustManager`
implementation was used, which was supplied with the connection's server
name, and performed hostname verification. However, it failed to verify
the basicConstraints and nameConstraints of the certificate chain
and has been removed in Smack 4.0.0.
Applications using Smack 2.2.0 to 3.4.1 with a custom `TrustManager` did
not benefit from `ServerTrustManager` and are vulnerable as well, unless
their own `TrustManager` implementation explicitly performs hostname
Created smack tracking bugs for this issue:
Affects: fedora-all [bug 1127277]
smack-3.2.2-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products:
Red Hat JBoss Fuse 6.2.0
Via RHSA-2015:1176 https://rhn.redhat.com/errata/RHSA-2015-1176.html