There is a german guide to privacy I read that has some real issues with Wire, most that I agree with [0].
I will Google translate it for you (ironic):
> "10/06/2017: Wire.com operational Security
> Wire.com is referred to as a new star among crypto messengers. I briefly looked at the (experimental) Linux version of Wire.com and found some significant security flaws:
> Mannings Bug: Wire.com has good end-to-end encryption based on Axolotl. The chats are all but unencrypted (!) Logged on the hard disk of the computer. The logging can not be switched off.
> The unencrypted storage of encrypted communication is not a bug but an epic FAIL!
> Access data: (Account name, password) to Wire.com account are also stored somewhere unencrypted on the hard drive. When starting the person does not have to authenticate in front of the screen but is automatically connected to all accounts.
> This is not a bug but a FAIL!
Remote Code Execution: The Linux Wire Client contains a lot of Javascript code. Updates for the Javascript code will be downloaded and executed via HTTPS from the Amazon Cloud. After a superficial examination, the authenticity of the executed code is not additionally cryptographically verified (this is a guess, not checked in the code!). Security therefore depends solely on HTTPS encryption.
The HTTPS encryption of the contacted wire servers app.wire.com, prod-assets.wire.com and prod-nginz-https.wire.com does NOT meet the BSI's requirements for secure HTTPS encryption. These servers are Amazon Cloud Server and Cloudfront Server (not your own infrastructure).
> DANE / TLSA or HPKP are NOT used to validate SSL certificates of HTTPS connections. In addition, no CAA record is defined in the DNS, which should actually be mandatory for HTTPS for a month. The security of the transport encryption between client and server thus does not correspond to the feasible state of the art.
> Potent attackers could attack with fake but valid SSL certificates as man-in-the-middle the communication to the wire servers, in combination with the remote code execution possibly also attack the end-to-end encryption (assumption!), and there are enough potent attackers who want to attack the encryption of crypto messengers.
The domain wire.com is not signed DNSSEC.
Instead of the privacy-friendly OCSP.Stapling, OCSP.Get is used and several CAs are contacted to verify SSL certificates via OCSP. OCSP.Get can be easily tricked, as M. Marlspike demonstrated in 2009.
It contacts third party servers that are not under the control of the operators (maps.googleapis.com, images.unsplash.com) to download anything.
> Conclusion: The operational security of Wire.com is not (yet) suitable for security-critical applications after a small, superficial test. In particular, whistleblowers should learn from Manning's example and not use it.
> Disclaimer: this is NOT an audit but a short test of the Linux version."
[0] https://www.privacy-handbuch.de/diskussion.htm