Wormable widget XSS shows the risk in multi-tenant platforms

At a glance

What this is: Sprocket Security shows that widget-based XSS in multi-tenant platforms can become wormable when injected JavaScript runs with session context and authenticated API access.

Why it matters: IAM, PAM, and platform security teams need to treat extensibility surfaces as governed execution environments, because editor access can become tenant-wide propagation once widgets can modify other applications.

Context

Multi-tenant platforms that let users add custom widgets are not just rendering content. They are also granting execution privileges, often inside a rich session context that can read data and call authenticated APIs. That changes the risk profile from ordinary stored XSS to a platform-level control problem where the feature itself becomes the delivery mechanism.

The security issue here is the overlap between untrusted code, tenant-scoped management APIs, and overbroad widget privileges. Where a platform allows one tenant user to modify multiple applications, a malicious widget can move from one app to the rest of the tenant without needing a separate breach of each target. That makes application extensibility a governance issue, not only a code review issue.

For practitioners, this is a reminder that edit rights, session scope, and cross-application permissions are part of the attack surface. The starting position described in the article is not unusual for modern SaaS design, which is why the failure mode deserves architectural scrutiny rather than point fixes.

Key questions

Q: What breaks when custom widgets can execute arbitrary JavaScript in multi-tenant platforms?

A: The control boundary breaks when widget code is treated as configuration but executes as application logic. In that model, a single injection point can read session data, call authenticated APIs, and persist across multiple applications. The failure is not just XSS, it is executable tenant authority with no meaningful separation between content and control.

Q: Why do authenticated widget sessions create such a large propagation risk?

A: Because the payload can use the victim’s own permissions to enumerate applications, write new widget objects, and replicate itself without stealing separate credentials. That makes tenant-scoped write access the key risk multiplier. The more applications one session can modify, the larger the blast radius becomes.

Q: How can security teams tell whether widget abuse is being hidden inside normal activity?

A: Look for hidden or zero-height widgets, unusual widget names, repeated marker patterns, and unexpected writes to layout or application-definition APIs. Those signals suggest the payload is using legitimate management paths rather than obvious exploit traffic. Review logs for edit actions that do not match normal dashboard administration.

Q: Should organisations separate widget editing from tenant administration?

A: Yes. If the same identity can author executable widgets, approve them, and push them across multiple applications, the platform has collapsed development, deployment, and operational privilege into one path. Separating those duties reduces the chance that a malicious or compromised editor can turn a single widget into tenant-wide persistence.

Technical breakdown

Why custom widgets become execution surfaces

A custom widget framework becomes risky when it allows stored code to execute as part of the application runtime rather than as inert configuration. In the article’s example, widget definitions contain JavaScript modules that are dynamically imported and run with access to record data, DOM objects, and the user session. That is materially different from ordinary reflected XSS, because the platform is intentionally treating user-supplied widget code as executable application logic. Once that design exists, the security boundary shifts from input validation to code governance, privilege segmentation, and runtime isolation.

Practical implication: Treat widget code as governed software, not user content, and separate approved execution from editable configuration.

How authenticated API access turns XSS into a worm

The propagation risk comes from the widget runtime inheriting authenticated access to management APIs. If the malicious code can list applications, read layouts, and write new widget definitions through the victim’s session, then every successful render becomes a replication event. This is why the attack is wormable: the payload does not rely on a single user action after initial injection. It uses normal tenant operations to discover targets, avoid re-infection, and write itself into other applications where the victim already has edit permissions.

Practical implication: Remove management API access from widget contexts and segment write operations away from runtime code paths.

Why traditional XSS controls fail in rich widget frameworks

Classic defenses such as output encoding and generic CSP are weak against platforms whose legitimate function is to execute stored JavaScript. The issue is not merely unsanitized input. The issue is that the platform design assumes trusted code execution inside a shared runtime, often with cross-application permissions and invisible placement options. When code is allowed to manipulate layouts, hide itself with zero-height widgets, and persist through session reuse, the attacker can blend into ordinary application behaviour while maintaining control over the infected tenant surface.

Practical implication: Use sandboxed execution, code allowlisting, and layout permission boundaries instead of relying on input filters alone.

Threat narrative

Attacker objective: The attacker aims to turn one editable widget into a persistent, self-replicating foothold that exfiltrates data and spreads across every application the victim can modify.

1. Entry occurs when malicious JavaScript is inserted into a custom widget definition and stored by the platform through an authenticated write path.
2. Credential and privilege abuse follow because the widget runs inside the victim’s session with access to tenant management APIs and application layouts.
3. The payload then enumerates other editable applications, writes copies of itself into clean layouts, and uses marker checks to avoid re-infection.
4. Impact is tenant-wide persistence, data exfiltration, and lateral spread through legitimate application modification rights.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Wormable widget XSS is an identity governance problem, not just a web flaw. Once widget code runs with the victim’s authenticated session and application edit rights, the security boundary is no longer the browser. The practical control question becomes who can deploy executable configuration, what that code can reach, and how far a session can write across the tenant. For identity teams, this is a governance issue over delegated application authority.

Custom widget frameworks create privilege propagation paths that conventional XSS thinking misses. Stored JavaScript is dangerous on its own, but the real escalation comes from combining execution context with authenticated management APIs. That intersection makes the platform’s own permission model the carrier for lateral spread. Practitioners should recognise this as a standing-privilege problem inside application extensibility, not a simple content-sanitisation gap.

Widget allowlisting is the right named concept for this risk class. The article shows why ad hoc validation is not enough when executable UI components are also cross-tenant control surfaces. Allowlisting approved widget code, separating build from deploy rights, and constraining runtime APIs are the governance moves that matter most. Without those controls, the platform is effectively authorising code to inherit tenant power.

Invisible placement techniques show how abuse hides inside normal operational noise. Zero-height widgets, marker-based reinfection checks, and randomised naming are not just malware tricks. They reveal that audit trails and UI reviews can be poor indicators of safety when the payload lives inside legitimate configuration channels. Security programmes need stronger provenance and runtime segregation for editable components.

The broader market signal is that extensibility and security are converging. SaaS platforms increasingly expose rich customisation, but every extra execution hook widens the trust boundary. That means identity and platform security teams have to evaluate not only who can use the application, but who can author active behaviour inside it. The governance answer is to narrow execution rights before attackers turn flexibility into propagation.

What this signals

Widget allowlisting should be treated as a governance control, not a developer convenience. If the platform is permitted to execute code from layout objects, then the code itself needs provenance, review, and deployment boundaries. That changes the control discussion from filtering inputs to governing who can publish active behaviour inside the tenant.

Cross-application edit rights create the blast radius, not just the vulnerability. The article’s worm spreads because authenticated users can modify more than one application, so the exploit path is already embedded in normal operational permissions. Practitioners should map those rights carefully and reduce them wherever a single editor does not need tenant-wide write reach.

Session context is the hidden identity layer in extensible SaaS. When custom widgets inherit the user’s authenticated state, the application runtime becomes part of identity governance. Teams should assume that any executable configuration with session access can act as the user until proven otherwise, and design isolation around that assumption.

For practitioners

• Implement widget code allowlisting Only permit approved widget hashes or signed modules to run in production, and block direct execution of arbitrary JavaScript from stored layout objects.
• Split widget authoring from deployment Separate developers who create widget code from administrators who approve and publish it, so a single tenant editor cannot both inject and propagate code.
• Remove management API access from runtime widgets Scope widget runtime permissions to read-only data and explicitly deny application, layout, user, and permission management endpoints from the widget context.
• Sandbox widget execution in an isolated frame Run custom widgets in a sandboxed iframe or equivalent isolation boundary so injected code cannot inherit the parent session or manipulate tenant-wide state.
• Review edit rights across all tenant applications Audit which identities can modify multiple applications and remove broad cross-application write access where the business case does not require it.

Key takeaways

• Multi-tenant widget frameworks can turn stored JavaScript into a self-propagating attack path when executable code inherits session context and authenticated API access.
• The article shows that a single infected widget can spread across every application a user can edit, which makes tenant write permissions a real blast-radius control.
• Architectural controls matter more than input filtering here. Code allowlisting, sandboxing, and API segmentation are the practical limits on this attack class.

Key terms

• Multi-Tenant SaaS Platform: A multi-tenant SaaS platform is a cloud application where many customers use the same underlying software service. Each tenant’s data, settings, and access controls are logically separated within shared infrastructure, so the provider can operate one platform while preserving customer isolation, governance, and security boundaries.
• Widget Execution Context: Widget execution context is the set of privileges, data objects, and browser capabilities available when a widget runs. In this article’s pattern, that context includes authenticated session access, record data, and the ability to call management APIs, which turns display logic into a control surface.
• Code Allowlisting: Code allowlisting is a control pattern where only approved, signed, or hashed code is allowed to execute. It is stronger than trying to block bad input after the fact because it defines what is permitted, which is crucial when a platform intentionally runs user-supplied widget logic.
• Tenant Blast Radius: Tenant blast radius is the amount of data, functionality, or application surface an attacker can reach after compromising one identity or one component. In extensible SaaS, it is shaped by edit rights, runtime privilege, and whether management APIs are reachable from user-executed code.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security decisions that shape blast radius and trust boundaries.