What is the CVSS score of EUVD-2025-210323?

EUVD-2025-210323 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.4%.

How to fix or mitigate EUVD-2025-210323?

Within 24 hours: Identify and inventory all systems running OpenLink Virtuoso OpenSource v7.2.11 and assess whether untrusted external systems can submit SQL queries to the database. Within 7 days: Implement SQL input validation and parameterized queries at the application layer, deploy database firewall rules to detect malicious query patterns, enforce database access controls to trusted applications only, and implement query execution timeout limits. Within 30 days: Monitor OpenLink Virtuoso advisory channels for patched releases; develop and execute migration plan to upgrade to a patched version of OpenLink Virtuoso or alternative database platform.

Virtuoso OpenSource EUVD-2025-210323

| CVE-2025-61024 HIGH

SQL Injection (CWE-89)

2026-06-23 mitre

GHSA-7gcw-w6h6-wm6p

Denial Of Service SQLi Red Hat N A

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

6.5 MEDIUM

Network-reachable and low-complexity, but Virtuoso's SQL interface normally requires database credentials so PR:L is more honest than PR:N; impact is availability-only.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Red Hat

6.5 MEDIUM

qualitative

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 23, 2026 - 20:00 vuln.today

CVSS changed

Jun 23, 2026 - 18:22 NVD

7.5 (HIGH)

CVE Published

Jun 23, 2026 - 00:00 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

An issue in the sqlo_try_in_loop component of openlink virtuoso-opensource v7.2.11 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

AnalysisAI

Denial of service in OpenLink Virtuoso OpenSource v7.2.11 allows remote attackers to crash the database server by submitting crafted SQL statements that trigger a fault in the sqlo_try_in_loop SQL optimizer component. No public exploit identified at time of analysis, though SSVC indicates a proof-of-concept exists in the referenced GitHub issue. The flaw is tagged as SQLi-class (CWE-89) but the demonstrated impact is availability-only, with no confidentiality or integrity loss per the CVSS vector.

Technical ContextAI

Virtuoso OpenSource is a hybrid relational/RDF database and middleware server from OpenLink Software, commonly used as a SPARQL endpoint for linked-data and semantic-web deployments (e.g., DBpedia historically ran on Virtuoso). The defective function sqlo_try_in_loop lives in Virtuoso's SQL optimizer (sqlo = SQL Optimizer), which rewrites query plans for IN-list and loop predicates. CWE-89 (SQL Injection) is the assigned weakness class, but the manifestation here is an optimizer crash on malformed/edge-case SQL rather than classic data-exfiltrating injection, indicating insufficient input validation or unchecked state in the query-planning path that causes the server process to abort.

RemediationAI

No vendor-released patch identified at time of analysis; the only public reference is the upstream bug report at https://github.com/openlink/virtuoso-opensource/issues/1227, so administrators should monitor that issue and the openlink/virtuoso-opensource releases page for a fixed tag beyond 7.2.11. Pending a fix, restrict network exposure of the Virtuoso SQL listener (default TCP 1111) and any internet-facing SPARQL/HTTP endpoint (default 8890) to trusted clients via firewall or reverse-proxy ACLs, require authenticated SPARQL where possible (SPARQL roles), and enable automatic process supervision (systemd Restart=on-failure) so a DoS crash self-recovers - accepting the trade-off that an attacker can still loop the crash to keep the service flapping. Rate-limiting or WAF rules on the /sparql endpoint can blunt automated abuse but will not stop a low-volume targeted crash.