CVE-2026-24044
Insecure Key Generation in ESS Community Helm Chart Allows Impersonation
Publication date: 2026-02-12
Last updated on: 2026-02-13
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| element | ess_community_helm_chart | 25.12.2 |
| element | matrix_tools | 0.5.7 |
| element | matrix_tools | 0.5.8 |
| element | synapse | 1.144.0-ess.2 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-336 | A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-24044 is a critical vulnerability in the Element Server Suite Community Edition (ESS Community) Helm Chart for Matrix Synapse. The issue stems from an insecure server key generation method used by the secrets initialization hook (via the matrix-tools container before version 0.5.7). This weak key generation allows network attackers to potentially recreate the same server key pair, enabling them to impersonate the victim server within the Matrix federation.
The vulnerability occurs when the Helm Chart’s secrets initialization hook generates the server signing key if both initSecrets.enabled is not set to false and synapse.signingKey is undefined. Since the server key authenticates both requests and events originating from the server, exploitation can compromise the confidentiality, integrity, and availability of rooms where the vulnerable server is a member. However, confidentiality of past conversations in end-to-end encrypted rooms is not affected.
The root cause is identified as CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG), where the PRNG uses the same seed on each initialization, leading to predictable key generation. The issue was fixed in matrix-tools version 0.5.7 and included in ESS Community Helm Chart 25.12.1.
How can this vulnerability impact me? :
This vulnerability can allow network attackers to impersonate a vulnerable Matrix server by recreating its server key pair. Because the server key authenticates both requests and events originating from the server, an attacker could compromise the confidentiality, integrity, and availability of rooms where the vulnerable server is a member.
Specifically, attackers could send malicious requests or events that appear to come from the legitimate server, potentially disrupting communication or injecting false information. However, the confidentiality of past conversations in end-to-end encrypted rooms is not impacted.
Deployments that expose federation APIs to untrusted networks are particularly at risk. Deployments that do not use federation or only federate within a closed, trusted federation are not affected.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "To detect this vulnerability on your system, you can run a shell script that uses curl and jq against your Synapse homeserver. This script checks if the server's public keys include the known bad key (ed25519:0) and whether that key has been revoked."}, {'type': 'paragraph', 'content': 'Servers that previously published the bad key may remain vulnerable to federation impersonation due to caching, so verifying the presence and revocation status of this key is critical.'}] [3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the ESS Community Helm Chart to version 25.12.2 or later, which includes matrix-tools version 0.5.7 or higher. This update fixes the insecure key generation method.
The update automates remediation by generating a new signing key, revoking the old signing key, and re-signing all existing events with the new key, provided that initSecrets.enabled is not set to false and synapse.signingKey is undefined.
It is strongly advised not to enable public federation without first applying this update, especially if your deployment exposes federation APIs to untrusted networks.