[comp] Production Deploy

[github-actions]

This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app (staging)	Ready	Preview	Comment	Nov 8, 2025 0:01am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal (staging)	Skipped			Nov 8, 2025 0:01am

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV: npm package ai@5.0.0 has GHSA-rwvc-j5jr-mgvh (low) — filetype whitelist bypass; fixed in 5.0.52.

---

📦 Dependency Vulnerabilities

🟢 NPM Packages (LOW)

Risk Score: 2/10 | Summary: 1 low CVE found

Package	Version	CVE	Severity	CVSS	Summary	Fixed In
ai	5.0.0	GHSA-rwvc-j5jr-mgvh	LOW	N/A	Vercel’s AI SDK's filetype whitelists can be bypassed when uploading files	5.0.52

---

🛡️ Code Security Analysis

View 9 file(s) with issues

🔴 .cursor/rules/trigger.advanced-tasks.mdc (HIGH Risk)

#	Issue	Risk Level
1	Exposed accessToken prop in client-side code (token leakage)	HIGH
2	Unvalidated payload.dataUrl fetch can enable SSRF/arbitrary requests	HIGH
3	Per-user queue names from userId may allow resource exhaustion	HIGH
4	User IDs/tags stored as tags can leak PII in logs/telemetry	HIGH
5	Logging item.id in metadata may leak sensitive data	HIGH

Recommendations:

1. Do not pass secrets (access tokens) into client-side components. Instead, trigger tasks via server-side endpoints that sign or mint short-lived tokens, or use a dedicated server-side API that invokes the task. If client-side tokens are required, make them scoped and short-lived and enforce least privilege and audience checks.
2. Validate and whitelist domains for payload.dataUrl before performing fetches. Perform the download/processing on a trusted server-side component that enforces DNS/IP allowlists, prevents internal network access (block RFC1918/localhost), and scans/validates responses. Treat any user-controlled URL as untrusted input.
3. Avoid creating unbounded per-user queues based directly on user-controlled IDs. Sanitize and normalize userId-derived names, impose a limit on the total number of dynamic queues, throttle/ratelimit queue creation, and reuse shared queues with per-job metadata or keys to enforce per-user concurrency instead of distinct queues.
4. Avoid storing raw PII in tags. Use hashed or pseudonymized identifiers (e.g., HMAC or salted hash) or non-identifying tokens for tags. Restrict tag access, log retention, and telemetry exports. Ensure tags cannot be used to reconstruct user identity.
5. Mask or redact sensitive fields before writing to metadata/logs. Replace item.id or other identifiers with truncated/hashes or use a separate non-identifying correlation id. Apply logging/metadata retention and access controls and treat metadata as potentially sensitive.

🟡 .cursor/rules/trigger.basic.mdc (MEDIUM Risk)

#	Issue	Risk Level
1	No runtime validation for payloads in process-data and child-task	MEDIUM
2	Console logging may expose sensitive data	MEDIUM

Recommendations:

1. Add runtime schema validation for task payloads (e.g., use schemaTask with zod or other validation) to ensure payloads conform to expected shapes before processing.
2. Where tasks are triggered from external sources, validate and sanitize inputs at the boundary (even if TypeScript types exist).
3. Avoid logging raw payloads. Sanitize or redact PII and sensitive fields before logging; use structured logging with explicit fields and severity levels.
4. If any string values used as tokens in code are in fact secrets (API keys, auth tokens), move them to secrets management or environment variables and remove them from source control. Rotate any secrets that were committed.
5. Enforce least-privilege and authentication on task triggers (validate callers, restrict who/what can trigger tasks).

🟡 .cursor/rules/trigger.realtime.mdc (MEDIUM Risk)

#	Issue	Risk Level
1	Access tokens passed to frontend props may leak to users	MEDIUM
2	No validation of runId or accessToken before subscribing	MEDIUM
3	Rendering run.output in UI may expose sensitive data	MEDIUM
4	Hardcoded run IDs in publicToken scope (example)	MEDIUM

Recommendations:

1. Do not send full long‑lived tokens to the client. Use short‑lived, minimal‑scope tokens (or single‑use tokens) and mint them server‑side when needed.
2. Perform server‑side authorization and validation of runId and accessToken before returning any data or tokens to the client. Validate that the requesting user/session is allowed to access the requested run.
3. Avoid rendering raw run.output directly in the UI. Filter or redact sensitive fields server‑side, or explicitly whitelist non‑sensitive fields. Sanitize any data before rendering to prevent accidental info disclosure and XSS.
4. Remove hardcoded identifiers from code and examples that could be mistaken for production credentials. Use clearly labeled placeholders (e.g., <RUN_ID>) in docs and ensure real IDs/tokens are provided at runtime via configuration or environment variables.
5. Enforce token rotation and expiration policies. Prefer single‑use trigger tokens or short expiration times for public tokens, and log/monitor token usage for anomalies.
6. Add input validation and type checks for runId and any parameters accepted from untrusted sources. Use server‑side checks to ensure runId format and ownership before performing subscriptions.

🔴 .cursor/rules/trigger.scheduled-tasks.mdc (HIGH Risk)

#	Issue	Risk Level
1	Unauthenticated POST: anyone can create schedules for arbitrary users	HIGH
2	Unvalidated user input: timezone, userId, deduplicationKey used directly	HIGH
3	Potential SQL injection: db.getUser(p.externalId) uses untrusted externalId	HIGH

Recommendations:

1. Require authentication on the POST route and perform authorization: ensure the caller is authenticated and allowed to create schedules for the specified userId/externalId.
2. Enforce server-side validation and strict typing for incoming JSON fields (timezone, userId, deduplicationKey). Validate timezone against a known IANA timezone list (or use schedules.timezones() if provided by the SDK). Restrict userId format (e.g., UUID) and enforce length/character whitelist for deduplicationKey.
3. Use parameterized queries / prepared statements or a safe ORM for db.getUser and all DB access. Review the implementation of db.getUser to ensure it does not interpolate p.externalId into raw SQL.
4. Apply rate limiting and quotas to the schedule creation endpoint to mitigate mass abuse.
5. Add input sanitation where needed, and centralized validation (libraries like Zod, Joi, or runtime checks). Log and monitor suspicious schedule creation activity and failed validation attempts.

🟡 apps/app/src/jobs/tasks/email/weekly-task-digest-email.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing input validation for payload fields (email, names, tasks)	MEDIUM
2	Unsanitized payload forwarded to email sender (possible injection/XSS)	MEDIUM
3	Sensitive PII (email, organizationName) logged in plaintext	MEDIUM
4	Verbose error messages logged may leak internal details	MEDIUM

Recommendations:

1. Perform runtime validation of the payload (email format, string lengths, tasks array/schema). Use a schema validator (e.g., Zod, Joi, or Yup) at the task entry point so malformed or malicious payloads are rejected before processing.
2. Sanitize/escape user-provided values before passing them into email templates. Ensure the sendWeeklyTaskDigestEmail implementation uses a safe templating engine with automatic escaping or explicitly escape values to prevent HTML/template injection.
3. Avoid logging PII in plaintext. Remove or redact emails and organization names from INFO logs in production (log hashed or truncated identifiers instead). If required for debugging, gate detailed logs behind a secure debug flag and store them in an access-controlled logging system.
4. Limit and validate payload sizes (max number of tasks, max length per field) to prevent abuse and resource exhaustion.
5. Do not surface raw error messages to logs/clients. Log non-sensitive error codes or classify errors, and store full stacktraces only in restricted, access-controlled diagnostics. Consider wrapping errors to provide consistent, non-revealing messages.

🟡 apps/app/src/jobs/tasks/task/weekly-task-reminder.ts (MEDIUM Risk)

#	Issue	Risk Level
1	No validation/sanitization of recipient emails (format/header injection risk)	MEDIUM
2	Task titles/content not sanitized before emailing (XSS/data leakage risk)	MEDIUM
3	Domain exclusion uses includes('@trycomp.ai') — can be bypassed/case-sensitive	MEDIUM
4	Bulk loads all organizations/tasks in memory — DoS/timeouts risk	MEDIUM
5	Error handler returns/logs raw error details, may leak sensitive info	MEDIUM

Recommendations:

1. Validate and sanitize recipient emails before sending: enforce a strict email format check (e.g., use validator.js isEmail), normalize to lowercase, and strip CR/LF characters (\r and \n) from any fields used in headers to prevent header injection. Also validate/verify addresses when possible (send verification emails).
2. Escape or sanitize all user-provided content (task titles, user names, organization names) before inserting into email templates. Prefer using a templating engine that auto-escapes HTML or run content through a sanitizer (e.g., DOMPurify on server or sanitize-html) and/or include a plaintext fallback to avoid HTML injection issues.
3. Make domain exclusion robust: compare domains case-insensitively (e.g., lowercasedEmail.endsWith('@trycomp.ai') or parse and compare the domain portion), or better maintain an explicit whitelist/blacklist of allowed internal domains and verify exact domain matches rather than substring includes.
4. Avoid loading everything into memory at once. Paginate or stream organizations and members (cursor-based queries), and fetch tasks per-organization in paginated batches. Consider processing organizations in chunks with backpressure and respecting the scheduler's maxDuration. Also cap total emailPayloads and handle large volumes with a job queue or worker pool.
5. Do not return or log raw error objects in production. Log only minimal, non-sensitive details and correlate with an internal error id for troubleshooting. For responses, return a generic error message. Ensure sensitive stack traces or DB error messages are not exposed to downstream callers or public logs.

🟡 apps/portal/src/app/lib/auth.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Logged NEXT_PUBLIC_BETTER_AUTH_URL may leak environment values	MEDIUM
2	Wildcard trustedOrigins 'https://*.trycomp.ai' allows any subdomain	MEDIUM
3	Invitation/email fields used in emails without sanitization	MEDIUM
4	generateId:false may allow predictable or colliding IDs if misconfigured	MEDIUM

Recommendations:

1. Remove or restrict logging of environment variables (avoid console.log(process.env.*) in production). If you must log, redact or limit to non-sensitive values and ensure logs are access-controlled.
2. Replace wildcard trustedOrigins with an explicit allowlist of exact hostnames (e.g., https://app.trycomp.ai, https://dashboard.trycomp.ai). If wildcards are necessary, narrow to the smallest possible scope and document why.
3. Sanitize and/or encode any user-controllable values used in email templates (data.email, data.organization.name, data.invitation.id). Use a trusted templating library that auto-escapes output or explicitly escape HTML and URL components. Validate email addresses server-side.
4. If relying on DB-side ID generation (generateId: false), ensure the database or schema produces cryptographically-unpredictable IDs when needed and that collision risk is mitigated (use UUIDv4 or a sufficiently large unique key). Audit ID-generation configuration in Prisma and any custom generators.

🟡 packages/email/emails/reminders/weekly-task-digest.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unsanitized organizationId used to build task URLs	MEDIUM
2	Unsanitized task.id used directly in hrefs	MEDIUM
3	External web fonts loaded from app.trycomp.ai (can track opens)	MEDIUM
4	Recipient email included verbatim (privacy leak)	MEDIUM

Recommendations:

1. Validate and/or whitelist organizationId and task.id server-side before passing them into this template. Ensure they match expected patterns (e.g., alphanumeric, UUID) and reject or normalize unexpected values.
2. URL-encode path segments when constructing links (e.g., encodeURIComponent for organizationId and task.id) to prevent injection of special characters into URLs and to ensure valid hrefs.
3. Continue to rely on the rendering framework's automatic escaping for plain text (React/JSX escapes strings), but if any titles can include HTML, strip or sanitize HTML on input and/or use a safe HTML sanitizer library. Also consider truncating extremely long titles.
4. Avoid using remote web fonts in emails if you want to prevent tracking. Host fonts on a privacy-respecting CDN you control, inline critical styles, or fall back to system fonts to avoid external resource fetches from the email client.
5. Avoid showing full recipient email addresses in mass emails. Show a partially redacted email (e.g., j***@domain.com) or otherwise minimize PII exposure. If you must include the email, ensure consent and consider logging/auditing access.

🟡 packages/email/lib/weekly-task-digest.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation for email, userName, organizationName, organizationId, tasks	MEDIUM
2	No email format validation; risk of email header injection via 'to' or 'subject'	MEDIUM
3	Unsanitized user data passed to email template; potential HTML/template injection	MEDIUM

Recommendations:

1. Add server-side validation for all inputs (email, userName, organizationName, organizationId, tasks). Enforce types and reasonable constraints (e.g., non-empty strings, max lengths).
2. Validate the email address with a well-tested library (e.g., validator.js isEmail) and strip CR and LF characters from email/subject values before passing them to the mailer to prevent header injection: e.g., email = email.replace(/[\r\n]/g, ''), subject = subject.replace(/[\r\n]/g, '').
3. Limit tasks array size (e.g., max number of tasks) and enforce a maximum length for task.title and other string fields to avoid large payloads or resource exhaustion.
4. Ensure the email rendering pipeline safely escapes user-provided values. If using React for email templates, verify templates do not use dangerouslySetInnerHTML with untrusted data. Prefer automatic escaping or explicit HTML sanitization (e.g., DOMPurify) when inserting HTML fragments.
5. Centralize input validation/sanitization in the sendEmail path (or earlier) so all callers benefit from the same protections.
6. Add monitoring and logging for send failures, and apply rate limiting on sending emails to prevent abuse.
7. Add unit tests that assert CRLFs are removed and that long/invalid inputs are rejected, and perform threat-modeling for email content generation.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade the ai dependency to >=5.0.52 in package.json and rebuild so the patched library is used by the codebase.
2. Add server-side file validation beyond the SDK whitelist: verify MIME type and extension, and validate file magic bytes (file signatures) before accepting or processing uploads in code that handles incoming files.
3. Do not rely solely on the SDK's client-side checks: enforce server-side checks where uploads are handled (reject mismatches between declared type and content, apply size limits, and sanitize any downstream handling of file content).

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 7, 2025

[claudfuen]

🎉 This PR is included in version 1.57.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀