Apache InLong: Insecurity direct object references cancelling applications
Description
Files or Directories Accessible to External Parties vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.2.0 through 1.6.0. the user in InLong could cancel an application that doesn't belongs to it. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7799 https://github.com/apache/inlong/pull/7799 to solve it.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Apache InLong 1.2.0 to 1.6.0 allows users to cancel applications not belonging to them due to missing access control.
CVE-2023-31064 describes an access control vulnerability in Apache InLong versions 1.2.0 through 1.6.0. The flaw allows a user to cancel an application that does not belong to them, violating intended access restrictions. The root cause is insufficient authentication when performing workflow operations, specifically for cancellation requests. This is classified as a "Files or Directories Accessible to External Parties" vulnerability, indicating that unauthorized parties can interact with resources they should not have access to.
The attack can be executed by any authenticated user within InLong. No special privileges are required beyond a valid account. By crafting a request to cancel an application, an attacker can target applications owned by other users. The vulnerability is present in the Manager module, where workflow operations lack proper user identity verification. As documented in the fix pull request [1], the solution adds user authentication checks to ensure that only the owner of an application can initiate a cancellation.
Successful exploitation allows an attacker to disrupt or terminate data processing workflows belonging to other users. This could lead to denial of service, data loss, or interference with critical data pipelines. The impact is limited to workflow cancellation; however, it could be leveraged to cause operational chaos in environments relying on InLong for data integration.
Apache has addressed the issue in InLong version 1.7.0 [2]. Users are advised to upgrade to this version or apply the cherry-pick commit from the referenced pull request [1]. No workarounds have been provided, making patching the recommended course of action.
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
org.apache.inlong:manager-workflowMaven | >= 1.2.0, < 1.7.0 | 1.7.0 |
Affected products
2- Range: 1.2.0
Patches
1e05199f4c3eb[INLONG-7798][Manager] Add user authentication when operate workflow (#7799)
1 file changed · +24 −0
inlong-manager/manager-workflow/src/main/java/org/apache/inlong/manager/workflow/core/impl/ProcessServiceImpl.java+24 −0 modified@@ -19,12 +19,18 @@ import com.google.common.collect.Lists; import lombok.extern.slf4j.Slf4j; +import org.apache.inlong.manager.common.consts.InlongConstants; import org.apache.inlong.manager.common.enums.ErrorCodeEnum; import org.apache.inlong.manager.common.enums.ProcessStatus; import org.apache.inlong.manager.common.enums.TaskStatus; +import org.apache.inlong.manager.common.enums.UserTypeEnum; import org.apache.inlong.manager.common.util.Preconditions; +import org.apache.inlong.manager.dao.entity.InlongGroupEntity; +import org.apache.inlong.manager.dao.entity.UserEntity; import org.apache.inlong.manager.dao.entity.WorkflowProcessEntity; import org.apache.inlong.manager.dao.entity.WorkflowTaskEntity; +import org.apache.inlong.manager.dao.mapper.InlongGroupEntityMapper; +import org.apache.inlong.manager.dao.mapper.UserEntityMapper; import org.apache.inlong.manager.dao.mapper.WorkflowTaskEntityMapper; import org.apache.inlong.manager.pojo.workflow.form.process.ProcessForm; import org.apache.inlong.manager.workflow.WorkflowAction; @@ -51,6 +57,10 @@ public class ProcessServiceImpl implements ProcessService { private WorkflowTaskEntityMapper taskEntityMapper; @Autowired private WorkflowContextBuilder workflowContextBuilder; + @Autowired + private InlongGroupEntityMapper groupMapper; + @Autowired + private UserEntityMapper userMapper; @Override public WorkflowContext start(String name, String applicant, ProcessForm form) { @@ -60,6 +70,7 @@ public WorkflowContext start(String name, String applicant, ProcessForm form) { // build context WorkflowContext context = workflowContextBuilder.buildContextForProcess(name, applicant, form); + checkUser(context, applicant, "Current user does not have permission to start workflow"); this.processorExecutor.executeStart(context.getProcess().getStartEvent(), context); return context; } @@ -69,6 +80,7 @@ public WorkflowContext continueProcess(Integer processId, String operator, Strin Preconditions.expectNotBlank(operator, ErrorCodeEnum.INVALID_PARAMETER, "operator cannot be null"); Preconditions.expectNotNull(processId, "processId cannot be null"); WorkflowContext context = workflowContextBuilder.buildContextForProcess(processId); + checkUser(context, operator, "Current user does not have permission to operate workflow"); WorkflowProcessEntity processEntity = context.getProcessEntity(); ProcessStatus processStatus = ProcessStatus.valueOf(processEntity.getStatus()); Preconditions.expectTrue(processStatus == ProcessStatus.PROCESSING, @@ -96,6 +108,7 @@ public WorkflowContext cancel(Integer processId, String operator, String remark) Preconditions.expectNotNull(processId, "processId cannot be null"); WorkflowContext context = workflowContextBuilder.buildContextForProcess(processId); + checkUser(context, operator, "Current user does not have permission to cancel workflow"); List<WorkflowTaskEntity> pendingTasks = taskEntityMapper.selectByProcess(processId, TaskStatus.PENDING); for (WorkflowTaskEntity taskEntity : pendingTasks) { WorkflowTask task = context.getProcess().getTaskByName(taskEntity.getName()); @@ -111,4 +124,15 @@ public WorkflowContext cancel(Integer processId, String operator, String remark) return context; } + public void checkUser(WorkflowContext context, String user, String errMsg) { + String groupId = context.getProcessForm().getInlongGroupId(); + Preconditions.expectNotBlank(groupId, ErrorCodeEnum.GROUP_ID_IS_EMPTY, + ErrorCodeEnum.GROUP_ID_IS_EMPTY.getMessage()); + InlongGroupEntity groupEntity = groupMapper.selectByGroupId(groupId); + UserEntity userEntity = userMapper.selectByName(user); + boolean isInCharge = Preconditions.inSeparatedString(user, groupEntity.getInCharges(), InlongConstants.COMMA); + Preconditions.expectTrue(isInCharge || UserTypeEnum.ADMIN.getCode().equals(userEntity.getAccountType()), + errMsg); + } + }
Vulnerability mechanics
Root cause
"Missing authorization check in workflow operations allows a user to cancel, start, or continue a workflow that belongs to an InLong group they are not responsible for."
Attack vector
An authenticated InLong user can call the `cancel` (or `start`/`continueProcess`) workflow API with a `processId` that belongs to an InLong group they are not in charge of. Because the server did not verify that the operator is listed in the group's `inCharges` field or is an admin user, the attacker can cancel, start, or continue a workflow that does not belong to them. The only precondition is a valid authenticated session in Apache InLong versions 1.2.0 through 1.6.0.
Affected code
The vulnerability exists in `ProcessServiceImpl.java` in the `start`, `continueProcess`, and `cancel` methods. These methods previously performed no authorization check to verify that the requesting user is the owner or an admin of the InLong group associated with the workflow process.
What the fix does
The patch adds a `checkUser` method that retrieves the `InlongGroupEntity` for the workflow's group ID and the `UserEntity` for the operator. It then verifies that the operator's username appears in the group's `inCharges` list (using `Preconditions.inSeparatedString`) or that the user has an `ADMIN` account type. This check is inserted at the beginning of `start`, `continueProcess`, and `cancel`, ensuring that only authorized users can perform these workflow operations [patch_id=1640828].
Preconditions
- authAttacker must have a valid authenticated session in Apache InLong.
- inputTarget workflow process must belong to an InLong group the attacker is not in charge of.
Generated on May 23, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- github.com/advisories/GHSA-3p9p-59qf-mqwhghsaADVISORY
- lists.apache.org/thread/1osd2k3t3qol2wdsswqtr9gxdkf78n00ghsavendor-advisoryWEB
- nvd.nist.gov/vuln/detail/CVE-2023-31064ghsaADVISORY
- github.com/apache/inlong/pull/7799ghsaWEB
News mentions
0No linked articles in our index yet.