CVE-2024-0553 is a high severity (7.5 in NVD) timing side channel in GnuTLS RSA-PSK key exchange, an incomplete fix for CVE-2023-5981. Red Hat rates it Moderate. On RHEL 9, RHSA-2024:0533 fixes it in gnutls-3.7.6-23.el9_3.3. Other distributions need their own advisories.
What's affected
- Product: GnuTLS, RSA-PSK ClientKeyExchange handling.
- Affected: the record lists GnuTLS broadly, plus Fedora 39 and RHEL 8.0 CPEs. Check your distribution for exact ranges.
- Fixed: RHEL 9 gets gnutls-3.7.6-23.el9_3.3 through RHSA-2024:0533. Other RHEL versions use other advisories listed in the record.
- Severity conflict: NVD scores it 7.5 (High). Red Hat rates the advisory Moderate. Both are given here.
- It is designated an incomplete resolution for CVE-2023-5981.
How to check if you're exposed
- Run gnutls-cli and ask it for its version to read the library version.
- On RPM systems run rpm -q gnutls, and on Debian family systems run dpkg -l libgnutls30. Compare against your vendor advisory.
- Check whether your servers use RSA-PSK cipher suites at all, in the GnuTLS priority strings or application config.
Keep a record of what you find. An inventory that lists the product, version and owner turns the next advisory into a lookup instead of a search. Safeguard's dependency scan runs in the browser for the software you build.
What to do now
- Install the vendor update for gnutls, for example the RHSA package on RHEL 9.
- Restart services that link GnuTLS so they load the new library.
- Prefer cipher suites other than RSA-PSK where you can.
- Check containers and static builds that bundle their own GnuTLS.
- Use the free scan at gold.safeguard.sh/scan to find GnuTLS in your dependencies.
Why it matters
The weakness is CWE-203, observable discrepancy. Responses to malformed ciphertexts in RSA-PSK key exchange take a different time than responses to ciphertexts with correct padding. A remote observer who measures the timing could learn something about secret data.
The earlier fix for CVE-2023-5981 did not close every difference, which is why this one was filed. The record carries no known exploited flag. Timing attacks need many measurements, so exposure depends on whether RSA-PSK is in use. That is also the quickest mitigation.
Try it yourself
The demo below walks through the same workflow on sample data.
Click through it at your own pace, or open it full screen.
Quick check
Why do the scores differ?
NVD gives 7.5 High, while the Red Hat advisory rates it Moderate. Vendors weigh real world use of RSA-PSK, which is uncommon. Follow the severity your vendor assigns for patch timing.
Does restarting matter?
Yes. Running processes keep the old library in memory until they restart.
Sources
I fetched RHSA-2024:0533. I did not read the other advisories in the record.
Last reviewed: 19 October 2026.
