Research on Vulnerability Detection Methods in SQL and NoSQL Systems Using Machine Learning and Large Language Models ^†

Abstract

SQL and NoSQL databases are at risk from injection attacks, which is one of the most serious threats to the security of today’s data-centric systems. To address this issue, this research proposes an architecture for evaluating a new hybrid technique for detecting vulnerabilities by using a mixture of lightweight statistical machine learning techniques and a semantically verified locally installed large language model (LLM). Specifically, the proposed detection architecture consists of three major parts: (1) an initial filtering phase that uses rapid filtering through TF-IDF vectorization and logistic regression; (2) a second phase that implements a confidence-based hybrid decision logic model; and (3) a third phase using a deterministic LLM to process semantically ambiguous queries. In our experimental evaluation of a balanced benchmark of 1000 queries (500 SQL and 500 NoSQL), our proposed hybrid method achieved the highest overall performance, yielding a precision of 0.998, recall of 0.986, and F1-score of 0.992. The individual ML model obtained a lower recall of 0.964 than the standalone LLM but had F1-scores (0.981) much higher than that of standalone LLM (0.667). The hybrid architecture reduced the number of false negatives (generated by the standalone ML models) from 18 to 7 and the number of false negatives generated by the standalone LLMs from 228 to 7. The hybrid architecture achieved very few false positives. Therefore, the use of hybrid ML-LLM detection pipelines will provide both greater robustness and practical effectiveness when doing database security monitoring.

1. Introduction

Modern databases remain vulnerable to injection attacks, which represent one of the most significant security risks for database-driven applications. Earlier research demonstrated the potential for NoSQL injection vectors by demonstrating how unstructured data can be uploaded into MongoDB and showcased real-world ramifications of insufficient input validation and schema enforcement [1]. Subsequent comparative studies showed that machine learning and large language models had complementary capabilities for detecting injection vulnerabilities in both SQL and NoSQL environments, where deep learning methods, with elastic pooling convolutional neural networks (CNNs), could detect up to 99% of SQL injection attacks, proving that they are efficient in identifying complex patterns of malicious queries [2,3]. The increase in publicly available vulnerability datasets has accelerated both progress in automated detection research and the ability to conduct repeatable experiments and benchmarks [4].

SQL injection detection has primarily relied on traditional machine learning algorithms because of their relatively inexpensive computational requirements and strong classification performance for structured query tasks [5]. Random Forest-based models for vulnerability prediction performed well across the various datasets tested, but only when combined with optimization methods targeting class imbalance. Work on neural network approaches to vulnerability detection in application source code demonstrated that balancing precision and recall is equally important in real-world deployments as it is during the development phase [6]. Extensive experimental evaluations showing detection accuracy alone do not necessarily provide enough evidence of the potential for successful deployment and require consideration regarding computational efficiency and operational effectiveness within production systems [7].

The introduction of large language model (LLM) technology has created new avenues for automating vulnerability analysis, such as security hardening and adversarial testing of software systems [7]. At the same time, the introduction of several publicly available, specialized benchmark datasets (such as datasets that contain historical records of attempts made to exploit SQL injection vulnerabilities in MongoDB) is helping mitigate the shortage of training data needed for NoSQL security research [8]. Researchers have also had success in using supervised learning, applying it successfully to detect NoSQL injection attacks and demonstrating that neural network classifiers can effectively classify semi-structured queries [9]. Further, researchers have found that using supervised text classification techniques (i.e., support vector machines and deep learning models) often outperform the traditional approaches used to detect NoSQL vulnerabilities. Additionally, deep neural network and dimensionality-reduction-based feature engineering approaches have also been developed to assist in identifying critical injection characteristics common to NoSQL queries, attaining high detection rates within controlled experimental settings.

Simultaneously, some researchers have investigated using large language models for identifying vulnerabilities and have concluded that task-specific fine-tuning of the models is required to obtain trustworthy security analysis results [10]. Meanwhile, adversarial machine learning has created significant security concerns associated with using machine learning by itself solely for cyber security, representing yet another justification for developing more resilient hybrid architectures that combine traditional cyber-security techniques with machine learning [11].

Open-source libraries, such as scikit-learn and imbalanced-learn, provide standardized implementations of many popular algorithms for classification, evaluation, and management of class imbalanced security datasets [12]. Publicly available SQL injection datasets made available through online research sites also allow consistent benchmarking of detection methods [11]. Achievements on deploying large language models as stand-alone solutions have made it possible to work with hybrid machine-learning/language-model (ML-LLM) systems in a controlled manner, which enables real experimentation.

SQL and NoSQL databases present different architectural features that affect the design of security models and protecting assets. Surveys of NoSQL databases show that while many NoSQL systems are designed with horizontal scalability, they also lack access control functions that compare with traditional relational database systems [13]. Broader surveys on cyber security in general indicate that more organizations are adopting ML as an option for intrusion detection and prevention across all industries. Despite these advantages, injection attacks remain one of the most common types of security threats in modern internet applications and rank among the highest in the annual list of global security issues.

Motivation

One of the biggest threats to modern databases is injection attacks. This threat is most prominent when SQL and NoSQL technologies are present together in an environment. Past research has shown that machine learning can deliver high levels of accuracy in detecting structured SQL injection patterns with low compute cost [5,6,7]. Additionally, deep learning can also help detect more complex malicious queries with high accuracy [3]. However, prior research has shown that stand-alone machine learning systems tend to have less robustness when confronted with semantically ambiguous queries, obfuscation of payload and deployment limitations [6,7].

New research into large language models (LLMs) has discovered how they can be used to perform semantic analysis on vulnerabilities and understand the security of programming languages [8,12]. Comparisons of systems detecting SQL or NoSQL injections using LLMs and machine learning-based solutions were found to be able to successfully complement one another in SQL vs. NoSQL injection detection [2]. Some limitations of purely using LLMs have also been noted in previous studies; these include higher costs, longer wait times, inconsistent results, and needing prompt design and task-specific ‘fine-tuning’ [8,12]. NoSQL databases are gaining popularity, but they bring additional security issues to both database administrators and developers, as compared to traditional relational databases due to reduced scheme enforcement and differing formatting of queries [1,9,14].

The limitations of existing vulnerability detection methods give rise to a need for hybrid architectures that utilize lightweight statistical filtering and semantic verification techniques. Prior research has suggested that the integration of machine learning (ML) and large language models (LLMs) will help automate security systems including vulnerability scanners and Web Application Firewalls (WAFs) [2]. As such, the present study proposes a hybrid ML/LLM vulnerability detection architecture consisting of TF-IDF vectorization, logistic regression classification, and a locally deployed LLM verifier which would verify ambiguous coinciding queries from users. The architecture will be tested using SQL and NoSQL injection datasets to assess its effectiveness, operational efficiency, and usability for monitoring database security.

2. Related Works

Earlier studies have explored methods for detecting SQL injections based on traditional machine learning techniques, including classical models like Naive Bayes Classification, support vector machines, Decision Trees [5], etc., as well as hybrid models: classification algorithms that combine multiple learning techniques (e.g., ensemble classification). Although they perform well when classifying SQL injection attempts, it is well reported that they usually demand a fair amount of effort to establish feature-engineering procedures, and in real production deployments they can be computationally heavy to apply.

2.1. Machine Learning for SQL Injection Detection

Several studies have been performed on classical and deep machine learning methods for detecting SQL injections. Gupta and Tyagi [5] have developed systematic studies on machine learning methodologies in detecting SQL injection attacks: they have explored Naïve Bayes, support vector machine, Decision Tree and ensemble approaches to improve their methods. They have shown good classification performance but indicate careful feature engineering is required in production. Xie et al. [3] introduced an elastic-pooling convolutional neural network and reached 99% accuracy in SQL injection detection, significantly outperforming classical classifiers. They tested and showcased how deep learning architectures could enable the detection of complex patterns in malicious queries. Arasteh et al. [6] examined SQL injection vulnerabilities in PHP code and found that CNN models had higher precision rates compared to other machine learning models, Multilayer Perceptron (MLP) achieved greater recall rates and Random Forest showed higher accuracy overall. Previous studies also evaluated machine learning models for detecting SQL injection attacks and reported that Naive Bayes classifiers achieved high accuracy rates in controlled environments. Their full evaluation gave useful guidelines for model selection in vulnerability-detection tooling. Chen et al. [4] proposed the new DiverseVul dataset, which provides 150 types of Common Weakness Enumeration (CWE) representations in a novel vulnerable source code collection for deep learning-based vulnerability detection.

2.2. Machine Learning for NoSQL Injection Detection

NoSQL injection detection is more limited but is growing, comparatively to SQL injection research. Ul Islam et al. [9] presented their supervised learning method in which seven ML classifiers were used to automatically detect NoSQL injection and found that the neural network is the most powerful system for detecting an injection attempt in NoSQL databases. Their results showed that for this aim, support vector machines (SVMs) and deep learning models outperformed traditional classifiers. Rameshwar et al. [8] did a valuable job by providing a comprehensive collection of MongoDB NoSQL injection attempts and vulnerabilities, “The MongoDB Injection Dataset,” available in Data in Brief. The data in this dataset addresses the critical shortage of publicly available NoSQL injection data and serves as a foundational input to train detection models and evaluate the model.

2.3. Large Language Models for Vulnerability Detection

As large language models have been emerging, researchers have started to explore their potential for code vulnerability analysis. He and Vechev [7] performed research on large language models for coding, especially security hardening and adversarial testing. In their work, they showed that fine-tuned LLMs were able to surpass traditional vulnerability scanners in certain situations. Gao et al. [10] also investigated the extent of the state-of-the-art of vulnerability detection through large language models and noted the need for task-based fine-tuning to enhance accuracy. Their study illuminated the promise and also the limitations of these LLM-based approaches for security applications. Maligazhdarova et al. [2] performed the most directly relevant comparative study, comparing ML models against a fine-tuned GPT-4o-mini-2024-07-18 model for SQL and NoSQL injection vulnerability detection. The study suggests that Random Forest reached 99% SQL injection accuracy and for NoSQL injection the fine-tuned LLM achieved 97%, indicating the complementary strengths of both methods.

2.4. Hybrid and Integrated Approaches

There is an increasing interest in recent studies in hybrid schemes that include mixed experimental approaches. For instance, previous studies on adversarial machine learning and cybersecurity robustness have demonstrated that ML-based security systems remain vulnerable to adversarial manipulation and require multi-level defense mechanisms [11]. This proved that machine learning (ML)-based security systems are susceptible and justify the construction of hybrid security systems with an increased resilience. Mukasheva et al. [1] investigated the impact of uploading unstructured data to MongoDB, using NoSQLBooster, on database vulnerabilities. The results demonstrate that there are real-world injection vulnerabilities present in the NoSQL databases. That kind of research develops a better idea of the attack surface within NoSQL and the lack of sufficient security measures. Also, the wider database and security context has been presented by Davoudian et al. [13]. These studies highlight the difference in architecture between SQL and NoSQL and the emerging role of ML solutions in enhancing security in cybersecurity.

2.5. Datasets and Reproducibility

Research into reproducible vulnerability detection is dependent on having access to high-quality datasets and standardized libraries for developing machine learning models. For this reason, Chen et al. [4] created the DiverseVul dataset. Meanwhile, Rameshwar et al. [8] provided a MongoDB injection-specific vulnerability dataset that can be utilized in web security research for NoSQL databases. Routinely used open-source machine learning libraries such as imbalanced-learn [12] can be employed to perform reproducible implementations of machine learning processes on cybersecurity datasets with imbalanced classes. In addition, the availability of publicly available SQL injection datasets from Kaggle can facilitate the ability to benchmark and evaluate vulnerability detection methodologies consistently. Currently, Maligazhdarova et al. [2] pointed out that there is still a lack of large-scale real-world datasets for NoSQL vulnerabilities, especially those based on exploitable source code for applications rather than simple malicious queries.

3. Problem Formulation and Methodology

Every query in the implementation is represented as a sparse vector, x, produced from a TF-IDF feature vector. Because they are both computationally efficient as well as resistant to degradation due to length, these two types of feature objects have been selected:

$$x=\mathrm{TFIDF}\left(q\right)$$

(1)

We use a logistic regression classifier to compute the probability that a query is vulnerable:

$$p\_\left\{\mathrm{M}\mathrm{L}\right\}(\mathrm{y}=\mathrm{V}\mathrm{U}\mathrm{L}\mathrm{N} | \mathrm{q})=\mathsf{\sigma }(\mathrm{w}^\mathrm{T}\mathrm{x}+\mathrm{b})$$

(2)

where the sigmoid activation is defined as follows:

$$\mathsf{\sigma }\left(\mathrm{z}\right)={\displaystyle \frac{1}{\left(1+{\mathrm{e}}^{\left\{-\mathrm{z}\right\}}\right)}}$$

(3)

For semantic classification, a local LLM (Llama3 via Ollama) receives the full query as a prompt and returns a binary decision:

$$d_{LLM}\left(q\right)\in \{\mathrm{SAFE},\mathrm{VULNERABLE}\}$$

(4)

A hybrid decision methodology compares between the probability score produced from a logistic regression model and determined threshold numbers. The machine learning (ML) stage classifies the queries with high confidence while uncertain cases will go through the large language model (LLM) to be semantically verified.

4. Proposed Hybrid Detection System

4.1. System Overview

The overall architecture of the proposed system is illustrated in Figure 1. The pipeline consists of three main stages: (1) a lightweight machine learning filter, (2) confidence-based hybrid decision logic, and (3) a semantic verifier based on a local large language model.

Figure 1. Hybrid detection architecture: ML filter, hybrid decision, LLM verifier.

4.2. ML Filter (Fast Path)

Query vectorization using TF-IDF combined with logistic regression classification serves as a high-speed executing filter at this stage, designed to identify common rules and patterns (based on keywords and syntactic hints) with minimal delay.

TF-IDF vectorizer uses n-grams in the range (1,3), with a maximum of 5000 features. The logistic regression model is trained with L2 regularization, using the ‘liblinear’ solver, with a random seed fixed at 42 and max_iter = 1000.

4.3. LLM Verifier

Also, for queries with an uncertain degree of ML trust and confidence, we call the local LLM (namely, the environment in this study is Llama3 via Ollama) with a short query that defines the introduction schemes and requests class verification. The query was created in such a way as to minimize hallucinations and unnecessary responses, etc. (examples are given in the model). We use a deterministic prompt passed to the LLM to minimize hallucinations:

You are a database security detection system.   Your task is to classify a query as VULNERABLE ONLY if it clearly demonstrates an injection attack.   Classify as SAFE if:   - the query is syntactically valid   - it does not modify logic using OR/AND injection   - it does not use operators such as $where, $ne, $regex for bypass   - it looks like a normal application query   IMPORTANT:   - Do NOT assume admin access is dangerous   - Do NOT flag queries as vulnerable without clear attack intent   - Be conservative: SAFE is preferred unless attack is obvious   Answer with ONLY one word:   SAFE or VULNERABLE   Query:   [QUERY]

4.4. Hybrid Decision Logic

Let ${\mathit{p}}_{\mathit{M}\mathit{L}}$ be the ML model’s predicted probability of VULN. We use two thresholds ${\mathit{\tau }}_{\mathit{l}\mathit{o}\mathit{w}}<{\mathit{\tau }}_{\mathit{h}\mathit{i}\mathit{g}\mathit{h}}$ and:

$$f{\_}_{hybrid}(q)\hspace{0.17em}=\hspace{0.17em}\left\{\begin{array}{c}\mathrm{SAFE},\hspace{1em}{p}_{ML}\le {\tau }_{low}\\ \mathrm{VULNERABLE},\hspace{1em}{p}_{ML}\ge {\tau }_{high}\\ d_{LLM}\left(q\right),\hspace{1em}{\tau }_{low} < p_{ML} < {\tau }_{high}\end{array}\right.$$

(5)

This design keeps LLM invocations minimal and ensures that ML confident decisions remain fast.

5. Dataset and Experimental Setup

5.1. Datasets

The task is to prepare datasets for training and testing injection detectors. We constructed two datasets. The SQL corpus contains 45,000 labeled SQL queries. The NoSQL corpus contains 1000 MongoDB queries (Figure 2).

Figure 2. Sample records from the constructed SQL and NoSQL datasets used in this study.

The SQL corpus is based on a publicly available dataset distributed through Kaggle [15]. The dataset contains approximately 30,000 labeled SQL queries, supplemented with 15,000 manually generated variations of attack patterns.

The NoSQL corpus is hand-built and contains 1000 MongoDB queries. The sample includes operator attacks: $where, $ne, $regex.

Qualitative insights from representative query samples tell us about an injection pattern; however, quantitative dataset properties are also required to properly train models and evaluate them. Class distribution is critical with regard to how a classifier can generalize, how to interpret results, and the amount of bias exhibited by the classifier.

We lowercased all SQL queries; removed or masked numeric literals/string constants; and anonymized common table/column names to generalize information. Tokenization was performed, and whitespace was used to preserve stop words when creating/logical structure in SQL queries.

5.2. Experimental Protocol

The experimental protocol used an 80/20 stratified train–test split. Hyperparameter tuning for ML models was performed using cross-validation on the training set. LLM prompts and invocation settings were kept constant throughout all experiments, while the LLM component was invoked only for the ambiguous subset identified by the ML classifier. Evaluation metrics included precision, recall, F1-score, false positive and false negative counts, and average detection latency.

The final evaluation was conducted on a balanced test set containing 500 SQL and 500 NoSQL queries.

Experiments were run on an Intel i5-13420H CPU (Intel Corporation, Santa Clara, CA, USA) with 16 GB DDR5 RAM (Micro-Star International Co., Ltd. (MSI), New Taipei City, Taiwan) and an NVIDIA GeForce RTX 4050 Laptop GPU with 6 GB of VRAM (NVIDIA Corporation, Santa Clara, CA, USA). The experimental database environment included MongoDB v8.0.16 for processing and testing NoSQL queries and PostgreSQL v17.9 for the SQL environment. Database administration and inspection were performed using pgAdmin 4 v9.11. Llama3 (8B) was deployed locally using the Ollama framework v0.30.8. All code was implemented in Python v3.9.13, and the ML models were implemented using scikit-learn v1.3.2. All random seeds were fixed at 42 for reproducibility. Figure 3 illustrates the average detection latency differences between the standalone ML model, standalone LLM, and the proposed hybrid architecture.

Figure 3. Average detection latency comparison between ML, LLM and hybrid approaches.

6. Results

6.1. Detection Performance

To provide a comprehensive assessment of detection effectiveness, evaluation metrics are calculated separately for SQL, NoSQL and the overall evaluation dataset (Table 1).

Table 1. Detection performance on SQL queries.

Model	Precision	Recall	F1
ML	0.995708	0.928	0.960663
LLM	0.824000	0.824	0.824000
Hybrid	0.995902	0.972	0.983806

The data presented in the following section shows that the hybrid solution provides a large improvement in recall for the SQL injecting activity over a standard ML classifier. The ML model already shows very good precision overall but was missing many potentially vulnerable queries. The hybrid architecture both decreases the number of missed detections while maintaining a low false-positive rate (Table 2).

Table 2. Error distribution of SQL queries.

Model	False Negatives	False Positives	Model
ML	18	1	ML
LLM	44	44	LLM
Hybrid	7	1	Hybrid

As can be seen in the next section, the standalone LLM classifier exhibits a relatively larger number of classification errors than the hybrid and machine learning classifiers, with both false negative and false positive errors occurring. However, the hybrid model also greatly reduces the number of missed SQL injection attacks and maintains the same low false-positive rate as the ML classifier (Table 3).

Table 3. Detection performance on NoSQL queries.

Model	Precision	Recall	F1
ML	1.0	1.000	1.000000
LLM	1.0	0.264	0.417722
Hybrid	1.0	1.000	1.000000

Finally, it should also be noted that the statistical testing methods employed produce a very high level of accuracy for the structured dataset used in this study, and both the hybrid and ML testing approaches were able to establish a high level of verification for all of the classified NoSQL queries, while the standalone LLM was unable to achieve the same return on investment as the hybrid and ML methods due to conservative semantic decision patterns (Table 4).

Table 4. Error distribution on NoSQL queries.

Model	False Negatives	False Positives	Model
ML	0	0	ML
LLM	184	0	LLM
Hybrid	0	0	Hybrid

Confirming that the hybrid architecture in Table 4 is functioning correctly, there were no missed detections when using NoSQL. However, the standalone LLM was unable to detect numerous vulnerable queries, illustrating how ineffective semantic analysis can be as a stand-alone approach to filtering when statistical filtering is not used (Table 5).

Table 5. Overall detection performance.

Model	Precision	Recall	F1-Score
ML	0.997930	0.964	0.980671
LLM	0.860759	0.544	0.666667
Hybrid	0.997976	0.986	0.991952

Overall precision, recall and F1-score offer generally limited descriptions of model data and do not allow for much comparison of modeling performance based on how well each performs according to these metrics. For this reason, differences between modeling methods based upon their performance with respect to individual metrics can only be determined through examination of aggregate performance metrics (Table 6).

Table 6. Overall error comparison.

Model	False Negatives	False Positives	Model
ML	18	1	ML
LLM	228	44	LLM
Hybrid	7	1	Hybrid

Overall data indicates that the hybrid model produced the highest level of detection quality among the various models. Although the ML classifier had previously demonstrated high levels of accuracy, recall improved even more with the addition of the hybrid architecture, and there were fewer occurrences of false negative data. With respect to data regarding missed vulnerable queries, the hybrid model reduced from 18 (ML only) to seven for missed detections while maintaining one false positive; meanwhile, the LLM only produced an extremely low level of recall and subsequently produced a significant number of false positive results (228), thereby confirming that it exhibits conservative classification behavior.

6.2. Recall on Vulnerable Queries

In the current experiment, recall differences were mainly driven by the LLM component, while the ML-based stages maintained 99.8% detection coverage. Figure 4 presents recall values for vulnerable queries across the evaluated detection approaches.

Figure 4. Recall comparison for vulnerable query detection across ML, LLM, and hybrid approaches.

Having a high recall value is not enough if it is achieved by producing a high number of incorrect classifications. To evaluate whether or not the system can be successfully deployed in production, we also look at how many of the different errors occurred between two or more classifiers.

6.3. Error Analysis

Figure 5 compares the distribution of false positives and false negatives across the evaluated models.

Figure 5. Comparison of detection errors (FP and FN) across approaches.

Qualitative analysis of model classification errors is needed to discover any recurring anomalies in the models’ underlying detection logics; and by looking at examples of models that have been misclassified, it is possible to create a better understanding of and identify areas where the models fail and have limitations (Table 7).

Table 7. Examples of false negatives and positive.

Query Example	ML Prediction	LLM Prediction	True Label
SELECT * FROM users WHERE id = ‘’ OR ‘1’ = ‘1’	SAFE	VULNERABLE	VULNERABLE
db.users.find({age: {$ne: null}})	VULNERABLE	SAFE	SAFE

7. Discussion

7.1. Interpretation of Results

Experimental results indicated that the hybrid machine learning (ML)—large language model (LLM) system strikes the most optimal combination of the twin objectives of detection accuracy and operational efficiency. The hybrid machine learning (ML)—large language model (LLM) system produced an F1 Score of 0.992 with a Recall of 0.986, outperforming stand-alone models of both the machine learning (ML) (F1 Score of 0.981) and large language models (LLM) (F1 Score of 0.667). Importantly, eliminating false negatives is critical if the model operates in the real world because of how much damage missed injection attacks can cause. These results are consistent with previous ML-based vulnerability detection research; the classification of vulnerabilities has been shown to be good but has been restricted for deployment in natural settings [5,6,7]. Our hybrid approach exhibits clear advantages over stand-alone strategies. While Maligazhdarova et al. [2] used Random Forest to achieve 99% accuracy for SQL injection and fine-tuned LLMs achieve 97% accuracy for NoSQL injection, our hybrid approach is comparable in accuracy while reducing computational costs by limiting LLM invocations to ambiguous cases only. This addresses the computational expense issues discussed in previous studies [8,12]. The near-zero false positive rates reached through the proposed system are of special interest for operational deployment. In previous studies, Gupta and Tyagi [5] reported that high false positive rates in production environments may increase analyst workload and alert fatigue. Our findings show that hybrid architecture can address this problem and maintain high recall.

7.2. Error Patterns and Failure Modes

Error analysis results in two major types of failure: obfuscated payloads that evade syntactic filters (encoding, string split, comment-based evasion, etc.), and context-dependent queries where the malignancy of the query code is determined by the application logic. This is in line with the findings made by Xie et al. [3] and Arasteh et al. [6] regarding the limitations of syntactic analysis when performing complex injections. Refer to Table 7 for selected examples of both cases, which serve to provide further impetus for developing normalizing techniques and contextual aware features, as shown in previous studies of adversarial machine learning and resilient security systems [11].

7.3. Limitations and Threats to Validity

The NoSQL dataset applied in this study is relatively small (1000 queries) and it was created manually using scripts and language model generators to mimic injections in the real world. This limitation might restrict the variety of attack patterns and thus may overstate performance results. Similar dataset challenges were identified by Maligazhdarova et al. [2] and Rameshwar et al. [8], who also highlighted the importance of bigger and more diverse NoSQL injection datasets. In the future, the dataset could be expanded to include real traffic data, honeypot log files, or anonymized production data from partner organizations. The thresholds for triggering the LLM verifier were chosen manually based on validation performance. As Ul Islam et al. [9] noted, manually selected thresholds may not generalize effectively across different operational environments. In practice, thresholds need to be established based on data and recalibrated periodically. The proposed system currently treats queries as independent events and does not incorporate contextual information such as application logic, user roles, session context, or database schema structure [14]. Research on database security has also emphasized the need for contextual information. Using schema information and application context is also an important step towards further improvement in this direction. Differences in phrasing by LLM, generation settings, and version of the model can result in inconsistent classifications for identical input values. He and Vechev [7] and Gao et al. [10] also found comparable issues in LLM-based security analysis. Some solutions are prompt refinement, ensemble classification, and domain-specific fine-tuning. The method provides a weak defense against advanced obfuscation techniques such as encoding, string splitting, and comment-based evasion. Future improvements may incorporate normalization pipelines and adversarial training techniques for obfuscated payloads, consistent with cybersecurity robustness recommendations discussed by Dasgupta et al. [11]. Although this hybrid model can make fewer LLM invocations, it may still contribute to higher latency and scaling problems due to the high variability in production-level requests. Production deployment environments may require batching, asynchronous processing, and rate-limiting strategies to mitigate latency and scalability limitations [6].

7.4. Reproducibility and Implementation Notes

We fixed random seeds, documented preprocessing steps (lowercasing, literal masking, anonymization), and preserved LLM prompts and invocation parameters to facilitate reproducibility, following best practices established by Lemaître et al. [12].

7.5. Practical Deployment Considerations

ML stages run in milliseconds; LLM calls are significantly slower. Only ambiguous queries should be escalated to avoid latency spikes, as recommended by production deployment studies. One should maintain counters for FP/FN and implement human-in-the-loop feedback paths to retrain and adjust thresholds, following continuous improvement practices suggested by [13]. One should also treat human analyst confirmation as final in high-risk flows; do not rely exclusively on automated classification, as emphasized by security best practices.

8. Conclusions

Numerous prior studies have investigated hybrid systems for detecting SQL and NoSQL injection attacks. The present work proposes a feasible hybrid detection architecture that combines lightweight statistical machine learning techniques with semantic verification by a large language model locally hosted to perform semantic verification. The system consists of a fast TF-IDF-based logistic regression classifier used in the first stage for filtering purposes. After that, any semantically ambiguous queries that remain after filtering are examined with the LLM verification component deterministically. The design developed combines both statistical and semantic methods into one mechanism that will allow for a highly effective and efficient method of detecting database attacks with minimal amounts of time spent doing excessive unnecessary semantic analysis on the detected data. The evaluation of a balanced test dataset (1000 total examples; 500 SQL queries and 500 NoSQL queries) showed that this hybrid detection model produced significantly better results when compared with a standalone machine learning model, achieving excellent performance information (precision: 0.998; recall: 0.986; and F1 Score: 0.992). The hybrid model had an enormous reduction in the number of false negative detections, producing only seven false negative detections compared with 18 from the standalone model and very few false positive detections. In comparison, the standalone LLM-only (purely semantic detection model) produced an exceptionally low recall rate of only 0.544 and produced many missed detections of SQL injections, demonstrating very significant weaknesses in using only semantic techniques to detect database attacks via purely semantic analysis, without the assistance of any statistical techniques. These findings indicate that hybrid architectures combining LLMs and ML algorithms (i.e., hybrid ML-LLM detection architectures) may provide a scalable architectural and secure database monitoring solution through the combination of high-speed statistical pattern analysis with targeted semantic analysis techniques combined with statistical filtering to provide reliable detection, while maintaining sufficient operational efficiency for use in production systems. Future studies will be done to extend the research to develop NoSQL datasets, increase the robustness against obfuscation detection methods, and increase the context and features at the application layer to increase the accuracy of detection.