v0.5.101: circular dependency mitigation, confluence enhancements, google tasks and bigquery integrations, workflow lock

[waleedlatif1]

• fix(call-chain): x-sim-via propagation for API blocks and MCP tools (fix(call-chain): x-sim-via propagation for API blocks and MCP tools #3332)
• chore(executor): extract shared utils and remove dead code from handlers (chore(executor): extract shared utils and remove dead code from handlers #3334)
• feat(google-sheets): add filter support to read operation (feat(google-sheets): add filter support to read operation #3333)
• fix(templates): show description tagline on template cards (fix(templates): show description tagline on template cards #3335)
• feat(google-translate): add Google Translate integration (feat(google-translate): add Google Translate integration #3337)
• feat(google): add missing tools for Gmail, Drive, Sheets, and Calendar (feat(google): add missing tools for Gmail, Drive, Sheets, and Calendar #3338)
• feat(confluence): return page content in get page version tool (feat(confluence): return page content in get page version tool #3344)
• feat(api): audit log read endpoints for admin and enterprise (feat(api): audit log read endpoints for admin and enterprise #3343)
• feat(workflow): lock/unlock workflow from context menu and panel (feat(workflow): lock/unlock workflow from context menu and panel #3336)
• feat(confluence): add get user by account ID tool (feat(confluence): add get user by account ID tool #3345)
• fix(terminal): thread executionOrder through child workflow SSE events for loop support (fix(terminal): thread executionOrder through child workflow SSE events for loop support #3346)
• feat(bigquery): add Google BigQuery integration (feat(bigquery): add Google BigQuery integration #3341)
• feat(google-tasks): add Google Tasks integration (feat(google-tasks): add Google Tasks integration #3342)
• feat(sidebar): add lock/unlock to workflow registry context menu (feat(sidebar): add lock/unlock to workflow registry context menu #3350)
• fix(confluence): add input validation for user provided parameters (fix(confluence): add input validation for SSRF-flagged parameters #3351)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Feb 26, 2026 7:42am

General fix approach: Ensure that user-controlled values used in URL construction cannot change the host, scheme, or unintended parts of the path, and cannot smuggle URL syntax. This can be done by (a) validating the parameter against a strict pattern and/or (b) encoding it safely as a path segment (e.g., encodeURIComponent). Because the host is already hard‑coded here, we primarily need to make sure blogPostId is strictly constrained and clearly treated as a safe path segment.

Best way to fix without changing functionality: Explicitly restrict blogPostId to a safe pattern (e.g., digits only, or a specific alphanumeric regex) via zod schema for the request body, so that the value is validated before it reaches the code that constructs currentUrl. That makes it clear to both humans and tools that blogPostId cannot contain /, ?, #, or other URL‑control characters. We can then optionally still apply encodeURIComponent when interpolating into the URL as defense in depth. The existing code is already using zod schemas (getBlogPostSchema, createBlogPostSchema); we should use createBlogPostSchema to parse and validate the request JSON at the beginning of the handler instead of destructuring directly from body. Within the schema, we can define blogPostId as a z.string().regex(...) that only allows safe characters, and retain the current validateAlphanumericId check for backward compatibility or remove redundancy later. After parsing with the schema, we use the parsed blogPostId (optionally URL-encoded) in currentUrl. This is a minimal, local change inside apps/sim/app/api/tools/confluence/blogposts/route.ts.

Concretely:

• In the handler around lines 291–305, replace const body = await request.json() and the subsequent manual presence checks with const parsed = createBlogPostSchema.safeParse(await request.json()), returning a 400 if parsing fails. Then destructure from parsed.data.
• When constructing currentUrl at line 320, wrap blogPostId in encodeURIComponent(blogPostId) to ensure it is treated as a literal path segment, even if future changes loosen validation.
• No new imports are required; encodeURIComponent is globally available in Node/Next runtimes.

---

General approach: ensure that all user-influenced values interpolated into the request URL path (cloudId, pageId) are strictly validated against a tight, local allow-list of characters/format before being used. This means rejecting any value that contains /, ?, #, \, or other characters that could break out of the intended path segment, and constraining IDs to the formats Confluence expects, rather than just “alphanumeric up to length N”.

Best concrete fix here: in apps/sim/app/api/tools/confluence/page-descendants/route.ts, add small helper functions (or inline checks) to enforce a strict pattern for pageId and to harden cloudId usage. For pageId, Confluence Cloud page IDs are typically numeric; if we assume that, we can enforce /^\d+$/. If we don’t want to change semantics too much, we can at least require a restricted set like /^[A-Za-z0-9_-]+$/ and disallow any path separators or URL control characters. For cloudId, even though validateJiraCloudId is called, we can add a cheap local guard ensuring it only contains hex digits and dashes (the usual Atlassian cloud ID format) and no slashes or other reserved characters. These local checks are added in this route only, so they don’t change global behavior and are easy to reason about.

Concretely:

• Leave imports as-is; no new dependencies are required.
• After parsing the body and before constructing the URL:
  • Replace the current pageIdValidation = validateAlphanumericId(...) block with a stricter local check using a regular expression, returning a 400 if it fails.
  • Keep the validateJiraCloudId call, but additionally enforce a strict regex for cloudId (e.g., /^[0-9a-fA-F-]+$/) before using it in the URL.
• Do not change the structure of the fetch call or its headers; only ensure the values going into the URL are tightly sanitized.

These changes maintain the existing functionality for valid inputs (Confluence-like IDs) while preventing any malformed or malicious IDs from influencing the request URL path.

---

In general, SSRF mitigation requires ensuring that user-controlled data cannot affect the destination host/scheme and can only influence tightly-constrained parts of the path or query, with strong validation. This code already fixes the scheme and host; the remaining concern is ensuring taskId cannot be used to alter the path structure or inject additional URL components. The best fix here is to (1) enforce a strict pattern on taskId locally, independent of external helpers, and/or (2) treat taskId as a path segment and reject or sanitize any value that is not a single safe segment. This preserves existing functionality while eliminating the possibility that a malicious taskId could lead to unintended endpoints.

Concretely, in apps/sim/app/api/tools/confluence/tasks/route.ts, inside the if (action === 'update' && taskId) block, right after the existing validateAlphanumericId check, add an additional explicit validation step that constrains taskId to a safe pattern, e.g. /^[A-Za-z0-9_-]+$/. If the value fails this check, return a 400 error. Then, when constructing URLs, use this validated taskId (and the validated cloudId) directly in the template strings. This does not change observable behavior for legitimate callers whose taskId already conforms, but it guarantees that no path traversal or special characters can be introduced via taskId. No new imports are strictly necessary; we can use a local regular expression.

General approach: Ensure that any user-controlled portion of a URL cannot affect the scheme, host, or path structure. For path segments, enforce a strict character allowlist and/or encode the value so special characters cannot alter the URL.

Best fix here: Harden the taskId usage by (1) explicitly constraining it to safe characters and (2) ensuring it is treated as a literal path segment, not raw URL syntax. We already have validateAlphanumericId, but CodeQL does not understand that. We can add a small, explicit validation/normalization step right before building the URL that guarantees the taskId is a safe path segment, using a simple regex. This does not change behavior for valid IDs (which are already alphanumeric) but makes the safety condition self-contained and obvious.

Concretely in apps/sim/app/api/tools/confluence/tasks/route.ts around lines 134–141:

• After the existing validateAlphanumericId check passes, add an explicit check enforcing a strict pattern such as /^[A-Za-z0-9_-]+$/. If it fails, return a 400 error.
• Optionally (and conservatively), keep the URL templating but rely on this restrictor so no reserved URL characters can ever be present. Using encodeURIComponent(taskId) is also safe, but if taskId must remain unchanged visually in logs or downstream API expectations, the explicit regex is clearer and preserves the string as-is for valid values.

Changes needed:

• No new imports; we only use built-in regex and existing Next.js/TS features.
• Only modify the if (taskId) { ... } block where url is constructed, inserting a short validation block just before const url = ....

---

In general, SSRF must be mitigated by ensuring that user input cannot change the destination host or introduce dangerous path components, and by validating or mapping any user-supplied identifiers used in URLs against a strict allow‑list or format. Here, cloudId can be supplied by the client via providedCloudId, and even though we already call validateJiraCloudId, CodeQL still considers it tainted. The best targeted fix is to add a strict, local validation/sanitization step for cloudId in this route, ensuring that only an expected safe format is accepted before constructing the URL.

Concretely, in apps/sim/app/api/tools/confluence/tasks/route.ts, immediately after computing cloudId and running validateJiraCloudId, we can add an extra check that cloudId matches a conservative pattern (for example, a UUID-like pattern or at least alphanumeric with dashes) and reject the request with HTTP 400 if it does not. This guarantees there are no /, ?, #, or similar special characters that could alter the path or query structure of the URL. We do not need any new imports: we can use a local RegExp. This keeps functionality the same for valid cloudId values while making the data demonstrably safe for use in the URL and silencing the CodeQL SSRF warning.

In general, SSRF issues are fixed by ensuring that untrusted input cannot directly control the destination of outgoing HTTP requests, particularly the hostname and significant parts of the path. For path segments derived from user input, either (1) strictly validate them against an allow-list or strong format that cannot be abused for path traversal, or (2) avoid trusting client-supplied identifiers by resolving them server-side based on trusted data.

For this specific code, the safest and simplest fix that preserves functionality is to stop allowing the client to provide cloudId at all. Instead, always derive cloudId using the trusted helper getConfluenceCloudId(domain, accessToken), which presumably talks to Atlassian and returns the correct ID for the given domain. This removes the tainted providedCloudId from the data flow entirely. Concretely:

• In apps/sim/app/api/tools/confluence/user/route.ts, change line 23 so that you only destructure domain, accessToken, and accountId from body, removing cloudId: providedCloudId.
• Replace line 47 so that cloudId is always obtained from getConfluenceCloudId(domain, accessToken) and is not conditionally overridden by a user-provided value.
• Keep the existing validateJiraCloudId check so that whatever getConfluenceCloudId returns is still validated before being used in the URL.

No new imports or helper methods are required; we are just simplifying the assignment of cloudId inside the existing file.