Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed InLong management endpoint
-
DeliveryCraft SQL payload in dbName/tableName parameter
-
ExploitSubmit request injecting arbitrary SQL
-
ExecutionBackend executes injected query
-
ImpactRead or modify database contents
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires network reachability to the Apache InLong component that processes the dbName, tableName, schemaName, or username parameters - typically the InLong Manager/data-source configuration interface - running a vulnerable version between 2.0.0 and 2.3.x. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N) no authentication or user interaction is nominally required, but the practical limiting factor is exposure: the attacker must be able to send requests to that endpoint, so deployments that keep the InLong console on an internal/management-only network or behind an authenticating gateway substantially raise the bar. Whether the vulnerable endpoint is genuinely pre-authentication in a given install should be verified, as this is the key determinant of real-world reachability. |
| Impact | The signals here are genuinely mixed and worth reconciling. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H, score 9.8) describes an unauthenticated, network-reachable, low-complexity flaw with full CIA impact - the theoretical worst case. Against that, EPSS is only 0.21% (11th percentile) and there is no KEV listing and no public PoC, indicating that real-world weaponization has not materialized and mass exploitation is not currently observed. The tension is that SQL injection in an unauthenticated management parameter is exactly the class attackers eventually automate, so the low EPSS likely reflects the product's modest deployment footprint and recency of disclosure rather than any intrinsic difficulty. One caveat on the CVSS itself: whether these parameters are truly reachable pre-authentication depends on how the affected InLong endpoint is exposed and whether the Manager/console sits behind auth in a given deployment - if the vulnerable endpoint normally requires a logged-in operator, effective privilege requirements are higher than PR:N implies, so verify exposure in your own environment. Net: a real, patchable priority for anyone running InLong 2.0.0-2.3.x, but the absence of active exploitation means it can be scheduled as an expedited patch rather than an emergency out-of-band response. |
| Exploit ScenarioDerived | An attacker who can reach an exposed Apache InLong management endpoint submits a request in which the dbName or tableName parameter contains a crafted SQL payload; because the identifier is concatenated into a backend query, the injected clause executes against InLong's database. Given AV:N/AC:L and full CIA impact, the attacker can read or modify stored configuration and pipeline metadata; no public PoC is currently identified, so exploitation would require the attacker to develop the injection string themselves. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 24, 2026
SQL injection in Apache InLong versions 2.0.0 through 2.3.x allows remote attackers to inject arbitrary SQL via the dbName, tableName, schemaName, and username parameters, compromising the integrity and confidentiality of the backend database. The flaw carries a CVSS 9.8 (network, no authentication, no user interaction) and was disclosed by the Apache project itself; a vendor patch exists in 2.4.0. There is no public exploit identified at time of analysis, and EPSS estimates exploitation probability at a low 0.21% (11th percentile).
Earlier versions of this analysis (1)
SQL injection in Apache InLong versions 2.0.0 through 2.3.x exposes backend databases to arbitrary query manipulation via the dbName, tableName, schemaName, and username API parameters. Any environment running InLong in this version range and exposing its API to untrusted networks is at risk of data exfiltration, modification, or destruction across all integrated data sources. No public exploit code or active exploitation has been identified at time of analysis; Apache Software Foundation has released version 2.4.0 as the fix.
RemediationAI
Vendor-released patch: upgrade Apache InLong to 2.4.0, which is the primary and recommended fix. If an immediate upgrade to 2.4.0 is not feasible, the vendor states operators may cherry-pick the upstream fix tracked at https://github.com/apache/inlong/issues/12135 and rebuild from source. As compensating controls until patched, restrict network access to the InLong Manager/console and any endpoints that accept dbName, tableName, schemaName, or username parameters so they are reachable only from trusted management networks (trade-off: legitimate remote administrators must connect via VPN/bastion), and place a WAF or reverse proxy rule in front of those endpoints to reject SQL metacharacters in those identifier parameters (trade-off: risk of blocking legitimate object names containing unusual characters and no guarantee of catching all injection variants). Refer to the Apache advisory at https://lists.apache.org/thread/79w0cfnkhs3hctv8yn861qx3qwlc3p37 for authoritative guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache InLong is an open-source, one-stop integration framework for massive data ingestion, offering data collection, aggregation, and distribution across streaming and batch pipelines. The affected parameters (dbName, tableName, schemaName, username) suggest the vulnerability lives in InLong's data-source or metadata management layer, where user-supplied identifiers are concatenated into SQL statements that query or configure backend databases rather than being bound as parameters or validated against an allowlist. The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command), meaning object-name inputs - which are typically not amenable to standard prepared-statement placeholders - are passed unsanitized into dynamically constructed queries. Per the CPE (cpe:2.3:a:apache_software_foundation:apache_inlong), all 2.x builds from 2.0.0 up to but not including 2.4.0 embed the vulnerable code path.
Know when Apache Inlong gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SQL injection via network-reachable unauthenticated management parameters with low complexity yields full database confidentiality, integrity, and availability impact within an unchanged scope.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
3DescriptionCVE.org
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache InLong. This allows an attacker to inject arbitrary SQL code through the dbName, tableName, schemaName, and username parameters.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it.
[1] https://github.com/apache/inlong/issues/12135 .
Executive ViewAI
Apache InLong, a critical data ingestion platform, contains an unauthenticated SQL injection vulnerability in versions 2.0.0-2.3.x that allows remote attackers to directly compromise database confidentiality and integrity. Organizations using affected versions face immediate risk of unauthorized data access and manipulation without requiring attacker authentication. Vendor-released patch is available in version 2.4.0 and should be deployed immediately.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
More in Apache Inlong
View allArgument injection in Apache InLong's Agent Installer (versions 2.0.0 through 2.3.x) enables arbitrary shell command exe
Missing authorization enforcement in Apache InLong's StreamSource component allows any authenticated user - regardless o
Broken access control in Apache InLong's manager component exposes Data Node management endpoints to any authenticated u
Arbitrary file read in Apache InLong 2.0.0 through 2.3.x exposes the Agent host filesystem to unauthenticated remote att
SQL injection in Apache InLong versions 2.0.0 up to (but not including) 2.4.0 allows attackers to inject attacker-contro
Server-Side Request Forgery in Apache InLong Manager (versions 2.0.0-2.3.x) allows any authenticated user - no administr
Uncontrolled Resource Consumption (CWE-400) in Apache InLong versions 2.0.0 through 2.3.x exposes two related attack sur
Unauthorized template information disclosure in Apache InLong 2.0.0 through 2.3.x allows authenticated users who are not
EUVD-2026-63399
GHSA-8x82-h8qj-qg8w
NVD
CVE.org
EPSS
Exploit-DB