CVE-2026-63040 in InLong
Summary
by MITRE • 08/20/2026
Files or Directories Accessible to External Parties vulnerability in Apache InLong. StreamSource performs no authorization check, any authenticated user can logically delete ALL stream sources.
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/pull/12145 .
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Apache InLong, specifically within the StreamSource component, represents a critical failure in access control mechanisms that allows authenticated users to perform unauthorized administrative actions. This flaw is classified under CWE-862, which denotes Missing Authorization, and aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it exploits legitimate credentials to escalate privileges or execute destructive operations without proper verification of user permissions. The core technical issue stems from the absence of an authorization check in the StreamSource module during logical deletion requests. In a properly secured system, any operation that modifies global state or affects other users' resources must verify not only that the requester is authenticated but also that they possess the specific role-based access control rights required for such actions. However, in versions from 2.0.0 up to but excluding 2.4.0, the endpoint responsible for deleting stream sources fails to validate whether the initiating user has ownership of or administrative authority over the targeted resource. This oversight creates a logical vulnerability where any valid session token can be used to trigger deletion operations on resources that do not belong to the requester.
The operational impact of this vulnerability is severe due to its potential for widespread data loss and service disruption within multi-tenant environments. Since stream sources are fundamental components in Apache InLong's architecture, responsible for ingesting data from various external systems into the pipeline, their unauthorized deletion can break downstream processing workflows immediately. An attacker with low-level access could systematically delete all configured stream sources, effectively halting data ingestion across the entire cluster or affecting specific tenants if multi-tenancy isolation is not strictly enforced at other layers of the application stack. This capability allows for a denial-of-service condition that is difficult to mitigate through standard monitoring alone because the actions appear as legitimate user activity from an authenticated account. Furthermore, in environments where stream sources are shared across multiple projects or teams, this flaw compromises data integrity and availability by allowing one user to inadvertently or maliciously remove configurations intended for others, leading to significant operational overhead in recovery efforts and potential loss of historical data if backups are not immediately available.
To mitigate this risk, organizations running affected versions must prioritize upgrading Apache InLong to version 2.4.0 or later, where the authorization logic has been corrected to enforce strict access controls on StreamSource deletion endpoints. For environments that cannot undergo an immediate full upgrade due to compatibility constraints or deployment cycles, applying the specific patch referenced in pull request 12145 is necessary to restore security boundaries. Additionally, while technical fixes are being implemented, administrators should review their existing user roles and permissions to ensure that only trusted personnel have access to management interfaces capable of modifying stream configurations. Implementing additional network-level controls or API gateways that enforce secondary validation policies can provide a defense-in-depth layer until the software update is fully deployed. Regular auditing of deletion logs and monitoring for unusual patterns in resource modification requests are also recommended practices to detect potential exploitation attempts early, although these measures serve as compensatory controls rather than replacements for fixing the underlying code defect.