ToolJet: authorization bypass via app-environments init (CVE-2026-70642)

An authenticated ToolJet user can retrieve application version metadata belonging to another workspace through the affected environment initialization endpoint. Upgrade ToolJet to restore workspace isolation.

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

cve.now entry. The experiment used a synthetic HTTP fixture.

Eden terminates the HTTP connection to the affected product, evaluates a declarative policy and — in tier 2 — a separately compiled native Rust module under signed module authority, before any byte reaches the application. It does not patch the affected component; the vendor's fixed release remains the durable repair.

Status: Two-tier lab fixture comparison recorded. The fixture ran against Eden 1.103.0.

Module source

The vulnerability

The advisory describes a cross-workspace version metadata read on the app-environments initialization endpoint before ToolJet 3.21.94. The synthetic fixture recorded an authorization marker when an init request carried forged headers.

The Eden patch

Tier 1 — declarative policy (blunt, fail-closed): deny every request under /app-environments/init (non-slash scope), legitimate traffic included — false positives measured below.

Tier 2 — native Rust module gabriel_tooljetauth_v1 (surgical): refuses app-environments init requests carrying forged auth headers

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 this reconstruction of the report’s scoped fixture deny.
2. Apply the declarative policy. Scope the policy to /app-environments/init 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 declaration as remediation.json.

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

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 select the fixed release for the installed branch. Reported fixed releases include 3.21.94. Follow the vendor’s update instructions and confirm the version actually loaded by the service.

Measured comparison (2026-11-12 UTC)

Summary of measured outcomes across the full authority lifecycle (baseline → tier-1 → tier-2 → revoke → restore):

• Baseline (no remediation): benign 200, attack 200 with the primitive recorded at the fixture oracle
• Tier 1 (deny): both probes refused 403 (blunt, false positives included)
• Tier 2 (module): benign 200 / attack 403, zero backend effects

Authority lifecycle and negatives

Import 201, activation: explicit_required; publisher enroll_key, host inventory + approve, reader inspect refused 403; tampered-statement admit 400; invalid-signature admit 403; admit prepared (not serving), activate → receipt serving_now, all expected shards acknowledged the operation. Revoke → the identical attack gets 503 (fail-closed); re-approve + re-activate → 403 again.

Test scope

The recorded results apply to the simulated requests and the fixture's backend markers. Coverage of the vendor's vulnerable code path remains unverified.

Performance

The public evidence for this case does not include request-latency measurements.

Evidence and artifacts

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