fix: prevent link cloaking and add malicious URL detection in workflows

[PeerRich]

What does this PR do?

This PR adds two security features for workflow emails and SMS:

1. Link Cloaking Prevention - Prevents users from hiding URLs behind custom text (e.g., "Click here" linking to a phishing URL). The full URL is always displayed to recipients.

2. Malicious URL Detection - Integrates Cloudflare Radar URL Scanner to detect malicious URLs in workflow content and event type redirect URLs. When malicious URLs are detected, the user's account is locked.

Link Cloaking Prevention Changes:

• Excludes the "link" toolbar item from the Editor component for all workflow actions
• Adds replaceCloakedLinksInHtml utility that transforms <a href="url">text</a> → <a href="url">url</a>
• Applies sanitization to email content before sending in all workflow email paths
• Includes HTML escaping to prevent XSS when href is inserted as text content

Malicious URL Detection Changes:

• Adds urlScanner.ts utility for Cloudflare Radar URL Scanner API integration
• Creates scanWorkflowUrls async task with submit → poll pattern (15s intervals, max 10 attempts)
• Integrates URL scanning into scanWorkflowBody task (runs after Iffy spam scan)
• Adds URL scanning for event type redirect URLs (successRedirectUrl)
• Adds MALICIOUS_URL_IN_WORKFLOW lock reason
• Respects whitelistWorkflows flag - whitelisted users won't be auto-locked

Environment Variables Required

For malicious URL detection:

• CLOUDFLARE_URL_SCANNER_API_TOKEN - API token for Cloudflare Radar
• CLOUDFLARE_ACCOUNT_ID - Cloudflare account ID

URL scanning is automatically disabled if these are not set.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A - no docs changes needed.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Link Cloaking Prevention:

1. Create a new workflow with an email action
2. Verify the "link" button is no longer available in the email body editor toolbar
3. For existing workflows with cloaked links, trigger the workflow and verify the sent email displays the full URL

Malicious URL Detection:

1. Set CLOUDFLARE_URL_SCANNER_API_TOKEN and CLOUDFLARE_ACCOUNT_ID environment variables
2. Create a workflow with a known malicious URL in the email body
3. Verify the tasker creates a scanWorkflowUrls task
4. Verify the user is locked if the URL is flagged as malicious
5. Test event type redirect URL scanning by setting a redirect URL in Advanced settings

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have checked if my changes generate no new warnings

Human Review Checklist

• Verify Cloudflare API integration (endpoint: /client/v4/accounts/{account_id}/urlscanner/v2/scan)
• Verify polling logic handles pending (404), completed (200), and error states correctly
• Verify URL extraction regex captures href attributes and bare URLs properly
• Verify fail-open behavior is acceptable (marks as verified if API errors occur)
• Verify whitelistWorkflows flag correctly prevents auto-locking
• Review the 25 unit tests for link cloaking sanitization
• Note: No unit tests for URL scanning code - relies on integration testing

Important Review Notes

1. Fail-open behavior: If Cloudflare API submissions fail or max poll attempts reached, the workflow step is marked as verified (not blocked). This prevents legitimate workflows from being blocked due to API issues.

2. Async scanning: URL scanning is async via the tasker system. Workflow steps have verifiedAt set to null until scanning completes. Steps with null verifiedAt should not be sent.

3. Pre-existing fixes: This PR also fixes two pre-existing lint issues:

   • parseInt(..., 0) → parseInt(..., 10) in constants.ts
   • secondaryEmail && secondaryEmail.emailVerified → secondaryEmail?.emailVerified in update.handler.ts

---

Link to Devin run: https://app.devin.ai/sessions/c245edc8038c4ac99ae88d65cbe65b71
Requested by: peer@cal.com (@PeerRich)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[vercel]

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

3 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
cal	Ignored		Dec 30, 2025 3:25am
cal-companion	Ignored	Preview	Dec 30, 2025 3:25am
cal-eu	Ignored		Dec 30, 2025 3:25am

[cubic-dev-ai]

1 issue found across 6 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="packages/features/ee/workflows/lib/reminders/utils.ts">

<violation number="1" location="packages/features/ee/workflows/lib/reminders/utils.ts:146">
P1: XSS vulnerability: The `href` value is inserted directly into HTML text content without escaping. If a malicious href contains `&lt;/a&gt;&lt;script&gt;...&lt;/script&gt;`, it would close the anchor tag and execute arbitrary JavaScript. The `href` should be HTML-escaped before being inserted into text content.</violation>
</file>

_{Reply to cubic to teach it or ask questions. Tag @cubic-dev-ai to re-run a review.}

[github-actions]

E2E results are ready!

• Workflow #96076.2 latest results

[chopsol]

Unfortunately, this PR is a modest idea.
When implementing HTML messages, it should be possible to offer links behind ‘click here’ texts.
In its current form, you have destroyed all my work on designing appealing HTML emails. And I can't even change it easily, as the function for editing hyperlinks has been completely removed without replacement.

Users should be free to activate or deactivate this option. Especially with a self-hosted instance, this is a form of paternalism that I would very much like to reverse.

[PeerRich]

Unfortunately, this PR is a modest idea. When implementing HTML messages, it should be possible to offer links behind ‘click here’ texts. In its current form, you have destroyed all my work on designing appealing HTML emails. And I can't even change it easily, as the function for editing hyperlinks has been completely removed without replacement.

Users should be free to activate or deactivate this option. Especially with a self-hosted instance, this is a form of paternalism that I would very much like to reverse.

i agree. we are reverting this change