SIExVulTS: CWE-200 Detection in Java

• SIExVulTS is a vulnerability detection system for CWE-200 in Java that integrates transformer-based embeddings with static analysis to trace context-aware data flows.
• Its three-stage pipeline—attack surface detection, exposure analysis, and flow verification—achieves high accuracy with F1 scores above 85% and precision improvements from 22.61% to 87.23%.
• The system maps findings to specific CWE-200 subcategories and has uncovered six previously unknown CVEs in major Apache projects.

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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025).

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\% (Katz et al., 26 Aug 2025). It also states that SentBERT performed best overall for variables and sinks; CodeT5 for free-form text (strings, comments) (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025):

$$\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) (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). More generally, the engine reports, for each detected flow, the source, sink, data path, CWE id, and code context (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025):

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\% (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). Long traces are handled with a Transformer-based aggregator of token embeddings.

Before classification, flows are hashed (SHA-256) to remove duplicates (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025).

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 (Katz et al., 26 Aug 2025). It also reports that F1-score rises to 0.90 and accuracy to 95.5\% (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025).

The system’s most prominent empirical claim is that it successfully uncovered six previously unknown CVEs in major Apache projects (Katz et al., 26 Aug 2025). 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. (Katz et al., 26 Aug 2025)

The paper further states that 12 more reports were under review (Katz et al., 26 Aug 2025). 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 (Katz et al., 26 Aug 2025). 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 (Sanjaya et al., 2024). 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 (Sanjaya et al., 2024). 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 (Shi et al., 19 Jun 2025). 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 (Shi et al., 19 Jun 2025). 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 (Sripad et al., 2017). 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 (Sripad et al., 2017). 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 (Katz et al., 26 Aug 2025).