Unrestricted File Upload with Automatic Workflow Deployment

A workflow automation platform exposed a file upload endpoint that accepted any file type without content validation, magic byte inspection, or antivirus scanning — and immediately deployed the uploaded file as an active workflow upon receipt. An EICAR standard antivirus test file, submitted with an .xml extension and a forged text/xml content type, was accepted and confirmed deployed by the server. No additional attacker action was required between upload and execution.

What makes this different from a standard unrestricted upload

Most unrestricted file upload findings require a second step: the attacker uploads a file, then triggers execution separately — by navigating to the stored path, calling an include, or waiting for a scheduled job. This endpoint collapses both steps into one. The upload request is simultaneously an execution request. The server's response confirms deployment immediately, meaning the attack surface is a single authenticated POST with no further interaction required.

The upload and deployment confirmation

POST /workflow/upload HTTP/1.1
Host: app.acme-lab.test
Content-Type: multipart/form-data; boundary=----Boundary
Cookie: JSESSIONID=<valid-session>

------Boundary
Content-Disposition: form-data; name="file"; filename="test.xml"
Content-Type: text/xml

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
------Boundary--

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "message": "deployment completed"
}
# EICAR signature not detected — no antivirus scanning performed
# file deployed immediately — no separate approval or execution step

The server accepted the upload based solely on the client-supplied Content-Type header and filename extension. No inspection of the file content was performed. The EICAR test file — whose signature is detected by every production antivirus engine — passed through without triggering any control.

The auto-deploy behaviour changes the risk calculation

Workflow engines process uploaded files as executable logic — scripts, rule sets, or automation definitions — rather than passive data. An attacker who can upload an arbitrary file to a workflow engine that auto-deploys on receipt has, in effect, achieved server-side code execution gated only by what the workflow engine is permitted to do. The scope of that execution depends on the engine's configuration, but the upload step itself is sufficient to trigger it. Chained with the JWT replay finding from the same engagement, an attacker could reach this endpoint using a captured session token without ever possessing valid credentials.

Fixing the upload pipeline

• Implement server-side file content validation based on magic bytes — inspect the actual file header, not the client-supplied Content-Type or filename extension. A text/xml declaration on a non-XML payload should fail validation before the file is stored or processed.
• Integrate antivirus or malware scanning on all uploaded files before processing or storage. The EICAR test file is the minimum bar — any endpoint accepting workflow files should reject known-bad signatures before deployment is triggered.
• Separate the upload step from the deployment step. Uploaded files should land in a staging area pending explicit review or approval before being promoted to an active workflow. Automatic deployment on receipt eliminates all human gates between an upload and server-side execution.
• Restrict permitted file types to the minimum set required by the workflow engine and validate against an allowlist. If the engine only processes .xml workflow definitions, enforce that restriction at the content level — not the extension level — and reject everything else.

The takeaway

An upload endpoint that auto-deploys is an execution endpoint. The absence of content validation turns a file upload into a one-request code execution path for any authenticated user — and if session controls are also weak, for any attacker who captures a valid token.