AI Threat AlertCVE-2025-8556: CIRCL FourQ: low-order point flaw weakens key exchange
LOWCVE-2025-8556 is a flaw in the FourQ elliptic curve implementation of Cloudflare's CIRCL Go cryptography library, where missing point validation and low-order point injection during Diffie-Hellman exchange can weaken session security. This is a general-purpose crypto library issue rather than an AI-specific one; it reaches AI/ML estates only indirectly, through container images (Red Hat OpenShift AI, RHEL AI InstructLab, Pipelines, Service Mesh) that bundle CIRCL as a Go dependency. Risk is low: CVSS is 3.7 with high attack complexity and confidentiality-only impact, it is not in CISA KEV, no public exploit or Nuclei template exists, and no EPSS score is available. Track it through your container vulnerability scanner and apply the vendor-patched images from Red Hat and CIRCL v1.6.1 or later on the normal patch cycle, with no emergency response needed.
What is the risk?
Low overall. The CVSS 3.1 score is 3.7 (AV:N/AC:H/PR:N/UI:N), with only limited confidentiality impact and no integrity or availability effect. Exploitation needs a network position that lets the attacker manipulate key exchange traffic, plus a target that actually uses FourQ DH from CIRCL, which is a niche curve choice. There is no KEV listing, no public exploit and no scanner template. Exposure in AI/ML is incidental: it is limited to bundled Go binaries in Red Hat container images, with no direct AI-specific attack surface. EPSS data is unavailable, so likelihood is judged from complexity and the narrow use of FourQ.
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade the CIRCL Go module to v1.6.1 or later, and rebuild any Go binaries that vendor it. 2) For Red Hat products, apply the updated container images referenced in the Red Hat advisory (access.redhat.com/security/cve/CVE-2025-8556) and bugzilla 2371624. 3) Use SBOM and container scanning (for example Trivy, Grype or ACS) to find images embedding github.com/cloudflare/circl. 4) Check whether any in-house code calls the FourQ DH API directly, and add explicit validation of public keys and rejection of low-order points if so. 5) Prefer standard curves (X25519, P-256) with TLS 1.3 for session establishment. 6) No special detection signal exists, so track remediation through vulnerability management.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2025-8556?
CVE-2025-8556 is a flaw in the FourQ elliptic curve implementation of Cloudflare's CIRCL Go cryptography library, where missing point validation and low-order point injection during Diffie-Hellman exchange can weaken session security. This is a general-purpose crypto library issue rather than an AI-specific one; it reaches AI/ML estates only indirectly, through container images (Red Hat OpenShift AI, RHEL AI InstructLab, Pipelines, Service Mesh) that bundle CIRCL as a Go dependency. Risk is low: CVSS is 3.7 with high attack complexity and confidentiality-only impact, it is not in CISA KEV, no public exploit or Nuclei template exists, and no EPSS score is available. Track it through your container vulnerability scanner and apply the vendor-patched images from Red Hat and CIRCL v1.6.1 or later on the normal patch cycle, with no emergency response needed.
Is CVE-2025-8556 actively exploited?
No confirmed active exploitation of CVE-2025-8556 has been reported, but organizations should still patch proactively.
How to fix CVE-2025-8556?
1) Upgrade the CIRCL Go module to v1.6.1 or later, and rebuild any Go binaries that vendor it. 2) For Red Hat products, apply the updated container images referenced in the Red Hat advisory (access.redhat.com/security/cve/CVE-2025-8556) and bugzilla 2371624. 3) Use SBOM and container scanning (for example Trivy, Grype or ACS) to find images embedding github.com/cloudflare/circl. 4) Check whether any in-house code calls the FourQ DH API directly, and add explicit validation of public keys and rejection of low-order points if so. 5) Prefer standard curves (X25519, P-256) with TLS 1.3 for session establishment. 6) No special detection signal exists, so track remediation through vulnerability management.
What systems are affected by CVE-2025-8556?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, MLOps orchestration, container-based model deployment, service mesh for model serving.
What is the CVSS score for CVE-2025-8556?
CVE-2025-8556 has a CVSS v3.1 base score of 3.7 (LOW). The EPSS exploitation probability is 0.53%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001AI SoftwareCompliance Controls Affected
What are the technical details?
Original Advisory
A flaw was found in CIRCL's implementation of the FourQ elliptic curve. This vulnerability allows an attacker to compromise session security via low-order point injection and incorrect point validation during Diffie-Hellman key exchange.
Exploitation Scenario
An attacker with a man-in-the-middle position between two internal components, such as a pipeline controller and a worker in an MLOps platform, substitutes a low-order FourQ public key during the Diffie-Hellman handshake. Because CIRCL does not correctly validate the point, the shared secret falls into a tiny predictable set. The attacker can then guess or brute-force the session key and read some of the exchanged data, for example pipeline parameters or artifact metadata. This needs a custom protocol that uses FourQ, a privileged network position and high attack complexity, so it is unlikely in practice.
Weaknesses (CWE)
CWE-1287 — Improper Validation of Specified Type of Input: The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
- access.redhat.com/security/cve/CVE-2025-8556vdb-entryx_refsource_REDHAT
- bugzilla.redhat.com/show_bug.cgiissue-trackingx_refsource_REDHAT
- github.com/cloudflare/circl
- github.com/cloudflare/circl/security/advisories/GHSA-2x5j-vhc8-9cwm
- github.com/cloudflare/circl/tree/v1.6.1
Timeline
Related Vulnerabilities
CVE-2026-68598.8InstructLab: RCE via hardcoded trust_remote_code flag
Same package: instructlabCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageCVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply Chain