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:`.

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