Dev installs can route auth mail into an unauthenticated /dev/mailbox — detect it and offer the integration send path instead

[timujinne]

Raised from a security review of a real PhoenixKit deployment on 2026-08-07. Nothing here is exploitable in that particular install today — the operator had already moved sending to a configured integration, which is exactly the mitigation this issue proposes making a first-class option. It is filed because the default shape is unsafe and the framework already has most of the pieces to say so.

The shape

mix phx.new generates, in dev.exs, a mailer on Swoosh.Adapters.Local, and in the router:

if Application.compile_env(:my_app, :dev_routes) do
  scope "/dev" do
    pipe_through :browser
    forward "/mailbox", Plug.Swoosh.MailboxPreview
  end
end

No authentication, by design — it is a developer convenience. PhoenixKit then delivers password-reset, magic-link, email-confirmation, email-change and invitation mail through that mailer. Those messages carry single-use tokens that exist nowhere else: core stores only a SHA-256 hash, so the raw token lives exclusively in the message.

The consequence is a three-request account takeover for anyone who can reach the dev server:

1. POST /users/reset-password with any address — the page is public and rate-limited per address, which does not impede one targeted reset.
2. The mail is stored in the in-memory mailbox instead of being sent.
3. GET /dev/mailbox — anonymous — read the link, follow it, set a password.

Picking the Owner yields the whole application. POST /dev/mailbox/clear then removes the evidence.

"It's only dev" is doing a lot of work in that sentence. Dev servers routinely bind 0.0.0.0, sit on a shared container network, and answer on a real hostname behind a proxy — and they hold real data far more often than anyone plans.

Two gaps in what PhoenixKit already has

1. PhoenixKit.Config.mailer_local?/0 misses the common wiring.

def mailer_local? do
  case get(PhoenixKit.Mailer, nil)[:adapter] do
    Swoosh.Adapters.Local -> true
    _ -> false
  end
end

It inspects config :phoenix_kit, PhoenixKit.Mailer only. In delegation mode — config :phoenix_kit, mailer: MyApp.Mailer, which PhoenixKit.Mailer's own moduledoc documents and which host apps generally use — the host's adapter is invisible to it. So on a host that delegates to a Swoosh.Adapters.Local mailer, mailer_local?/0 returns false while every message really does land in the local mailbox. I confirmed this on a live install: Application.get_env(:phoenix_kit, PhoenixKit.Mailer) is nil, the host mailer's adapter is Swoosh.Adapters.Local, and the helper answers false.

It also does not account for default_email_integration_uuid, which takes precedence over both mailers in deliver_email/2.

2. When it does fire, the response points people at the mailbox.

PhoenixKitWeb.Components.Core.DevNotice renders, on the public login / registration / forgot-password / magic-link pages:

Development mode: Check mailbox for reset emails

That is a helpful signpost for a developer and a map for everyone else — rendered to anonymous visitors, on the exact pages used to trigger the mail. What is missing is any signal aimed at the operator that the inbox has no authentication.

Proposal

1. Make mailer_local?/0 reflect what will actually send. Resolve it the way deliver_email/2 does — default send integration, then the delegated host mailer, then the built-in one — so delegation and the integration override are both accounted for. This is a small fix and everything below depends on it.

2. Warn at install and doctor time. mix phoenix_kit.install and mix phoenix_kit.doctor can see the resolved adapter, and can scan the host router's routes for Plug.Swoosh.MailboxPreview (Phoenix.Router.routes/1) and check whether its pipeline carries any authentication. When mail is local and the preview is unauthenticated, say so in one sentence with the consequence spelled out — "password-reset links for every account are readable at /dev/mailbox by anyone who can reach this server" — rather than a generic note.

3. Offer the integration send path as an install option. PhoenixKit already ships the Integrations system with SMTP / SES / Brevo providers and default_email_integration_uuid; a dev install pointed at a local catch-all SMTP (Mailpit, Mailhog, smtp4dev) gets the same convenience with none of the tokens-in-a-public-web-page property. Offering this during phoenix_kit.install — "how should development mail be delivered?" — puts the decision in front of the operator once, at the moment they can act on it.

4. Reconsider the DevNotice link. Keeping the notice while dropping the anchor, or rendering the link only when the preview route is behind a pipeline, would stop the framework advertising an unauthenticated inbox on its own public pages.

Happy to open a PR for (1) and (2) if the direction is agreeable — (3) is a larger design question about what phoenix_kit.install should ask.

[ddon]

Re-verified all four items against main at b3ef57b2 (post-#688, post-#689). All four are still open — nothing here has been addressed, and neither #686 nor #689 touched any of it. #686 was a different batch (OAuth, sessions, permissions, user forms) and never opened config.ex or dev_notice.ex; #689 was migrations.

Item 1 — mailer_local?/0

Still byte-for-byte the code quoted above, lib/phoenix_kit/config/config.ex:346:

def mailer_local? do
  case get(PhoenixKit.Mailer, nil)[:adapter] do
    Swoosh.Adapters.Local -> true
    _ -> false
  end
end

Meanwhile deliver_email/2 (lib/phoenix_kit/mailer.ex:212) resolves in a different order entirely — default send integration, then get_mailer() (i.e. config :phoenix_kit, :mailer → the host mailer), then the built-in one. The helper reads a config key that delivery may never consult. Confirmed.

One thing worth adding: the mismatch cuts both ways. mix phoenix_kit.install writes config :phoenix_kit, PhoenixKit.Mailer, adapter: Swoosh.Adapters.Local into dev.exs (install/mailer_config.ex:106). A host that also sets mailer: MyApp.Mailer pointing at a real adapter therefore gets mailer_local?/0 == true while mail genuinely goes out — a false positive on top of the false negative reported here. Both directions have the same root cause: the helper answers a question about a mailer that may not be the one sending.

Item 4 — the DevNotice link

Still present, components/core/dev_notice.ex:37-41 — <.link href="/dev/mailbox">, rendered to anonymous visitors on the auth pages.

Worth pinning down which installs actually see it, because the two items interact in an unhelpful way: the notice renders on the default installer-driven install, precisely because the installer writes the PhoenixKit.Mailer Local block that makes mailer_local?/0 return true. The installs where it doesn't render are the delegation-mode ones from item 1 — where mail really is landing in the unauthenticated mailbox. So today the framework advertises the inbox on the hosts that configured things the ordinary way, and stays silent on the hosts that are actually blind to the problem. That is backwards, and fixing item 1 fixes the visibility half of item 4 as a side effect.

Items 2 and 3

No reference to Plug.Swoosh.MailboxPreview anywhere in lib/. mix phoenix_kit.doctor is up to 18 checks (the squash added a manifest-repair one) and none inspects the resolved mail adapter. MailerConfig still writes only the Swoosh.Adapters.Local dev block — no integration option is offered at install time.

Suggested sequencing

1. and 4. are small and self-contained, and everything else depends on 1. being right, so they are worth landing on their own even if 2. and 3. wait. 2. needs router introspection (Phoenix.Router.routes/1 plus a pipeline check) and is a genuine piece of work; 3. is the design question about what phoenix_kit.install should ask, and is fine to defer.

Direction looks right to me. Keeping this open.

[timujinne]

Took this into work — PR #697.

The shape differs from the body's item 3 in one deliberate way: no install-time seeding or install-time question. The mailbox becomes a runtime opt-in instead — a dev_mailbox_enabled setting (default off) gates delivery in deliver_email/2 itself; while off, the message body (with its one-time links) goes to the server log with a pointer at the switch, and flows keep returning {:ok, …}. That closes the hole for new installs, for existing installs on upgrade, and for the delegation-mode hosts the installer can never reach — the population item 1 is about.

What the PR covers against this issue's list:

• Item 1 — fixed: mailer_local?/0 now derives from PhoenixKit.Mailer.resolved_send_path/0, which resolves integration → delegated host mailer → built-in, exactly like delivery. Both directions of the mismatch (the false negative here, the false positive from the re-verification above) have regression tests.
• Item 4 — fixed via the truthful render condition plus the "drop the anchor" option: no /dev/mailbox link in either variant.
• Item 3 — superseded: with the gate, the safe default no longer depends on what phoenix_kit.install asks. The integration path on /admin/settings/email-sending remains the recommended way to actually send.
• Item 2 (router introspection in install/doctor) — untouched, stays the follow-up, per the sequencing above.

The accepted cost is the default flip: an upgraded dev install stops filling the mailbox until the switch is flipped. Every suppressed send logs the exact reason and the exact fix, the DevNotice copy changes visibly, and the admin page carries a warning banner while the mailbox is on.