{"version":"2.1.163","anchor":"workflow-vm-security-hardening","canonical_anchor":"workflow-vm-security-hardening","heading":"Workflow VM Security Hardening","tier":null,"area":null,"scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.163\/e\/workflow-vm-security-hardening","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.163","markdown":"### Workflow VM Security Hardening\n\n**What**\n\nThe workflow VM execution environment was substantially hardened against Proxy-based attacks that could cross the JavaScript VM sandbox boundary.\n\n**Details**\n\n- Arrays crossing the VM boundary are now deep-cloned inside the VM sandbox. The array length is read once (preventing a Proxy `length` getter that increments from causing an infinite loop on the host thread).\n- The maximum array length crossing the boundary is capped; exceeding it throws a clear error rather than hanging.\n- Functions are never cloned across the boundary (they become `undefined`).\n- A private `_CAP` symbol on boundary-cap errors prevents hostile Proxy traps from intercepting and suppressing the error.\n- The `budget` object passed to workflows now uses `__proto__: null` to prevent prototype chain pollution.\n- `agent`, `parallel`, `pipeline`, `workflow`, and `args` are injected into the VM context via `Object.defineProperty` with proper wrapping rather than being in the initial context literal.\n- The `args` value is serialized with `JSON.stringify`\/`JSON.parse` through the VM context to prevent host-side Proxy objects from being accessible inside the script.\n\n**Evidence**\n\nCross-VM clone code (search for `\"array length is not a safe integer across the workflow VM boundary\"`)"}