Skip to main content
CVE-2024-45191VulnerabilityPublished Updated

CVE-2024-45191: olm · n/a

Affects olmSource CVE Database V5

0

Not known to be exploited · CVSS 5.3 Medium · end of life, no fix coming : replace or isolate olm; no fix will be released.

Data as of 26 Oct 2026, 08:30 UTC

CVSS 3.1 base score
5.3Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 39% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
None coming – the product is end of life
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 22 Aug 2024

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

No fix will be released: olm is end of life. Replace it, or isolate it from untrusted networks until you can.

Affected software

ProductAffectedFixed in
GitHubmatrix-org/olmpkg:github/matrix-org/olmOther threatsAffected
  • <=3.2.16
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Organizations should first identify any use of libolm versions through 3.2.16 within their environments, particularly in Matrix protocol implementations. Since the affected versions are no longer supported and no official patches exist, the primary mitigation is to upgrade to a supported version of libolm that does not use vulnerable AES S-box lookup tables or employs constant-time cryptographic implementations. If upgrading is not immediately feasible, organizations should isolate affected systems from untrusted networks to reduce exposure to remote attackers. Employing network segmentation and strict access controls can limit attacker access to vulnerable components. Additionally, monitoring for unusual timing analysis attempts or side-channel attack indicators may help detect exploitation attempts. Developers should consider refactoring cryptographic code to use constant-time implementations that avoid lookup tables susceptible to cache-timing attacks. Finally, organizations should maintain awareness of updates from the libolm maintainers or Matrix community for any future patches or advisories.

Description

An issue was discovered in Matrix libolm through 3.2.16. The AES implementation is vulnerable to cache-timing attacks due to use of S-boxes. This is related to software that uses a lookup table for the SubWord step. This refers to the libolm implementation of Olm. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

References

Community reviews

Loading reviews…