{"id":"CVE-2026-92939","aliases":["CLSA-2026-1790888247","EUVD-2026-81589","GHSA-46pr-c5wc-xffx","GHSA-6jgm-4w45-vh8j","GHSA-8686-vhfx-7r3j","GHSA-8hr7-r645-pc6w","ROOT-APP-NPM-CVE-2026-92939"],"status":"published","title":"vm2 3.11.3 through 3.11.6 Native Code Execution via crypto.setEngine","description":"vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","severity":{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00616,"percentile":0.49993,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-114"],"published":"2026-09-17T13:46:03Z","modified":"2026-10-28T02:30:52Z","fixes":[{"ecosystem":"npm","package":"vm2","fixed_in":["3.11.7"],"sources":["ghsa","osv"]},{"ecosystem":"Root:npm","package":"vm2","fixed_in":["3.11.6-aikido.1"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@rootio/vm2","fixed_in":["3.11.6-root.io.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.11.3"},{"last_affected":"3.11.6"},{"fixed":"3.11.7"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.11.5-tuxcare.0"},{"fixed":"3.11.5-tuxcare.3"}]}],"versions":["3.11.5","3.11.5-tuxcare.1","3.11.5-tuxcare.2"],"bundled":13},{"source":"osv","ecosystem":"npm","package":"vm2","ranges":[{"type":"SEMVER","events":[{"introduced":"3.11.3"},{"fixed":"3.11.7"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.11.6-aikido.1"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@rootio/vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.11.6-root.io.1"}]}]}],"products":[{"vendor":"patriksimek","product":"vm2"}],"references":[{"url":"https://github.com/patriksimek/vm2/security/advisories/GHSA-46pr-c5wc-xffx","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/vm2-3.11.3-through-3.11.6-native-code-execution-via-crypto-setengine","tags":["third-party-advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92939","tags":["advisory"]},{"url":"https://github.com/patriksimek/vm2/commit/aa146a77f859325e079f3bfbfe6d8309af483daa","tags":["web"]},{"url":"https://github.com/patriksimek/vm2/releases/tag/v3.11.7","tags":["web"]},{"url":"https://github.com/advisories/GHSA-46pr-c5wc-xffx"},{"url":"https://github.com/advisories/GHSA-6jgm-4w45-vh8j"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92939.json","tags":["advisory"]},{"url":"https://github.com/patriksimek/vm2","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-92939","title":"vm2 3.11.3 through 3.11.6 Native Code Execution via crypto.setEngine","description":"vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"published","published":"2026-09-17T13:46:03.558Z","modified":"2026-09-17T14:26:31.623Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical","assessor":"cna"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T13:48:13.398044Z"}],"euvd":[{"id":"EUVD-2026-81589","description":"vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"published","published":"2026-09-17T13:46:03Z","modified":"2026-09-17T14:26:31Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical"}],"updated_at":"2026-11-02T17:28:12.076337Z"}],"ghsa":[{"id":"GHSA-46pr-c5wc-xffx","title":"vm2 crypto builtin loads attacker native code through setEngine","description":"Summary\n\nvm2 3.11.6 exposes the host `crypto` module to a `NodeVM` when that single builtin is allowed. The module is presented through a read-only bridge, but its functions still execute with host-process authority. `crypto.setEngine()` accepts a filesystem path and asks OpenSSL to dynamically load the referenced native library.\n\nAn attacker whose untrusted plugin package contains a native library can therefore load that library into the host process by calling `crypto.setEngine()` from sandboxed JavaScript. The native library's constructor executes before OpenSSL finishes validating whether the file is a usable engine. Consequently, even the expected `ERR_CRYPTO_ENGINE_UNKNOWN` exception occurs only after arbitrary native code has already run.\n\nThe exploit requires only the `crypto` builtin. It does not require `fs`, `process`, `module`, `child_process`, `worker_threads`, `vm`, `inspector`, unrestricted builtins, or vm2 nesting.\n\n### Details\n\nThe vulnerable boundary is the generic builtin loader. Builtins that are not specially wrapped or classified as dangerous are imported in the host realm and exposed through a recursive read-only proxy:\n\n```js\nbuiltins.set(key, special ? special : vm =\u003e vm.readonly(hostRequire(key)));\n```\n\nRead-only prevents sandbox code from assigning properties on the module object. It does not reduce the authority of callable exports. Calls are forwarded to the original host function with bridge values converted back to host values.\n\nThe `crypto` module includes this callable export:\n\n```js\ncrypto.setEngine(enginePath)\n```\n\nWhen `enginePath` names a dynamic library, OpenSSL loads that file into the current process. Operating-system dynamic loaders execute library constructors as part of loading. Engine-symbol validation happens afterward. A file does not have to become a functional cryptographic engine for its constructor to execute.\n\nThe resulting exploit flow is:\n\n```text\nattacker supplies an untrusted plugin package containing a native library\n  -\u003e host executes the plugin in NodeVM with only crypto allowed\n  -\u003e plugin calls crypto.setEngine(pathToBundledLibrary)\n  -\u003e vm2 forwards the call to the host crypto module\n  -\u003e OpenSSL asks the operating-system loader to load the library\n  -\u003e the library constructor executes native code in the host process\n  -\u003e OpenSSL may then reject the file, but host compromise has already occurred\n```\n\nThis is different from merely granting JavaScript filesystem access. A plugin system commonly has to place an untrusted package on disk before running its JavaScript. The native file can therefore already exist inside that package even when the sandbox denies `fs` and all process-execution builtins. Allowing `crypto` for hashing or signature verification unexpectedly turns that inert package file into a native-code execution primitive.\n\n### PoC\n\nThe attached PoC is local and harmless. Its native library constructor creates a marker file; it does not spawn a process, open a network connection, or modify any other file.\n\n1. Install Node.js with OpenSSL engine support, a C compiler, and npm.\n2. In the attached `poc` directory, install the exact affected package:\n\n   ```bash\n   npm install --ignore-scripts\n   ```\n\n3. Build the marker library.\n\n   On macOS:\n\n   ```bash\n   cc -dynamiclib -O2 -o probe-engine.dylib engine_probe.c\n   node poc.js ./probe-engine.dylib\n   ```\n\n   On Linux:\n\n   ```bash\n   cc -shared -fPIC -O2 -o probe-engine.so engine_probe.c\n   node poc.js ./probe-engine.so\n   ```\n\n4. A vulnerable result contains all of the following:\n\n   - the sandbox configuration lists only `crypto` as an allowed builtin;\n   - `crypto.setEngine()` reports `ERR_CRYPTO_ENGINE_UNKNOWN` or returns;\n   - `vm2-setengine-native-marker.txt` exists afterward;\n   - the marker contains `VM2_SETENGINE_NATIVE_CODE_EXECUTED`.\n\nThe exception is not a negative result. The marker proves that the native constructor ran before engine validation failed.\n\n### Impact\n\nThis is a sandbox escape to arbitrary native code execution. The code runs with the operating-system identity and privileges of the Node.js host process, outside all vm2 language and module restrictions.\n\nAn attacker can replace the marker-only constructor with native code that:\n\n- reads application secrets, environment variables, credentials, and files available to the host user;\n- modifies application data or executable files and establishes persistence;\n- accesses internal services using the host's network identity;\n- steals other tenants' data from the same process;\n- terminates or corrupts the host process; and\n- executes arbitrary operating-system actions permitted to the host account.\n\nThe realistic affected workflow is a plugin, automation, notebook, or multi-tenant code runner that stores attacker-supplied package contents on disk and runs the package's JavaScript in `NodeVM` while allowing `crypto`. The attacker does not need the sandbox to expose a file-write or command-execution module.","status":"published","published":"2026-10-01T15:28:36Z","modified":"2026-10-01T15:28:37Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T14:41:24.739884Z"},{"id":"GHSA-6jgm-4w45-vh8j","title":"Duplicate Advisory: vm2 crypto builtin loads attacker native code through setEngine","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-46pr-c5wc-xffx. This link is maintained to preserve external references.\n\n## Original Description\nvm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"withdrawn","published":"2026-09-17T15:32:14Z","modified":"2026-10-01T15:28:22Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T14:41:24.739884Z"}],"nvd":[{"id":"CVE-2026-92939","description":"vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"published","published":"2026-09-17T14:17:58.97Z","modified":"2026-09-17T15:17:00.65Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical","assessor":"secondary"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T14:12:49.013904Z"}],"osv":[{"id":"CVE-2026-92939","title":"vm2 3.11.3 through 3.11.6 Native Code Execution via crypto.setEngine","description":"vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"published","published":"2026-09-17T13:46:03.558Z","modified":"2026-10-28T02:30:52.827915663Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T15:45:20.588039Z"},{"id":"GHSA-46pr-c5wc-xffx","title":"vm2 crypto builtin loads attacker native code through setEngine","description":"Summary\n\nvm2 3.11.6 exposes the host `crypto` module to a `NodeVM` when that single builtin is allowed. The module is presented through a read-only bridge, but its functions still execute with host-process authority. `crypto.setEngine()` accepts a filesystem path and asks OpenSSL to dynamically load the referenced native library.\n\nAn attacker whose untrusted plugin package contains a native library can therefore load that library into the host process by calling `crypto.setEngine()` from sandboxed JavaScript. The native library's constructor executes before OpenSSL finishes validating whether the file is a usable engine. Consequently, even the expected `ERR_CRYPTO_ENGINE_UNKNOWN` exception occurs only after arbitrary native code has already run.\n\nThe exploit requires only the `crypto` builtin. It does not require `fs`, `process`, `module`, `child_process`, `worker_threads`, `vm`, `inspector`, unrestricted builtins, or vm2 nesting.\n\n### Details\n\nThe vulnerable boundary is the generic builtin loader. Builtins that are not specially wrapped or classified as dangerous are imported in the host realm and exposed through a recursive read-only proxy:\n\n```js\nbuiltins.set(key, special ? special : vm =\u003e vm.readonly(hostRequire(key)));\n```\n\nRead-only prevents sandbox code from assigning properties on the module object. It does not reduce the authority of callable exports. Calls are forwarded to the original host function with bridge values converted back to host values.\n\nThe `crypto` module includes this callable export:\n\n```js\ncrypto.setEngine(enginePath)\n```\n\nWhen `enginePath` names a dynamic library, OpenSSL loads that file into the current process. Operating-system dynamic loaders execute library constructors as part of loading. Engine-symbol validation happens afterward. A file does not have to become a functional cryptographic engine for its constructor to execute.\n\nThe resulting exploit flow is:\n\n```text\nattacker supplies an untrusted plugin package containing a native library\n  -\u003e host executes the plugin in NodeVM with only crypto allowed\n  -\u003e plugin calls crypto.setEngine(pathToBundledLibrary)\n  -\u003e vm2 forwards the call to the host crypto module\n  -\u003e OpenSSL asks the operating-system loader to load the library\n  -\u003e the library constructor executes native code in the host process\n  -\u003e OpenSSL may then reject the file, but host compromise has already occurred\n```\n\nThis is different from merely granting JavaScript filesystem access. A plugin system commonly has to place an untrusted package on disk before running its JavaScript. The native file can therefore already exist inside that package even when the sandbox denies `fs` and all process-execution builtins. Allowing `crypto` for hashing or signature verification unexpectedly turns that inert package file into a native-code execution primitive.\n\n### PoC\n\nThe attached PoC is local and harmless. Its native library constructor creates a marker file; it does not spawn a process, open a network connection, or modify any other file.\n\n1. Install Node.js with OpenSSL engine support, a C compiler, and npm.\n2. In the attached `poc` directory, install the exact affected package:\n\n   ```bash\n   npm install --ignore-scripts\n   ```\n\n3. Build the marker library.\n\n   On macOS:\n\n   ```bash\n   cc -dynamiclib -O2 -o probe-engine.dylib engine_probe.c\n   node poc.js ./probe-engine.dylib\n   ```\n\n   On Linux:\n\n   ```bash\n   cc -shared -fPIC -O2 -o probe-engine.so engine_probe.c\n   node poc.js ./probe-engine.so\n   ```\n\n4. A vulnerable result contains all of the following:\n\n   - the sandbox configuration lists only `crypto` as an allowed builtin;\n   - `crypto.setEngine()` reports `ERR_CRYPTO_ENGINE_UNKNOWN` or returns;\n   - `vm2-setengine-native-marker.txt` exists afterward;\n   - the marker contains `VM2_SETENGINE_NATIVE_CODE_EXECUTED`.\n\nThe exception is not a negative result. The marker proves that the native constructor ran before engine validation failed.\n\n### Impact\n\nThis is a sandbox escape to arbitrary native code execution. The code runs with the operating-system identity and privileges of the Node.js host process, outside all vm2 language and module restrictions.\n\nAn attacker can replace the marker-only constructor with native code that:\n\n- reads application secrets, environment variables, credentials, and files available to the host user;\n- modifies application data or executable files and establishes persistence;\n- accesses internal services using the host's network identity;\n- steals other tenants' data from the same process;\n- terminates or corrupts the host process; and\n- executes arbitrary operating-system actions permitted to the host account.\n\nThe realistic affected workflow is a plugin, automation, notebook, or multi-tenant code runner that stores attacker-supplied package contents on disk and runs the package's JavaScript in `NodeVM` while allowing `crypto`. The attacker does not need the sandbox to expose a file-write or command-execution module.","status":"published","published":"2026-10-01T15:28:36Z","modified":"2026-10-01T15:45:05.648155026Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T15:46:36.434231Z"},{"id":"GHSA-6jgm-4w45-vh8j","title":"Duplicate Advisory: vm2 crypto builtin loads attacker native code through setEngine","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-46pr-c5wc-xffx. This link is maintained to preserve external references.\n\n## Original Description\nvm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.","status":"withdrawn","published":"2026-09-17T15:32:14Z","modified":"2026-10-01T15:45:06.202722723Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"},{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"cwes":["CWE-114"],"updated_at":"2026-11-02T15:46:39.965326Z"},{"id":"CLSA-2026-1790888247","title":"TuxCare security update for vm2 (15 CVEs)","description":"TuxCare rebuilt vm2 to address 15 CVEs. Fixed in 3.11.5-tuxcare.3.","status":"published","published":"2026-10-01T20:57:27Z","modified":"2026-10-15T09:47:57.771844817Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"ROOT-APP-NPM-CVE-2026-92939","title":"CVE-2026-92939 in vm2 - Patched by Root","description":"Root has patched CVE-2026-92939 in the vm2 package for Root:npm. Multiple fixed versions available.","status":"published","published":"2026-10-19T07:16:29Z","modified":"2026-10-19T08:15:05.420880843Z","updated_at":"2026-11-02T15:53:27.649662Z"}]}}