CVE-2026-75330 in Super Diamond Server
Summary
by MITRE • 08/27/2026
The front-end interface /superdiamond/preview/{projectCode}/{module}/{type} of super-diamond-server <= 1.3.3 is vulnerable to SQL injection. The module parameter is directly concatenated into the SQL IN clause through StringUtils.split() and string concatenation without being parameterized and bound.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in super-diamond-server versions up to 1.3.3 represents a critical security flaw within its front-end interface, specifically targeting the endpoint /superdiamond/preview/{projectCode}/{module}/{type}. This component is responsible for rendering preview data based on project and module identifiers provided by the user or client application. The core technical deficiency lies in how the system processes the module parameter during database query construction. Instead of utilizing prepared statements with parameterized queries, which would safely separate code from data, the application employs direct string concatenation to build the SQL statement. This architectural decision bypasses the fundamental safeguards provided by modern database drivers against injection attacks.
The specific mechanism of exploitation involves the use of StringUtils.split() combined with raw string interpolation. When a user supplies input for the module parameter, this value is split and then directly inserted into an SQL IN clause without any sanitization or validation checks that would neutralize malicious syntax. An attacker can craft a specially crafted HTTP request where the module parameter contains valid SQL syntax followed by injection payloads. Because the database engine interprets these injected characters as part of the query structure rather than literal data, it allows for arbitrary command execution within the context of the database user account associated with the application.
This type of flaw is classically categorized under CWE-89, which defines Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The vulnerability enables a range of severe operational impacts depending on the privileges granted to the database service account. In its most basic form, it allows for unauthorized data disclosure, where sensitive project configurations, module definitions, or user-specific preview data can be exfiltrated through error-based or blind injection techniques. More critically, if the underlying database supports stacked queries and has sufficient permissions, an attacker could potentially modify existing records, delete critical configuration files stored in the database, or even execute operating system commands via specific database features such as xp_cmdshell in Microsoft SQL Server or UDFs in MySQL.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically when used to facilitate data exfiltration (T1048) or unauthorized access (T1078). The lack of input validation means that the attack surface is broad, allowing attackers to probe for vulnerabilities using automated tools designed to detect SQL injection patterns. The presence of this flaw in a server component suggests that any user with network access to the preview endpoint can potentially compromise the integrity and confidentiality of the entire super-diamond system's data layer.
Mitigation strategies must prioritize immediate remediation through code refactoring. The primary fix involves replacing all instances where the module parameter is concatenated into SQL queries with prepared statements or stored procedures that utilize bound parameters. This ensures that user input is treated strictly as data, preventing it from altering the logic of the executed query. Additionally, implementing strict input validation on the server side can provide a defense-in-depth layer. Validating that the module parameter matches an expected format, such as alphanumeric characters only, or checking against a whitelist of known valid modules before processing, would significantly reduce the risk surface even if code changes are delayed.
Beyond immediate patching, organizations should conduct a broader security review to identify similar patterns across other endpoints in super-diamond-server that may suffer from the same lack of parameterization. Enabling Web Application Firewall rules can offer temporary protection by detecting and blocking common SQL injection payloads before they reach the application logic. Furthermore, adhering to secure coding standards such as OWASP Top 10 guidelines will help prevent recurrence of this class of vulnerability in future development cycles. Regular static code analysis tools configured with strict SQL injection detection profiles should be integrated into the continuous integration pipeline to catch these issues early in the software development lifecycle.