Since KWallet is still the default password manager in KDE, I think this deserves an update.

Current Status, Apr 2021

The security bugs originally discussed in this question and the answers from 2013 (particularly Tom Leek's answer) are disclosed in CVE-2013-7252, which links back to the same blog post that was referenced in this question, which itself links back to Tom Leek's analysis here.

These issues have since been addressed. In particular, GPG support was added in kde-runtime 4.12, the password encryption was improved in 4.13, and the ECB/CBC issue was addressed in KDE Applications 14.12.1 and KF5::KWallet 5.6.0.
(Note: As I understand, in the latter link, "kde-runtime KWallet" refers to the older "KWallet 4", and "KF5::KWallet" refers to the newer "KWallet 5".)

Modern KWallet should not have these vulnerabilities, at least when using the GPG support (this post suggests using Kleopatra instead KGPG to set this up). But that is not to say there aren't any other vulnerabilities. For example:

1. The password database and GUI manager are unlocked together. While the DB is unlocked, no additional password is required to view the stored passwords. Anyone with access to the PC can view every stored password as plain text via the GUI. This is made worse by the common practice of leaving it unlocked for the entire duration of a user's session.
2. Likewise, the DB itself is stored as plain text while its unlocked. During this time, the DB security is only as good as the filesystem security (and in fact worse, due to other access options such as point 1 above).
3. Any application can query the DB via CLI, and there's no isolation between different applications' passwords. So a malicious application can potentially query another application's password. (To be fair, this is likely a problem with other password stores as well.)
4. When an application requests access to the wallet, the message is not always clear on which application is attempting access. So it can be difficult to tell if it's a legitimate request. Furthermore, it's easy to impersonate a valid application for such requests.
5. It was, and likely still is, vulnerable to keylogger and ptrace attacks.

This thread from 2016 on the Plasma-devel mailing list provides more details.

Some of these can be reduced at the cost of some user convenience, by disabling auto-unlocking, enabling auto-locking, and requiring a prompt each time an application tries to access the wallet. In addition, don't store highly-sensitive secrets together with your application passwords, and use two-factor-authentication for the really sensitive stuff like your email (which can be used to reset many of your other passwords), bank account/website, and credit card/website passwords.

PAM auto-unlock:

Auto-unlock itself already reduces security as noted above, but according to ArchWiki, it's actually worse:

• kwallet-pam is not compatible with GnuPG keys, the KDE Wallet must use the standard blowfish encryption.
• The wallet must be named kdewallet (default name). It does not unlock any other wallet(s).

So you get either GPG or auto-unlock, not both; and the default wallet name is easy for a malicious script to guess.

KSecretsService, QtKeyChain, libsecret

Back in the day, there was an attempt to replace KWallet with KSecretsService, aka KSecrets. This was an implementation of the FreeDesktop Secret Service API draft, which is also implemented by GNOME Keyring. But this was abandoned due to lack of developer time, and newer developments in the Linux ecosystem.

This was discussed on the Plasma-devel mailing list, and the consensus seemed to be to migrate the KDE apps to QtKeyChain, which would separate the API from the backend implementation. I don't know if that decision was followed, but given the level of activity on QtKeyChain, that seems like a reasonable assumption (this post somewhat confirms that as well).

A few months later, QtKeyChain added support for libsecret, which is also based on FreeDesktop Secret Service (included since QtKeyChain 0.8). More recently, libsecret is now required by QtKeyChain (unless disabled).

libsecret itself is a replacement for libgnome-keyring (but with no GNOME dependencies), so GNOME applications should also be migrating to libsecret.

KeePassXC and KDE Integration

KeePassXC is the modern successor of KeePassX, itself a Linux port of KeePass. KeePassXC is cross-platform via Qt5. It added libsecret support as of version 2.5.0 (2019). Theoretically (haven't tested this myself yet), this should allow KDE apps to communicate with KeePassXC, if those KDE apps use QtKeyChain.

Disclaimer

I AM NOT A SECURITY EXPERT. The information provided herein is merely a summary of what I found with Google. I am not responsible for any damages, loss of data or finances, security breaches, inconvenience, and so forth, resulting from your use of the information or advice provided herein. USE AT YOUR OWN RISK.

References

1. CVE-2013-7252
2. Bug 1048169 - CVE-2013-7252 kwallet: crypto misuse [fedora-all] - Bugzilla
3. KDE Security Advisory 9 January 2015
4. The situation of KWallet, and what to do about it? - Plasma-devel mailing list, 2016
5. How secure kwallet is - KDE Forum
6. Taming KDEwallet: Using GPG - Thoughts on computing
7. Unable to configure Kgpg kwalletmanager - AskUbuntu
8. Unlock KDE Wallet automatically on login - ArchWiki
9. KSecretsService - KDE.org, KSecrets - GitHub
10. Secret Service API Draft - FreeDesktop.org
11. Libsecret revealed - LWN.net
12. libsecret in Focal - Ubuntu Packages
13. QtKeyChain commits history - GitHub
14. QtKeyChain PR62: Added libsecret support - GitHub
15. KeePassXC PR2726: Implement Freedesktop.org Secret Storage - GitHub