Package Instance

Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values
During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

Our filter to detect and prevent the use of the `javascript:` URL scheme in the `href` attribute of an `<a>` tag could be bypassed with tab `\t` or newline `\n` characters between the characters of the protocol, e.g. `java\tscript:`.

Phlex vulnerable to Cross-site Scripting (XSS) via maliciously formed HTML attribute names and values
There is a potential cross-site scripting (XSS) vulnerability that
can be exploited via maliciously crafted user data.

The reason these issues were not detected before is the escapes were
working as designed. However, their design didn't take into account
just how recklessly permissive browser are when it comes to executing
unsafe JavaScript via HTML attributes.

### Impact

If you render an `<a>` tag with an `href` attribute set to an
user-provided link, that link could potentially execute JavaScript
when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG
tag, malicious event attributes could be included in the output,
executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches

Patches are [available on RubyGems](https://rubygems.org/gems/phlex)
for all minor versions released in the last year.

- [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2)
- [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3)

If you are on `main`, it has been patched since
[`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2)

### Workarounds

Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)
that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline)
would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly
recommend configuring a Content Security Policy header that does
not allow `unsafe-inline`. Here’s how you can configure a Content
Security Policy header in Rails.
https://guides.rubyonrails.org/security.html#content-security-policy-header

Cross-site Scripting (XSS) possible with maliciously formed HTML attribute names and values in Phlex
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data. This was due to improper case-sensitivity in the code that was meant to prevent these attacks.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all `1.x` minor versions. The patched versions are:

- [1.9.1](https://rubygems.org/gems/phlex/versions/1.9.1)
- [1.8.2](https://rubygems.org/gems/phlex/versions/1.8.2)
- [1.7.1](https://rubygems.org/gems/phlex/versions/1.7.1)
- [1.6.2](https://rubygems.org/gems/phlex/versions/1.6.2)
- [1.5.2](https://rubygems.org/gems/phlex/versions/1.5.2)
- [1.4.1](https://rubygems.org/gems/phlex/versions/1.4.1)
- [1.3.3](https://rubygems.org/gems/phlex/versions/1.3.3)
- [1.2.2](https://rubygems.org/gems/phlex/versions/1.2.2)
- [1.1.1](https://rubygems.org/gems/phlex/versions/1.1.1)
- [1.0.1](https://rubygems.org/gems/phlex/versions/1.0.1)

If you are on `main`, it has been patched since [`aa50c60`](https://github.com/phlex-ruby/phlex/commit/aa50c604cdee1d0ce7ef068a4c66cbd5d43f96a1)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header

Cross-site Scripting (XSS) possible with maliciously formed HTML attribute names and values in Phlex
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data. This was due to improper case-sensitivity in the code that was meant to prevent these attacks.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all `1.x` minor versions. The patched versions are:

- [1.9.1](https://rubygems.org/gems/phlex/versions/1.9.1)
- [1.8.2](https://rubygems.org/gems/phlex/versions/1.8.2)
- [1.7.1](https://rubygems.org/gems/phlex/versions/1.7.1)
- [1.6.2](https://rubygems.org/gems/phlex/versions/1.6.2)
- [1.5.2](https://rubygems.org/gems/phlex/versions/1.5.2)
- [1.4.1](https://rubygems.org/gems/phlex/versions/1.4.1)
- [1.3.3](https://rubygems.org/gems/phlex/versions/1.3.3)
- [1.2.2](https://rubygems.org/gems/phlex/versions/1.2.2)
- [1.1.1](https://rubygems.org/gems/phlex/versions/1.1.1)
- [1.0.1](https://rubygems.org/gems/phlex/versions/1.0.1)

If you are on `main`, it has been patched since [`aa50c60`](https://github.com/phlex-ruby/phlex/commit/aa50c604cdee1d0ce7ef068a4c66cbd5d43f96a1)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header