Back to site

Security Report

Stephanie Burt Realty Group · July 9, 2026

This report documents three security vulnerabilities identified and remediated in the notifyTeam backend function, which handles lead and appointment notifications via the platform’s Gmail and Slack integrations. All issues listed below have been resolved and verified.

HighResolved

1. MIME Header Injection in Email Notifications

The notifyTeam function inserted user-supplied values (full name and recipient email address) directly into MIME email headers without sanitization. An attacker could embed carriage return (\r) and line feed (\n) characters to inject additional headers such as Bcc, enabling email header injection and potential message redirection.

Fix Applied

Added a sanitizeHeader() utility that strips all CR and LF characters from any value before it is placed into a MIME header. This neutralizes header injection attempts while preserving normal functionality for legitimate submissions.

HighResolved

2. Unauthenticated Access to Connected Gmail and Slack Credentials

The notifyTeam function used the service role (asServiceRole) to retrieve OAuth access tokens for Gmail and Slack without first verifying the caller’s identity. Any unauthenticated party with the endpoint URL could invoke the function and dispatch arbitrary emails and Slack messages using the team’s connected credentials.

Fix Applied

Added an authentication check at the top of the handler using base44.auth.me(). Requests without a valid user session are rejected with HTTP 401 Unauthorized before any connector credentials are accessed or notifications are dispatched.

MediumResolved

3. Notification Content Spoofing via Direct Function Invocation

An authenticated user could bypass the contact and scheduling forms and call notifyTeam directly with arbitrary full_name, email, phone, and message fields. This allowed the submission of spoofed lead or appointment notifications containing attacker-controlled content directly to the administrator’s Gmail inbox and Slack DMs.

Fix Applied

The function now accepts a record ID rather than raw message data. It fetches the stored Lead or Appointment record server-side and sources all notification content from that database record. An ownership check (record.created_by_id === user.id) ensures only the record’s original submitter can trigger a notification for it. Both frontend call sites were updated to pass the created record’s ID.