[stroland02]

No description provided.

[strix-security]

Strix Security Review

3 open security findings on this PR:

• 🔵 MEDIUM Dashboard agent chat lacks installation entitlement and billing enforcement — packages/dashboard/src/app/api/agents/[id]/chat/route.ts:1-4
• 🔵 MEDIUM Duplicate PR review posting in GitHub installation backfill flow — packages/webhook/src/backfill.ts:1-2
• 🔵 MEDIUM Billing gate bypass in GitHub installation backfill flow — packages/webhook/src/backfill.ts:1-2

Review summary

Reviewed all security-relevant changes in the PR, including the new dashboard API routes, tenancy/auth updates, Synthesizer projection path, and the webhook backfill workflow. Confirmed two medium-severity issues in the newly added code: Billing gate bypass in GitHub installation backfill flow, where the backfill path enqueues review jobs without the billing enforcement present in the normal PR/comment flows, and a dashboard chat entitlement gap that lets any authenticated account proxy prompts to the Python chat model without installation or billing checks. The remaining changed UI and projection code was traced for rendering and tenancy issues, but did not introduce additional confirmed vulnerabilities from the diff.

_{Updated for 2f4eccd.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[strix-security]

Strix flagged 8 new security findings below. See the pinned summary comment for the full PR status.

[strix-security]

🔵 Dashboard agent chat lacks installation entitlement and billing enforcement

Severity: MEDIUM · CWE-862

The new dashboard chat route authorizes any logged-in dashboard account and forwards prompts directly to the Python /chat model without checking whether the caller administers any connected installation or whether that installation is still entitled to consume billable AI features. This bypasses the existing billing gate already enforced for the webhook review-comment chat flow and allows self-registered accounts or billing-blocked tenants to consume model resources through the dashboard.

Suggested change

	import { NextResponse, type NextRequest } from "next/server";
	import { auth } from "@/lib/auth";
	import { AGENTS } from "@/components/dashboard/agents/agent-catalog";
	import { sendAgentChat } from "@/lib/agent-chat";
	import { NextResponse, type NextRequest } from "next/server";
	import { auth } from "@/lib/auth";
	import { db } from "@/lib/db";
	import { AGENTS } from "@/components/dashboard/agents/agent-catalog";
	import { sendAgentChat } from "@/lib/agent-chat";
	import { FREE_TIER_REVIEW_LIMIT } from "@/lib/queries";

Prompt to fix with AI

This is a security vulnerability found during a code review.

Vulnerability: Dashboard agent chat lacks installation entitlement and billing enforcement
Severity: MEDIUM
CWE: CWE-862

The new dashboard chat route authorizes any logged-in dashboard account and forwards prompts directly to the Python `/chat` model without checking whether the caller administers any connected installation or whether that installation is still entitled to consume billable AI features. This bypasses the existing billing gate already enforced for the webhook review-comment chat flow and allows self-registered accounts or billing-blocked tenants to consume model resources through the dashboard.

Location: packages/dashboard/src/app/api/agents/[id]/chat/route.ts:1-4
Context: Add installation and billing imports to the dashboard chat route
```
// Before:
import { NextResponse, type NextRequest } from "next/server";
import { auth } from "@/lib/auth";
import { AGENTS } from "@/components/dashboard/agents/agent-catalog";
import { sendAgentChat } from "@/lib/agent-chat";
// After:
import { NextResponse, type NextRequest } from "next/server";
import { auth } from "@/lib/auth";
import { db } from "@/lib/db";
import { AGENTS } from "@/components/dashboard/agents/agent-catalog";
import { sendAgentChat } from "@/lib/agent-chat";
import { FREE_TIER_REVIEW_LIMIT } from "@/lib/queries";
```

Location: packages/dashboard/src/app/api/agents/[id]/chat/route.ts:20-39
Context: Reject users with no authorized installation and enforce the chat billing gate before proxying to `/chat`
```
// Before:
  const session = await auth();
  if (!session?.user) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const { id } = await ctx.params;
  const agent = AGENTS.find((a) => a.id === id);
  if (!agent) {
    return NextResponse.json({ error: "Unknown agent" }, { status: 400 });
  }

  const body = await req.json().catch(() => ({}));
  const message = typeof body?.message === "string" ? body.message.trim() : "";
  if (!message) {
    return NextResponse.json({ error: "Empty message" }, { status: 400 });
  }

  try {
    const reply = await sendAgentChat({ agent, message });
    return NextResponse.json({ reply });
// After:
  const session = await auth();
  if (!session?.user) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const installationIds = (session.installations ?? []).map((installation) => installation.id);
  if (installationIds.length === 0) {
    return NextResponse.json(
      { error: "Connect an authorized installation before using agent chat." },
      { status: 403 },
    );
  }

  const entitledInstallation = await db.installation.findFirst({
    where: {
      id: { in: installationIds },
      OR: [
        { subscriptionStatus: "active" },
        {
          AND: [
            { subscriptionStatus: { notIn: ["canceled", "past_due"] } },
            { usageCount: { lt: FREE_TIER_REVIEW_LIMIT } },
          ],
        },
      ],
    },
    select: { id: true },
  });
  if (!entitledInstallation) {
    return NextResponse.json(
      { error: "Agent chat is unavailable for this installation's current plan." },
      { status: 403 },
    );
  }

  const { id } = await ctx.params;
  const agent = AGENTS.find((a) => a.id === id);
  if (!agent) {
    return NextResponse.json({ error: "Unknown agent" }, { status: 400 });
  }

  const body = await req.json().catch(() => ({}));
  const message = typeof body?.message === "string" ? body.message.trim() : "";
  if (!message) {
    return NextResponse.json({ error: "Empty message" }, { status: 400 });
  }

  try {
    const reply = await sendAgentChat({ agent, message });
    return NextResponse.json({ reply });
```

How to fix:
Require a repository installation entitlement before proxying dashboard chat requests. The route should reject users with no authorized installations, then enforce the same billing policy already used by the webhook chat flow before calling the Python service. If chat is meant to be scoped to a specific installation, require an `installationId` parameter, verify it belongs to `session.installations`, and evaluate the billing gate against that installation; the UI can then disable the composer when the server would deny access.

Please fix this vulnerability. If you propose a fix, make it concise and minimal.

_{React 👍 / 👎 to tune Strix for this repo. A repo collaborator (or the PR author) can resolve this thread to dismiss the finding.}

[strix-security]

Reject users with no authorized installation and enforce the chat billing gate before proxying to /chat

Suggested change

	const session = await auth();
	if (!session?.user) {
	return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
	}
	const { id } = await ctx.params;
	const agent = AGENTS.find((a) => a.id === id);
	if (!agent) {
	return NextResponse.json({ error: "Unknown agent" }, { status: 400 });
	}
	const body = await req.json().catch(() => ({}));
	const message = typeof body?.message === "string" ? body.message.trim() : "";
	if (!message) {
	return NextResponse.json({ error: "Empty message" }, { status: 400 });
	}
	try {
	const reply = await sendAgentChat({ agent, message });
	return NextResponse.json({ reply });
	const session = await auth();
	if (!session?.user) {
	return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
	}
	const installationIds = (session.installations ?? []).map((installation) => installation.id);
	if (installationIds.length === 0) {
	return NextResponse.json(
	{ error: "Connect an authorized installation before using agent chat." },
	{ status: 403 },
	);
	}
	const entitledInstallation = await db.installation.findFirst({
	where: {
	id: { in: installationIds },
	OR: [
	{ subscriptionStatus: "active" },
	{
	AND: [
	{ subscriptionStatus: { notIn: ["canceled", "past_due"] } },
	{ usageCount: { lt: FREE_TIER_REVIEW_LIMIT } },
	],
	},
	],
	},
	select: { id: true },
	});
	if (!entitledInstallation) {
	return NextResponse.json(
	{ error: "Agent chat is unavailable for this installation's current plan." },
	{ status: 403 },
	);
	}
	const { id } = await ctx.params;
	const agent = AGENTS.find((a) => a.id === id);
	if (!agent) {
	return NextResponse.json({ error: "Unknown agent" }, { status: 400 });
	}
	const body = await req.json().catch(() => ({}));
	const message = typeof body?.message === "string" ? body.message.trim() : "";
	if (!message) {
	return NextResponse.json({ error: "Empty message" }, { status: 400 });
	}
	try {
	const reply = await sendAgentChat({ agent, message });
	return NextResponse.json({ reply });

[strix-security]

🔵 Duplicate PR review posting in GitHub installation backfill flow

Severity: MEDIUM

The new GitHub backfill flow introduced in this PR enqueues review jobs for every open pull request during installation and installation_repositories events without checking whether the same (repository, prNumber, headSha) was already reviewed. Because the queued worker publishes the PR review and check run before persistence rejects duplicates, a redelivered installation event or repeated repository-add event causes duplicate review comments, duplicate check runs, and repeated review-pipeline spend for already-reviewed pull requests.

Suggested change

	import type { Octokit } from '@octokit/core'
	import { enqueueReviewJob } from './queue.js'
	import type { Octokit } from '@octokit/core'
	import { reviewExists } from './persistence.js'
	import { enqueueReviewJob } from './queue.js'

Prompt to fix with AI

This is a security vulnerability found during a code review.

Vulnerability: Duplicate PR review posting in GitHub installation backfill flow
Severity: MEDIUM

The new GitHub backfill flow introduced in this PR enqueues review jobs for every open pull request during `installation` and `installation_repositories` events without checking whether the same `(repository, prNumber, headSha)` was already reviewed. Because the queued worker publishes the PR review and check run before persistence rejects duplicates, a redelivered installation event or repeated repository-add event causes duplicate review comments, duplicate check runs, and repeated review-pipeline spend for already-reviewed pull requests.

Location: packages/webhook/src/backfill.ts:1-2
Context: Add early idempotency import
```
// Before:
import type { Octokit } from '@octokit/core'
import { enqueueReviewJob } from './queue.js'
// After:
import type { Octokit } from '@octokit/core'
import { reviewExists } from './persistence.js'
import { enqueueReviewJob } from './queue.js'
```

Location: packages/webhook/src/backfill.ts:82-95
Context: Skip already-reviewed PRs during backfill
```
// Before:
        const changedFiles = pr.changed_files ?? 0
        const lane = changedFiles > 50 ? 'heavy' : 'fast'

        await enqueueReviewJob({
          provider: 'github',
          kind: 'pull_request',
          owner,
          repo: name,
          repositoryExternalId: repo.id,
          fullName: repo.full_name,
          installationId,
          prNumber: pr.number,
          headSha: pr.head.sha,
        }, lane)
// After:
        const changedFiles = pr.changed_files ?? 0
        const lane = changedFiles > 50 ? 'heavy' : 'fast'
        const alreadyReviewed = await reviewExists({
          provider: 'github',
          repositoryExternalId: repo.id,
          prNumber: pr.number,
          headSha: pr.head.sha,
        })
        if (alreadyReviewed) {
          console.log(
            `[backfill] Review already exists for ${repo.full_name}#${pr.number} @ ${pr.head.sha} — skipping duplicate backfill job`
          )
          continue
        }

        await enqueueReviewJob({
          provider: 'github',
          kind: 'pull_request',
          owner,
          repo: name,
          repositoryExternalId: repo.id,
          fullName: repo.full_name,
          installationId,
          prNumber: pr.number,
          headSha: pr.head.sha,
        }, lane)
```

Location: packages/webhook/src/server.ts:70-78
Context: Installation event reaches vulnerable backfill path
```
    try {
      const { getInstallationOctokit } = await import('./github-auth.js')
      const octokit = await getInstallationOctokit(app, payload.installation.id)
      const { backfillInstallationPRs } = await import('./backfill.js')
      // `repositories` is only present on some installation actions (e.g.
      // 'created'); default to [] so e.g. 'unsuspend' deliveries without it
      // are a no-op rather than a crash.
      const repos = (payload as any).repositories ?? []
      await backfillInstallationPRs(octokit as any, payload.installation.id, repos)
```

Location: packages/webhook/src/server.ts:87-93
Context: Repository-add event reaches vulnerable backfill path
```
  app.webhooks.on('installation_repositories', async ({ payload }) => {
    if (payload.action !== 'added') return
    try {
      const { getInstallationOctokit } = await import('./github-auth.js')
      const octokit = await getInstallationOctokit(app, payload.installation.id)
      const { backfillInstallationPRs } = await import('./backfill.js')
      await backfillInstallationPRs(octokit as any, payload.installation.id, payload.repositories_added as any)
```

How to fix:
Before enqueueing each backfilled pull request, perform the same `(provider, repository external ID, PR number, head SHA)` idempotency check used by the normal `pull_request` webhook path. Skip enqueueing when a matching review already exists so duplicate installation deliveries and repeated repository-add events do not trigger another worker run.

Please fix this vulnerability. If you propose a fix, make it concise and minimal.

_{React 👍 / 👎 to tune Strix for this repo. A repo collaborator (or the PR author) can resolve this thread to dismiss the finding.}

[strix-security]

Skip already-reviewed PRs during backfill

Suggested change

	const changedFiles = pr.changed_files ?? 0
	const lane = changedFiles > 50 ? 'heavy' : 'fast'
	await enqueueReviewJob({
	provider: 'github',
	kind: 'pull_request',
	owner,
	repo: name,
	repositoryExternalId: repo.id,
	fullName: repo.full_name,
	installationId,
	prNumber: pr.number,
	headSha: pr.head.sha,
	}, lane)
	const changedFiles = pr.changed_files ?? 0
	const lane = changedFiles > 50 ? 'heavy' : 'fast'
	const alreadyReviewed = await reviewExists({
	provider: 'github',
	repositoryExternalId: repo.id,
	prNumber: pr.number,
	headSha: pr.head.sha,
	})
	if (alreadyReviewed) {
	console.log(
	`[backfill] Review already exists for ${repo.full_name}#${pr.number} @ ${pr.head.sha} — skipping duplicate backfill job`
	)
	continue
	}
	await enqueueReviewJob({
	provider: 'github',
	kind: 'pull_request',
	owner,
	repo: name,
	repositoryExternalId: repo.id,
	fullName: repo.full_name,
	installationId,
	prNumber: pr.number,
	headSha: pr.head.sha,
	}, lane)

[strix-security]

Installation event reaches vulnerable backfill path

[strix-security]

Repository-add event reaches vulnerable backfill path

[strix-security]

🔵 Billing gate bypass in GitHub installation backfill flow

Severity: MEDIUM · CWE-840

The PR introduces GitHub installation and installation_repositories backfill handlers that enqueue review jobs for every existing open pull request without applying the billing gate used by the normal pull_request and pull_request_review_comment flows. Because the worker posts the review before persistence updates usage and does not re-check billing, a customer with an inactive subscription or an exhausted free tier can reinstall the app or add repositories and still receive LLM-backed reviews.

Suggested change

	import type { Octokit } from '@octokit/core'
	import { enqueueReviewJob } from './queue.js'
	import type { Octokit } from '@octokit/core'
	import { prisma } from './db.js'
	import { evaluateBillingGate } from './billing.js'
	import { enqueueReviewJob } from './queue.js'

Prompt to fix with AI

This is a security vulnerability found during a code review.

Vulnerability: Billing gate bypass in GitHub installation backfill flow
Severity: MEDIUM
CWE: CWE-840

The PR introduces GitHub `installation` and `installation_repositories` backfill handlers that enqueue review jobs for every existing open pull request without applying the billing gate used by the normal `pull_request` and `pull_request_review_comment` flows. Because the worker posts the review before persistence updates usage and does not re-check billing, a customer with an inactive subscription or an exhausted free tier can reinstall the app or add repositories and still receive LLM-backed reviews.

Location: packages/webhook/src/backfill.ts:1-2
Context: Add billing dependencies to the backfill module
```
// Before:
import type { Octokit } from '@octokit/core'
import { enqueueReviewJob } from './queue.js'
// After:
import type { Octokit } from '@octokit/core'
import { prisma } from './db.js'
import { evaluateBillingGate } from './billing.js'
import { enqueueReviewJob } from './queue.js'
```

Location: packages/webhook/src/backfill.ts:58-62
Context: Block installation/repository backfill when billing is not allowed
```
// Before:
export async function backfillInstallationPRs(
  octokit: Octokit,
  installationId: number,
  repos: BackfillRepo[]
): Promise<void> {
// After:
export async function backfillInstallationPRs(
  octokit: Octokit,
  installationId: number,
  repos: BackfillRepo[]
): Promise<void> {
  const installation = await prisma.installation.findUnique({
    where: { provider_externalId: { provider: 'github', externalId: installationId } }
  })
  const gate = evaluateBillingGate(installation)
  if (!gate.allowed) {
    console.log(
      `[backfill] Skipping PR backfill for installation ${installationId} (${gate.reason}). ` +
      `Status: ${installation?.subscriptionStatus}, usage: ${installation?.usageCount}`
    )
    return
  }
```

How to fix:
Apply the same billing decision before any backfill job is enqueued. The simplest fix is to load the installation record inside `backfillInstallationPRs`, evaluate it with the existing billing helper, and return early when the installation is blocked. As defense in depth, keep billing enforcement close to job execution as well so any future alternate enqueue path cannot bypass the check.

Please fix this vulnerability. If you propose a fix, make it concise and minimal.

_{React 👍 / 👎 to tune Strix for this repo. A repo collaborator (or the PR author) can resolve this thread to dismiss the finding.}

[strix-security]

Block installation/repository backfill when billing is not allowed

Suggested change

	export async function backfillInstallationPRs(
	octokit: Octokit,
	installationId: number,
	repos: BackfillRepo[]
	): Promise<void> {
	export async function backfillInstallationPRs(
	octokit: Octokit,
	installationId: number,
	repos: BackfillRepo[]
	): Promise<void> {
	const installation = await prisma.installation.findUnique({
	where: { provider_externalId: { provider: 'github', externalId: installationId } }
	})
	const gate = evaluateBillingGate(installation)
	if (!gate.allowed) {
	console.log(
	`[backfill] Skipping PR backfill for installation ${installationId} (${gate.reason}). ` +
	`Status: ${installation?.subscriptionStatus}, usage: ${installation?.usageCount}`
	)
	return
	}