---
title: 'SIExVulTS: CWE-200 Detection in Java'
url: https://www.emergentmind.com/topics/siexvults
type: topic
---

# SIExVulTS: CWE-200 Detection in Java

SIExVulTS is a vulnerability detection system for **CWE-200 (Sensitive Information Exposure)** in Java applications that integrates transformer-based models with static analysis in a three-stage pipeline comprising **Attack Surface Detection**, **Exposure Analysis**, and **Flow Verification** [2508.19472]. Its stated aim is to identify and verify sensitive information exposure with context-aware analysis of code-level data flows, rather than relying on fixed keyword lists or undifferentiated static rules. In the evaluation reported for the system, the Attack Surface Detection Engine achieved an average F1 score greater than 93\%, the Exposure Analysis Engine achieved an F1 score of 85.71\%, and the Flow Verification Engine increased precision from 22.61\% to 87.23\% while the system also uncovered six previously unknown CVEs in major Apache projects [2508.19472].

## 1. Definition, scope, and problem model

SIExVulTS targets **Sensitive Information Exposure vulnerabilities (CWE-200)**. In the formulation used for the system, the central problem is not merely whether a program contains a sensitive token or a logging statement, but whether sensitive program elements can be traced to exposure points through meaningful source-to-sink flows. The paper presents the system as a response to the observation that existing detection tools rarely target the diverse subcategories of CWE-200 or provide context-aware analysis of code-level data flows [2508.19472].

The system is explicitly scoped to **Java applications**. Its novelty is described as the combination of **transformer-based embeddings** with **CodeQL-based static analysis**, organized as a structured three-stage architecture. The stages are: **(1) an Attack Surface Detection Engine that uses sentence embeddings to identify sensitive variables, strings, comments, and sinks; (2) an Exposure Analysis Engine that instantiates CodeQL queries aligned with the CWE-200 hierarchy; and (3) a Flow Verification Engine that leverages GraphCodeBERT to semantically validate source-to-sink flows** [2508.19472].

A key distinction in the system’s threat model is the treatment of exposure as a hierarchy of patterns rather than a single defect class. The detailed examples in the paper include **CWE-537**, **CWE-214**, **CWE-209**, and **CWE-615**, indicating that SIExVulTS is designed to map findings to specific nodes in the CWE-200 taxonomy rather than to a generic “leakage” label [2508.19472]. This suggests a design emphasis on taxonomic precision, reporting clarity, and downstream triage.

## 2. Architectural organization and analysis pipeline

SIExVulTS uses a three-stage pipeline in which each stage narrows or refines the candidate set produced by the previous stage. The first stage identifies potential sources and sinks. The second stage performs static dataflow analysis over those candidates. The third stage filters static-analysis results by semantic plausibility and exploitability [2508.19472].

| Stage | Primary method | Reported outcome |
|---|---|---|
| Attack Surface Detection Engine | Sentence embeddings and neural classification | Average F1 score greater than 93\% |
| Exposure Analysis Engine | CodeQL queries aligned with CWE-200 hierarchy | F1 score of 85.71\% |
| Flow Verification Engine | GraphCodeBERT-based semantic validation | Precision from 22.61\% to 87.23\% |

The first stage defines the candidate attack surface in terms of **variables**, **strings**, **comments**, and **sinks**. The second stage converts those detections into **custom CodeQL queries** that encode source and sink predicates for the appropriate CWE subtype. The third stage takes the resulting flows, enriches them with code context and type information, deduplicates them with **SHA-256**, serializes them, embeds them using **GraphCodeBERT**, and classifies them as real or spurious flows [2508.19472].

This architecture reflects a deliberate separation of concerns. The transformer components are used where contextual interpretation is required, while CodeQL is used where explicit program-graph traversal and hierarchical rule instantiation are required. A plausible implication is that the pipeline is intended to preserve the recall advantages of static analysis while compensating for its high false-positive rate through semantic verification.

## 3. Attack Surface Detection Engine

The **Attack Surface Detection Engine** is responsible for identifying elements that may participate in sensitive information exposure. The paper defines these elements as **sources—sensitive variables, strings, comments—and sinks—points where data can be exposed** [2508.19472]. Rather than relying on fixed keyword lists, the system uses **transformer-based sentence embeddings** to recognize sensitivity in project-specific or contextually ambiguous locations.

The candidate models evaluated for this stage are **SentBERT, CodeBERT, CodeT5, and ChatGPT-4o**, with **SentBERT** selected for primary use due to strong performance and efficient embedding size [2508.19472]. The embedding design separates **name embeddings** from **context embeddings**. The name embedding is the literal representation of the variable name, string value, or comment text. The context embedding uses a hybrid method that embeds the whole enclosing method and relevant global lines, while incorporating data type for precision [2508.19472].

The classifier takes the concatenation of name and context embeddings. For variables, strings, and comments, the task is binary classification; for sinks, it is multi-class classification. The architectural description given is a **4-layer fully-connected network with residuals, ReLU/ELU activations, L2 regularization, dropout**, trained using **hyperparameter search** over learning rate, dropout, activations, and batch size, with a **70:15:15 split**, **5-fold cross-validation**, and **SMOTE** for class imbalance [2508.19472].

The paper reports the following example F1-scores for sensitive element detection: **Variables: 93.85\%**, **Strings: 95.56\%**, **Comments: 97.77\%**, and **Sinks: 97.63\%** [2508.19472]. It also states that **SentBERT performed best overall for variables and sinks; CodeT5 for free-form text (strings, comments)** [2508.19472]. This result is consistent with the division between identifier-heavy program elements and more natural-language-like artifacts such as comments.

The classifier is summarized in the paper as follows, with $E_n$ denoting the name embedding, $E_c$ the context embedding, and $X = [E_n; E_c]$ the concatenated representation [2508.19472]:

$$
\hat{y} = \sigma(W_4 \cdot \phi(W_3 \cdot \phi(W_2 \cdot \phi(W_1 X + b_1) + b_2) + b_3) + b_4)
$$

Here, $\phi$ is the activation function, specified as **ReLU/ELU**, and $\sigma$ is **sigmoid (binary) or softmax (multi-class)** [2508.19472].

## 4. Exposure Analysis Engine and CWE-aligned flow construction

The **Exposure Analysis Engine** traces flows from detected sources to sinks using **CodeQL**. Its defining feature is that its queries are **aligned with the CWE-200 hierarchy**, so each query targets a specific subcategory rather than an undifferentiated notion of leakage [2508.19472]. The engine auto-instantiates **custom queries** based on detected sources and sinks.

The paper gives an explicit example for **CWE-537 (Sensitive Information in Runtime Error Message)**: sources are sensitive variables, and sinks are error handlers, print calls, or logging calls [2508.19472]. More generally, the engine reports, for each detected flow, the **source**, **sink**, **data path**, **CWE id**, and **code context** [2508.19472]. This reporting structure is significant because it ties each finding both to a concrete path and to a recognized weakness taxonomy.

The following excerpted query shape illustrates the engine’s use of CodeQL predicates for source and sink declaration [2508.19472]:

```codeql
predicate isSource(DataFlow::Node source) {
  exists(SensitiveVariableExpr sve |
    source.asExpr() = sve)
}

predicate isSink(DataFlow::Node sink) {
  exists(MethodCall mc, CatchClause cc |
    cc.getACaughtType().getASupertype*().hasQualifiedName("java.lang", "RuntimeException") and
    ...
    sink.asExpr() = mc.getAnArgument())
}

from Flow::PathNode source, Flow::PathNode sink
where Flow::flowPath(source, sink)
select sink.getNode(), source, sink, "Java runtime error message containing sensitive information"
```

On the synthetic benchmark, the Exposure Analysis Engine achieved an **F1-score of 85.71\%** [2508.19472]. The paper characterizes it as robust to a wide set of CWE-200 patterns. A plausible implication is that the principal challenge at this stage is not source or sink recognition in isolation, but the precision of flow instantiation across diverse exposure patterns.

## 5. Flow Verification Engine and false-positive reduction

The **Flow Verification Engine** is the stage that most directly addresses the false-positive problem of static analysis. According to the paper, it validates the **semantic plausibility and exploitability** of each static flow by enriching CodeQL-generated dataflows with **code context**, **data types**, and **semantic roles**, then embedding the serialized flow using **GraphCodeBERT** [2508.19472]. Long traces are handled with a **Transformer-based aggregator of token embeddings**.

Before classification, flows are **hashed (SHA-256) to remove duplicates** [2508.19472]. The classifier used here is described as a **residual neural classifier** similar to the one used in attack surface detection. The engine then distinguishes **real (exploitable)** from **spurious** flows [2508.19472].

The reported effect is substantial. The paper states that **precision improved from 22.61\% (CodeQL alone) to 87.23\% with semantic filtering**, while **recall** remains high, dropping slightly from **1.00 to 0.94** [2508.19472]. It also reports that **F1-score rises to 0.90** and **accuracy to 95.5\%** [2508.19472]. These numbers place the verification stage at the center of the system’s practical value, because static analysis alone is reported to produce many candidate flows that are not semantically meaningful exposures.

This stage also reflects the system’s broader methodological stance: semantic code representations are used not as a replacement for static analysis, but as a validation layer applied to static-analysis outputs. That division is central to SIExVulTS’s design.

## 6. Evaluation datasets, empirical findings, and disclosed vulnerabilities

The evaluation uses three curated datasets. The **CVE Dataset** contains **40 real-world CVEs (with patches) from NVD and GitHub**. The **Benchmark Dataset** contains **300 synthetic Java examples**, mapped to individual CWE-200 subtypes as `GOOD` or `BAD`. The **Flow Verification Dataset** contains **2,555 labeled dataflows** with manual yes/no annotation from **31 real open-source Java projects** [2508.19472]. The paper also notes augmented strings and comments to address natural class imbalance.

The experimental setup uses **stratified splits**, **cross-validation**, and **manual review**, with evaluation metrics including **Precision, Recall, F1, Accuracy,** and **Cohen’s Kappa** [2508.19472]. For a known-vulnerability case study, the paper reports that SIExVulTS detected **9 out of 15 known CWE-200 related vulnerabilities in Jenkins**, while the remaining cases were missed due to unforeseen or out-of-scope sinks [2508.19472].

The system’s most prominent empirical claim is that it **successfully uncovered six previously unknown CVEs in major Apache projects** [2508.19472]. The examples listed in the paper include:

- **CVE-2025-26795**: Apache IoTDB JDBC driver logs plaintext DB credentials.
- **CVE-2025-26864**: Apache IoTDB OpenID logs user passwords on failure.
- **CVE-2025-30677**: Apache Pulsar connectors log SSL truststore passwords.
- **CVE-2025-53651**: Jenkins HTML Publisher logs absolute file paths.
- **CVE-2025-48955**: Para logs AWS/Facebook OAuth keys/tokens. [2508.19472]

The paper further states that **12 more reports** were **under review** [2508.19472]. This suggests that the system was evaluated not only as a benchmark classifier but also as a vulnerability discovery workflow with disclosure relevance.

The comparison with prior work is also explicit. The paper states that **most static analyzers (e.g., SonarQube) and vulnerability detectors (e.g., DeepWukong, VulDeePecker for C/C++, LineVul) do not target CWE-200** in Java or in diverse detail [2508.19472]. It also states that prior work uses fixed keywords or API lists and rarely handles context, custom sensitive data, or nuanced flows. Within that framing, SIExVulTS is positioned as a system for **context awareness**, **hierarchical/CWE-aligned analysis**, and **flow semantics** rather than as a generic detector for arbitrary software weaknesses.

## 7. Relation to adjacent leakage and cyber-physical vulnerability research

SIExVulTS addresses **code-level sensitive information exposure in Java applications**, but the broader research landscape represented in related work includes leakage and exploitation mechanisms at other system layers. One adjacent line of work introduces **Physical Layer Supply Voltage Coupling (PSVC)** as a side-channel vulnerability that leaks data-dependent power variations from off-the-shelf devices **without any device modification or direct physical access** [2403.08132]. PSVC supports key-recovery attacks through power rail probing, leakage propagation across voltage domains, and wireless leakage capture through carrier modulation, with the reported mitigation that devices should operate at the **lowest safe input voltage permitted by manufacturer specifications** [2403.08132]. This is a distinct problem from SIExVulTS’s source-to-sink analysis, but both concern the exposure of sensitive information.

A second adjacent line concerns **physical-layer signal spoofing** in EV charging systems. Research on **SAE J1772, CCS, IEC 61851, GB/T 20234, and NACS** reports that authentication on **CC** and **CP** lines can be bypassed by injecting matching voltages, resistances, or PWM patterns, leading to **denial of service**, **vehicle-induced charger lockout**, and possible damage to chargers or the vehicle’s charge management system [2506.16400]. The reported proof-of-concept, **PORTulator**, uses an **RP2040 microcontroller**, a **programmable digital potentiometer (AD5160)**, **PWM-capable GPIO outputs**, and a **433 MHz wireless receiver**, and was evaluated on **7 charging standards used by 20 charger piles** [2506.16400]. Although this work belongs to transportation-system security rather than code-level CWE-200 detection, it highlights that “information exposure” and “signal injection” may both arise from weak assumptions at the physical or logical boundary of authentication and control.

A third adjacent line studies **EV battery-pack cyberattacks**, including **overdischarge**, **overcharge**, and auxiliary-component abuse, in a **physics-driven, multi-layer modeling framework** [1711.04822]. The paper reports that attacks on auxiliary components can drain **up to 20\% of the state-of-charge per hour**, that **overdischarge** under loads greater than **200W** can lead to failure in **under 2 hours**, and that **overcharging by 0.4 V/cell** can reduce a new pack’s lifetime to **~200 days** [1711.04822]. This research is not about information exposure in the CWE-200 sense, but it provides a useful contrast: SIExVulTS is a software-analysis system for disclosure vulnerabilities, whereas EV cyber-physical studies quantify long-term physical and financial damage.

Taken together, these adjacent results indicate that SIExVulTS belongs to a broader security landscape in which exposure can occur through program logic, supply-noise coupling, or protocol-level signal semantics. Its contribution is specifically the **detection and verification of CWE-200 vulnerabilities in Java**, using transformer-based context modeling and static analysis to recover semantically meaningful exposure paths [2508.19472].

Source: https://www.emergentmind.com/topics/siexvults