Is a chosen ciphertext attack on PGP still possible? In a paper from 2002 (pdf), Jallad et al describe a chosen ciphertext attack on PGP by taking advantage of the CFB mode that the block ciphers use under PGP. It's quite a devastating attack.

Is this attack still viable in 2016 or has PGP made changes?
RFC 4880, OpenPGP (superseded RFC 2440 which was up to date in 2002) contains a chapter on security considerations, which also discusses the decryption oracle attack Jallad et al described:


  In late summer 2002, Jallad, Katz, and Schneier published an
       interesting attack on the OpenPGP protocol and some of its
       implementations [JKS02].  In this attack, the attacker modifies a
       message and sends it to a user who then returns the erroneously
       decrypted message to the attacker.  The attacker is thus using the
       user as a random oracle, and can often decrypt the message.
  
  Compressing data can ameliorate this attack.  The incorrectly
       decrypted data nearly always decompresses in ways that defeat the
       attack.  However, this is not a rigorous fix, and leaves open some
       small vulnerabilities.  For example, if an implementation does not
       compress a message before encryption (perhaps because it knows it
       was already compressed), then that message is vulnerable.  Because
       of this happenstance -- that modification attacks can be thwarted
       by decompression errors -- an implementation SHOULD treat a
       decompression error as a security problem, not merely a data
       problem.
  
  This attack can be defeated by the use of Modification Detection,
       provided that the implementation does not let the user naively
       return the data to the attacker.  An implementation MUST treat an
       MDC failure as a security problem, not merely a data problem.
  
  In either case, the implementation MAY allow the user access to the
       erroneous data, but MUST warn the user as to potential security
       problems should that data be returned to the sender.
  
  While this attack is somewhat obscure, requiring a special set of
       circumstances to create it, it is nonetheless quite serious as it
       permits someone to trick a user to decrypt a message.
       Consequently, it is important that:
  
  
  Implementers treat MDC errors and decompression failures as
       security problems.
  Implementers implement Modification Detection with all due
       speed and encourage its spread.
  Users migrate to implementations that support Modification
       Detection with all due speed.
  


As a consequence, the OpenPGP packets "Sym. Encrypted Integrity Protected Data Packet (Tag 18)
" and "Modification Detection Code Packet (Tag 19)
" have been introduced, together forming an modification detection system (which is the proposed mitigation by Jallad et al):


  NON-NORMATIVE EXPLANATION
  
  The MDC system, as packets 18 and 19 are called, were created to
        provide an integrity mechanism that is less strong than a
        signature, yet stronger than bare CFB encryption.
  
  It is a limitation of CFB encryption that damage to the ciphertext
        will corrupt the affected cipher blocks and the block following.
        Additionally, if data is removed from the end of a CFB-encrypted
        block, that removal is undetectable.  (Note also that CBC mode has
        a similar limitation, but data removed from the front of the block
        is undetectable.)
  
  [...]


At least GnuPG uses these packets per default, which you can verify through gpg --list-packets or pgpdump:

$ echo "foo" | gpg --recipient a4ff2279 --encrypt | pgpdump
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xCC73B287A4388025
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA m^e mod n(4093 bits) - ...
        -&gt; m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
New: Symmetrically Encrypted and MDC Packet(tag 18)(63 bytes)
    Ver 1
    Encrypted data [sym alg is specified in pub-key encrypted session key]
        (plain text + MDC SHA1(20 bytes))


In GnuPG, you can enforce usage of the new packets through the --force-mdc option (which can also be applied permanently in gpg.conf). From man gpg:


  Force  the use of encryption with a modification detection code. This is always used with the newer ciphers (those with a blocksize greater than 64 bits), or if all of the
                recipient keys indicate MDC support in their feature flags.