[Draft paper][1] linked from [efail.de][2].

TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common.

The issue is that un-validated deciphered ciphertext is made available to the email client, _and_ it acts upon it (e.g. following HTML links to addresses that an adversary collects), yielding a decryption oracle capable of deciphering a past or current ciphertext, and exfiltrating the plaintext.

It is fine to disable decryption functionality in the email client. It should remain so until that software (and any extension  it relies on) is checked or improved to suppress (or at least not automatically act upon and preferably flag as suspect) any deciphered plaintext that did not explicitly pass the [Modification Detection Code][3] test for OpenPGP, or a similar ckeck (to be defined) for S/MIME.

For OpenPGP, we can get back to manual use of the bare OpenPGP tool (e.g. `gpg`), checking from stderr output that an [MDC][3] check explicitly passed, otherwise not acting based on what's received, be it programmatically or manually. I have no workaround suggestion for S/MIME.
___
From [an official statement by the GnuPG and Gpg4Win teams](https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html):

> 1.  This paper is misnamed.  It's not an attack on OpenPGP.  It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned.
2.  This attack targets buggy email clients.  Correct use of the [MDC][3] completely prevents this attack.  GnuPG has had [MDC][3] support since the summer of 2000.

___
<sup>Update: based on that [comment][4] and [other answer][5], and subject to dust settling, in GnuPG v2 two things are questionable, even if done on purpose so as not to break compatibility:</sup><br>
<sup>- Returning a status code of 0 (and a mere warning) in the absence of [MDC][3], at least by default.</sup><br>
<sup>- A quirk specific to the Twofish algorithm prevents [MDC][3] error catching.</sup>

  [1]: https://efail.de/efail-attack-paper.pdf
  [2]: https://efail.de/
  [3]: https://tools.ietf.org/html/rfc4880#section-5.14
  [4]: https://crypto.stackexchange.com/q/59229/555#comment130304_59231
  [5]: https://crypto.stackexchange.com/a/59241/555