VYPR
← All advisories
Moderate severityNVD Advisory· Published Jul 25, 2023· Updated Feb 13, 2025

Apache InLong: General user can delete and update process

CVE-2023-34189

Description

Exposure of Resource to Wrong Sphere Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.7.0. The attacker could use general users to delete and update the process, which only the admin can operate occurrences.

Users are advised to upgrade to Apache InLong's 1.8.0 or cherry-pick https://github.com/apache/inlong/pull/8109  to solve it.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Apache InLong's workflow approver API allowed general users to delete/update processes that should be admin-only (v1.4.0-1.7.0).

Vulnerability

Overview CVE-2023-34189 is an Exposure of Resource to Wrong Sphere vulnerability in Apache InLong, a data integration framework. Affected versions from 1.4.0 through 1.7.0 contain a flaw where the WorkflowApprover API does not enforce proper permissions, allowing general users to delete and update processes that only administrators should be able to operate [1][2].

Exploitation

An attacker with access as a general user can exploit this by sending crafted API requests to the WorkflowApprover endpoints, bypassing the intended role-based access control. The vulnerability exists in the manager module, and exploitation requires an authenticated account with minimal privileges (i.e., a non-admin user) [1][4]. No additional network position or special conditions are needed beyond being able to reach the InLong Manager API [3].

Impact

Successful exploitation allows the attacker to arbitrarily delete or update workflow approval processes. This can disrupt administrative workflows, alter approval chains, or remove critical process configurations, leading to unauthorized data handling or service disruptions within the InLong environment [2][4].

Mitigation

The Apache InLong project has fixed this issue in version 1.8.0. Users are advised to upgrade to the latest release or cherry-pick the relevant commit from Pull Request #8109 [1][2][4]. No workarounds are publicly documented; upgrading is the recommended remediation.

References
  1. [INLONG-8108][Manager] WorkflowApprover API Permissions Optimization by hnrainll · Pull Request #8109 · apache/inlong
  2. NVD - CVE-2023-34189
  3. GitHub - apache/inlong: Apache InLong - a one-stop, full-scenario integration framework for massive data
  4. security - CVE-2023-34189: Apache InLong: General user can delete and update process

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.

PackageAffected versionsPatched versions
org.apache.inlong:inlong-managerMaven
>= 1.4.0, < 1.8.01.8.0

Affected products

3

Patches

1
a39e03cc5d1b

[INLONG-8108][Manager] WorkflowApprover API Permissions Optimization (#8109)

https://github.com/apache/inlongHaoMay 30, 2023via ghsa-ref
commitPR #8109
4 files changed · +18 −4
  • inlong-manager/manager-service/src/main/java/org/apache/inlong/manager/service/core/impl/WorkflowApproverServiceImpl.java+9 −1 modified
    @@ -29,6 +29,7 @@
 import org.apache.inlong.manager.pojo.workflow.ApproverRequest;
 import org.apache.inlong.manager.pojo.workflow.ApproverResponse;
 import org.apache.inlong.manager.service.core.WorkflowApproverService;
+import org.apache.inlong.manager.service.user.UserService;
 import org.apache.inlong.manager.workflow.core.ProcessDefinitionService;
 import org.apache.inlong.manager.workflow.definition.UserTask;
 import org.apache.inlong.manager.workflow.definition.WorkflowProcess;
@@ -60,6 +61,8 @@ public class WorkflowApproverServiceImpl implements WorkflowApproverService {
     private WorkflowApproverEntityMapper approverMapper;
     @Autowired
     private ProcessDefinitionService processDefinitionService;
+    @Autowired
+    private UserService userService;
 
     @Override
     public Integer save(ApproverRequest request, String operator) {
@@ -87,13 +90,18 @@ public Integer save(ApproverRequest request, String operator) {
     }
 
     @Override
-    public ApproverResponse get(Integer id) {
+    public ApproverResponse get(Integer id, String operator) {
         Preconditions.expectNotNull(id, "approver id cannot be null");
+
         WorkflowApproverEntity approverEntity = approverMapper.selectById(id);
         if (approverEntity == null) {
             LOGGER.error("workflow approver not found by id={}", id);
             throw new BusinessException(ErrorCodeEnum.WORKFLOW_APPROVER_NOT_FOUND);
         }
+
+        userService.checkUser(approverEntity.getApprovers(), operator,
+                "Current user does not have permission to get this workflow approver info");
+
         return CommonBeanUtils.copyProperties(approverEntity, ApproverResponse::new);
     }
  • inlong-manager/manager-service/src/main/java/org/apache/inlong/manager/service/core/WorkflowApproverService.java+2 −1 modified
    @@ -41,9 +41,10 @@ public interface WorkflowApproverService {
      * Get workflow approver by ID
      *
      * @param id approver id
+     * @param operator operator name
      * @return approver info
      */
-    ApproverResponse get(Integer id);
+    ApproverResponse get(Integer id, String operator);
 
     /**
      * Get process approver by the process name and task name.
  • inlong-manager/manager-service/src/test/java/org/apache/inlong/manager/service/workflow/WorkflowApproverServiceImplTest.java+1 −1 modified
    @@ -43,7 +43,7 @@ public void testListAndGet() {
         Assertions.assertTrue(approverList.getList().size() > 0);
 
         Integer id = approverList.getList().get(0).getId();
-        ApproverResponse approverResponse = workflowApproverService.get(id);
+        ApproverResponse approverResponse = workflowApproverService.get(id, "admin");
         Assertions.assertEquals(id, approverResponse.getId());
     }
  • inlong-manager/manager-web/src/main/java/org/apache/inlong/manager/web/controller/WorkflowApproverController.java+6 −1 modified
    @@ -21,6 +21,7 @@
 import org.apache.inlong.manager.common.enums.UserTypeEnum;
 import org.apache.inlong.manager.pojo.common.PageResult;
 import org.apache.inlong.manager.pojo.common.Response;
+import org.apache.inlong.manager.pojo.user.UserRoleCode;
 import org.apache.inlong.manager.pojo.workflow.ApproverPageRequest;
 import org.apache.inlong.manager.pojo.workflow.ApproverRequest;
 import org.apache.inlong.manager.pojo.workflow.ApproverResponse;
@@ -31,6 +32,7 @@
 import io.swagger.annotations.Api;
 import io.swagger.annotations.ApiImplicitParam;
 import io.swagger.annotations.ApiOperation;
+import org.apache.shiro.authz.annotation.RequiresRoles;
 import org.springframework.beans.factory.annotation.Autowired;
 import org.springframework.web.bind.annotation.DeleteMapping;
 import org.springframework.web.bind.annotation.GetMapping;
@@ -54,6 +56,7 @@ public class WorkflowApproverController {
     @PostMapping("/workflow/approver/save")
     @OperationLog(operation = OperationType.CREATE)
     @ApiOperation(value = "Save approver info")
+    @RequiresRoles(value = UserRoleCode.ADMIN)
     public Response<Integer> save(@RequestBody ApproverRequest config) {
         return Response.success(workflowApproverService.save(config, LoginUserUtils.getLoginUser().getName()));
     }
@@ -62,7 +65,7 @@ public Response<Integer> save(@RequestBody ApproverRequest config) {
     @ApiOperation(value = "Get approver by ID")
     @ApiImplicitParam(name = "id", value = "Workflow approver ID", dataTypeClass = Integer.class, required = true)
     public Response<ApproverResponse> get(@PathVariable Integer id) {
-        return Response.success(workflowApproverService.get(id));
+        return Response.success(workflowApproverService.get(id, LoginUserUtils.getLoginUser().getName()));
     }
 
     @GetMapping("/workflow/approver/list")
@@ -76,6 +79,7 @@ public Response<PageResult<ApproverResponse>> listByCondition(ApproverPageReques
     @PostMapping("/workflow/approver/update")
     @OperationLog(operation = OperationType.UPDATE)
     @ApiOperation(value = "Update approver info")
+    @RequiresRoles(value = UserRoleCode.ADMIN)
     public Response<Integer> update(@RequestBody ApproverRequest request) {
         return Response.success(workflowApproverService.update(request, LoginUserUtils.getLoginUser().getName()));
     }
@@ -84,6 +88,7 @@ public Response<Integer> update(@RequestBody ApproverRequest request) {
     @OperationLog(operation = OperationType.DELETE)
     @ApiOperation(value = "Delete approver by ID")
     @ApiImplicitParam(name = "id", value = "Workflow approver ID", dataTypeClass = Integer.class, required = true)
+    @RequiresRoles(value = UserRoleCode.ADMIN)
     public Response<Boolean> delete(@PathVariable Integer id) {
         workflowApproverService.delete(id, LoginUserUtils.getLoginUser().getName());
         return Response.success(true);

Vulnerability mechanics

Root cause

"Missing role-based access control on workflow approver API endpoints allows non-admin users to perform admin-only operations."

Attack vector

An attacker with a low-privilege (non-admin) account can send HTTP requests to the `/workflow/approver/save`, `/workflow/approver/update`, or `/workflow/approver/delete` endpoints. Because these endpoints lacked role-based access control [patch_id=1640742], the attacker can create, modify, or delete workflow approver configurations that should only be managed by administrators. The attacker can also call the `get` endpoint to read approver details without being listed as an approver, leaking sensitive workflow approval information.

Affected code

The vulnerability resides in the `WorkflowApproverController` and `WorkflowApproverServiceImpl` classes. The `save`, `update`, and `delete` endpoints in `WorkflowApproverController.java` lacked the `@RequiresRoles(value = UserRoleCode.ADMIN)` annotation, allowing any authenticated user to call them. Additionally, the `get` method in `WorkflowApproverServiceImpl.java` did not verify that the requesting user was among the approvers listed for a workflow, exposing approver details to unauthorized users.

What the fix does

The patch adds `@RequiresRoles(value = UserRoleCode.ADMIN)` annotations to the `save`, `update`, and `delete` methods in `WorkflowApproverController.java`, ensuring only admin users can modify approver data. It also modifies the `get` method to accept the operator name and calls `userService.checkUser()` to verify that the requesting user is among the approvers listed for that workflow entry [patch_id=1640742]. These changes enforce proper authorization on all CRUD operations for workflow approvers.

Preconditions

  • authAttacker must have a valid non-admin user account on the Apache InLong system.
  • configThe affected version must be Apache InLong 1.4.0 through 1.7.0.
  • networkAttacker must be able to reach the WorkflowApprover API endpoints over the network.

Generated on May 23, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.