AppFlowy Cloud: stored XSS via blob upload Content-Type (CVE-2026-127203)

A workspace member can upload an active blob that executes script when an affected AppFlowy Cloud deployment serves it inline. Apply the vendor’s mitigation to protect users who open stored blobs on the application’s origin.

Public CVE record · Vendor or publisher advisory · Native module source

CVE advisory record · Publisher advisory · Module source

Result. The marked request reached the backend in the baseline and raised its counter. The native rule refused that request with HTTP 403 and preserved HTTP 200 for the benign probe. The synthetic fixture ran through Eden 1.103.0 on November 12, 2026 (UTC).

The vulnerability

An authenticated AppFlowy Cloud workspace member can upload a blob with an active media type. Serving the upload inline from the application’s origin lets a browser interpret the blob as HTML or SVG. The advisory also identifies an unauthenticated retrieval route, which matters even though the uploader must be authenticated.

The advisory lists AppFlowy Cloud through 0.9.64 as affected. The CVE record reports a CVSS base score of 5.1.

The Eden patch

Tier 1 — declarative policy. The recorded policy denies requests to /api/workspace/object and its descendants. The empty method list leaves the deny unrestricted by HTTP method. This is a coarse rule and blocked the benign probe on the same path.

{
  "version": 1,
  "profile": "http-structure-v1",
  "policy": {
    "version": 1,
    "rules": [
      {
        "scope": {
          "methods": [],
          "path": "/api/workspace/object",
          "descendants": true
        },
        "require": {
          "kind": "deny"
        }
      }
    ]
  }
}

Tier 2 — native Rust module. gabriel_appflowyxss_v1 waits for the request to be complete, checks whether the request target starts with /api/workspace/object, and looks for any configured marker in the body. The substring comparison is ASCII case-insensitive. Outside that prefix or without a marker, the module returns Continue. The shown lines are excerpts from the linked source.

const ROUTE: &[u8] = b"/api/workspace/object";
static NEEDLES: [&[u8]; 2] = [b"text/html", b"onerror="];

NEEDLES.iter().any(|n| find_ignore_case(body, n).is_some()) && return Ok(Decision::Refuse);

Implement the remediation

Use this procedure in an isolated fixture to reproduce the scoped restriction. Follow the vendor update for the underlying exposure. See deployment prerequisites.

1. Prepare the target. Verify the loaded product and version against the advisory. Use a compatible Eden HTTP interlay and an authenticated operator with Configure permission. Use the recorded declaration and the linked source when applicable.
2. Apply the declarative policy. Scope the policy to /api/workspace/object and descendants (all methods, deny). Set INTERLAY to the target interlay UUID in the authenticated Eden CLI. Run an authenticated GET /api/v1/interlays/{interlay} with X-Eden-Verbose: true. Save its complete current settings object as current-settings.json and retain the prior remediation declaration for recovery. Set IDEMPOTENCY_KEY to a fresh key for this intended mutation.

Save the JSON in the patch section as remediation.json.

jq -e --slurpfile policy remediation.json \
  '.remediation = $policy[0] | {settings: .}' current-settings.json \
  > interlay-update.json
eden api request PATCH "/api/v1/interlays/$INTERLAY" \
  --header "Idempotency-Key:$IDEMPOTENCY_KEY" \
  --body-file interlay-update.json --content-type application/json --confirm

3. Verify the serving policy. Read back the interlay.

eden api request GET "/api/v1/interlays/$INTERLAY" \
  --header 'X-Eden-Verbose:true'

Check that remediation_status.state is ready and both desired and effective SHA-256 values match the intended declaration. Replay the benign and marked requests in the recorded comparison on an isolated target. Check the recorded response and backend outcome for each probe. 4. Restore the previous policy. Coordinate the change with any other operator updating this interlay. Read current settings again and merge the saved remediation field into them. If the prior settings had no remediation field, omit it in the replacement. Send the same PATCH with a fresh idempotency key, then read back the intended state. Repeat the verification probes. Keep the affected route isolated if restoring the prior settings reopens exposure.

Vendor update. Use the advisory to identify the supported update or workaround for the installed release. The advisory data used here supplies no fixed version. Confirm the running version and verify the affected feature after the change.

Fixture and probes

The fixture was a synthetic HTTP handler behind Eden. It answered the probes and kept a separate counter that increased when the handler recognized its marker bytes. The counter measures a fixture effect. An HTTP 200 from the baseline does not by itself establish that the counter moved.

Request. POST /api/workspace/object/upload for the benign probe and the marked probe.

The benign fixture body carried an ordinary blob name. The second body put a script marker in the name and a media-type string in a JSON field. The handler looked for those body bytes and incremented a marker on a match.

Measured comparison (2026-11-12 UTC)

The values after each status are the observed increases in the backend marker counter.

Request latency

Eden telemetry request spans measured in the fixture. Latencies are in microseconds (µs).

These are durations of the recorded request spans. The passing request includes the path to the fixture, while the policy and native refusal rows describe requests that ended at Eden. The rows represent different request outcomes, so their difference does not isolate module CPU time. The sample counts are shown for each arm.

Signed module authority

The module import returned HTTP 201 and required explicit activation. Signature verification was deferred at import. Read-only inspection returned HTTP 403, admission with a tampered statement returned HTTP 400, and admission with an invalid signature returned HTTP 403. The activation receipt reported the module serving on all expected shards.

After revocation, the same marked request received HTTP 503. Re-approval and reactivation restored HTTP 403. The source digest below identifies the linked Rust file. The binary digest identifies the artifact recorded in the activation evidence.

• Source SHA-256 87c02f6326bc8ee161b51b5ccce3f858e3d7c5719fb031e3391124efd5426590
• Tested binary SHA-256 dbfa50b05a2e7712dec7ae28bfbe78d2f1d03a831f057744c51b53c291bd76cf

Test scope

This module scans body bytes. Coverage of the upload Content-Type header and the inline retrieval behavior remains unverified. The experiment did not upload a stored blob, request it anonymously, or open it in a browser. A media type supplied only in a header is outside the body rule.

Evidence and artifacts

• Public CVE record
• Vendor or publisher advisory
• Published module source