CVE-2026-86284: Tourism Management System Information Disclosure

CVE-2026-86284 Overview

CVE-2026-86284 is an information disclosure vulnerability in the jaychouchannel Tourism-Management-System, a Java-based web application. The flaw affects the getOption function within travel/src/main/java/com/controller/CommonController.java. Attackers can manipulate the tableName and columnName parameters to disclose sensitive database information remotely without authentication. The affected project uses a rolling release model, so no discrete version numbers are published for affected releases. The upstream patch is identified by commit hash d44ec3aa0bd2a72c8800e3befb0a9a96a6491b86. Public disclosure of the exploit has already occurred, increasing risk to internet-exposed deployments. This weakness maps to [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor].

Critical Impact
Unauthenticated remote attackers can query arbitrary database tables and columns through the getOption endpoint, leading to disclosure of sensitive application data.

Affected Products

jaychouchannel Tourism-Management-System (rolling release, up to commit 8122bf020d91199eddfff3ee02d1632a70a9a132)
Affected file: travel/src/main/java/com/controller/CommonController.java
Vulnerable function: getOption

Discovery Timeline

2026-09-07 - CVE-2026-86284 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-86284

Vulnerability Analysis

The getOption handler in CommonController.java accepts caller-supplied tableName and columnName arguments and uses them to construct a database query. Because these identifiers are not validated against an allowlist, an attacker can substitute arbitrary table or column names. The endpoint returns the resulting data to the caller, exposing information that the application never intended to publish. The vulnerability is reachable over the network and requires no authentication or user interaction, which broadens the pool of potential attackers.

Root Cause

The root cause is missing input validation on SQL identifiers passed from HTTP request parameters into a data-access call. The original controller relied on CommonUtil to build queries directly from client input. The upstream fix replaces this with a dedicated SqlIdentifierValidator that constrains tableName and columnName to known-safe values. Without such validation, the controller trusts untrusted input to name database objects, which is the underlying pattern behind [CWE-200] information exposure in this project.

Attack Vector

An unauthenticated attacker sends an HTTP request to the getOption endpoint and supplies chosen values for tableName and columnName. The controller executes a query against those identifiers and returns the column data in the HTTP response. The attacker iterates through table and column names to enumerate the schema and extract sensitive fields such as user records or configuration data.

java

// Patch: switch identifier handling from CommonUtil to a validator
 import com.utils.BaiduUtil;
 import com.utils.FileUtil;
 import com.utils.R;
-import com.utils.CommonUtil;
+import com.utils.SqlIdentifierValidator;
 /**
  * 通用接口
  */

Source: GitHub Commit d44ec3aa. The commit swaps unrestricted identifier handling for validated identifier lookups, blocking arbitrary table and column access.

Detection Methods for CVE-2026-86284

Indicators of Compromise

HTTP requests to the getOption endpoint containing unexpected values in tableName or columnName parameters, especially references to system, user, or credential tables.
Repeated requests iterating through many distinct tableName or columnName values from a single source, indicating schema enumeration.
Application logs showing SQL queries built with identifiers that do not correspond to normal user-facing features.

Detection Strategies

Instrument the web application or reverse proxy to log all query-string and body parameters submitted to CommonController endpoints.
Deploy a web application firewall rule that blocks or alerts on tableName and columnName parameters containing values outside a documented allowlist.
Review database audit logs for SELECT statements referencing tables that the tourism application does not normally query at runtime.

Monitoring Recommendations

Alert on unauthenticated access patterns against /getOption from external IP addresses.
Correlate spikes in 200-OK responses from the getOption endpoint with unusual outbound data volumes.
Track new or unexpected values in the tableName and columnName fields over time using log analytics.

How to Mitigate CVE-2026-86284

Immediate Actions Required

Pull the latest main branch of the Tourism-Management-System repository and confirm commit d44ec3aa0bd2a72c8800e3befb0a9a96a6491b86 is present.
Restrict network exposure of the application to trusted networks until the patch is deployed.
Audit application and database logs for prior requests to getOption that reference sensitive tables.

Patch Information

The upstream fix is delivered in commit d44ec3aa, merged via Pull Request #14. The patch replaces CommonUtil with SqlIdentifierValidator in CommonController.java, constraining tableName and columnName to validated identifiers. Additional hardening in the same pull request removes @IgnoreAuth from the password-reset endpoint. Because the project uses a rolling release model, redeploy from source after pulling the patched commit. Additional context is available in GitHub Issue #8 and VulDB CVE-2026-86284.

Workarounds

Place the application behind an authenticating reverse proxy so that anonymous callers cannot reach getOption.
Add a WAF rule that rejects requests to getOption whose tableName or columnName parameters are not in an approved allowlist.
Restrict the database account used by the application to only the specific tables and columns required by legitimate features.

bash

# Example NGINX rule to block anonymous access to the vulnerable endpoint
location /getOption {
    if ($http_authorization = "") { return 403; }
    proxy_pass http://tourism_backend;
}