deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 1.5.0, < 1.5.3
Patched in: 1.5.3

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 1.6.0, < 1.6.3
Patched in: 1.6.3

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 1.7.0, < 1.7.2
Patched in: 1.7.2

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 1.8.0, < 1.8.3
Patched in: 1.8.3

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 1.9.0, < 1.9.2
Patched in: 1.9.2

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: = 1.10.0
Patched in: 1.10.1

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
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:`.

### 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### 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.
GitHub Security Advisory: GHSA-5xv2-q475-rwrh
Package: katello (RUBYGEMS)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: >= 1.1.0, < 1.1.7
Patched in: 1.1.7

Summary: Katello uses hard coded credential

Details:
The installation script in Katello 1.0 and earlier does not properly generate the `Application.config.secret_token` value, which causes each default installation to have the same secret token, and allows remote attackers to authenticate to the CloudForms System Engine web interface as an arbitrary user by creating a cookie using the default `secret_token`.
GitHub Security Advisory: GHSA-5xv2-q475-rwrh
Package: katello (RUBYGEMS)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: < 1.0.6
Patched in: 1.0.6

Summary: Katello uses hard coded credential

Details:
The installation script in Katello 1.0 and earlier does not properly generate the `Application.config.secret_token` value, which causes each default installation to have the same secret token, and allows remote attackers to authenticate to the CloudForms System Engine web interface as an arbitrary user by creating a cookie using the default `secret_token`.
GitHub Security Advisory: GHSA-vfmv-jfc5-pjjw
Package: carrierwave (RUBYGEMS)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-436: Interpretation Conflict
Vulnerable versions: < 2.2.6
Patched in: 2.2.6

Summary: CarrierWave content-Type allowlist bypass vulnerability which possibly leads to XSS remained

Details:
### Impact
The vulnerability [CVE-2023-49090](https://github.com/carrierwaveuploader/carrierwave/security/advisories/GHSA-gxhx-g4fq-49hj) wasn't fully addressed.

This vulnerability is caused by the fact that when uploading to object storage, including Amazon S3, it is possible to set a Content-Type value that is interpreted by browsers to be different from what's allowed by `content_type_allowlist`, by providing multiple values separated by commas.

This bypassed value can be used to cause XSS.

### Patches
Upgrade to [3.0.7](https://rubygems.org/gems/carrierwave/versions/3.0.7) or [2.2.6](https://rubygems.org/gems/carrierwave/versions/2.2.6).

### Workarounds
Use the following monkey patch to let CarrierWave parse the Content-type by using `Marcel::MimeType.for`.

```ruby
# For CarrierWave 3.x
CarrierWave::SanitizedFile.class_eval do
  def declared_content_type
    @declared_content_type ||
      if @file.respond_to?(:content_type) && @file.content_type
        Marcel::MimeType.for(declared_type: @file.content_type.to_s.chomp)
      end
  end
end
```

```ruby
# For CarrierWave 2.x
CarrierWave::SanitizedFile.class_eval do
  def existing_content_type
    if @file.respond_to?(:content_type) && @file.content_type
      Marcel::MimeType.for(declared_type: @file.content_type.to_s.chomp)
    end
  end
end
```

### References
[OWASP - File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html#content-type-validation)
GitHub Security Advisory: GHSA-vfmv-jfc5-pjjw
Package: carrierwave (RUBYGEMS)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-436: Interpretation Conflict
Vulnerable versions: >= 3.0.0, < 3.0.7
Patched in: 3.0.7

Summary: CarrierWave content-Type allowlist bypass vulnerability which possibly leads to XSS remained

Details:
### Impact
The vulnerability [CVE-2023-49090](https://github.com/carrierwaveuploader/carrierwave/security/advisories/GHSA-gxhx-g4fq-49hj) wasn't fully addressed.

This vulnerability is caused by the fact that when uploading to object storage, including Amazon S3, it is possible to set a Content-Type value that is interpreted by browsers to be different from what's allowed by `content_type_allowlist`, by providing multiple values separated by commas.

This bypassed value can be used to cause XSS.

### Patches
Upgrade to [3.0.7](https://rubygems.org/gems/carrierwave/versions/3.0.7) or [2.2.6](https://rubygems.org/gems/carrierwave/versions/2.2.6).

### Workarounds
Use the following monkey patch to let CarrierWave parse the Content-type by using `Marcel::MimeType.for`.

```ruby
# For CarrierWave 3.x
CarrierWave::SanitizedFile.class_eval do
  def declared_content_type
    @declared_content_type ||
      if @file.respond_to?(:content_type) && @file.content_type
        Marcel::MimeType.for(declared_type: @file.content_type.to_s.chomp)
      end
  end
end
```

```ruby
# For CarrierWave 2.x
CarrierWave::SanitizedFile.class_eval do
  def existing_content_type
    if @file.respond_to?(:content_type) && @file.content_type
      Marcel::MimeType.for(declared_type: @file.content_type.to_s.chomp)
    end
  end
end
```

### References
[OWASP - File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html#content-type-validation)
GitHub Security Advisory: GHSA-592j-995h-p23j
Package: rdoc (RUBYGEMS)
Severity: LOW (CVSS 4.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 6.6.0, < 6.6.3.1
Patched in: 6.6.3.1

Summary: RDoc RCE vulnerability with .rdoc_options

Details:
An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0.

When parsing `.rdoc_options` (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored.

When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache.

We recommend to update the RDoc gem to version 6.6.3.1 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.0 users: Update to `rdoc` 6.3.4.1
* For Ruby 3.1 users: Update to `rdoc` 6.4.1.1
* For Ruby 3.2 users: Update to `rdoc` 6.5.1.1

You can use `gem update rdoc` to update it. If you are using bundler, please add `gem "rdoc", ">= 6.6.3.1"` to your `Gemfile`.

Note: 6.3.4, 6.4.1, 6.5.1 and 6.6.3 have a incorrect fix. We recommend to upgrade 6.3.4.1, 6.4.1.1, 6.5.1.1 and 6.6.3.1 instead of them.
GitHub Security Advisory: GHSA-592j-995h-p23j
Package: rdoc (RUBYGEMS)
Severity: LOW (CVSS 4.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 6.5.0, < 6.5.1.1
Patched in: 6.5.1.1

Summary: RDoc RCE vulnerability with .rdoc_options

Details:
An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0.

When parsing `.rdoc_options` (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored.

When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache.

We recommend to update the RDoc gem to version 6.6.3.1 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.0 users: Update to `rdoc` 6.3.4.1
* For Ruby 3.1 users: Update to `rdoc` 6.4.1.1
* For Ruby 3.2 users: Update to `rdoc` 6.5.1.1

You can use `gem update rdoc` to update it. If you are using bundler, please add `gem "rdoc", ">= 6.6.3.1"` to your `Gemfile`.

Note: 6.3.4, 6.4.1, 6.5.1 and 6.6.3 have a incorrect fix. We recommend to upgrade 6.3.4.1, 6.4.1.1, 6.5.1.1 and 6.6.3.1 instead of them.
GitHub Security Advisory: GHSA-592j-995h-p23j
Package: rdoc (RUBYGEMS)
Severity: LOW (CVSS 4.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 6.4.0, < 6.4.1.1
Patched in: 6.4.1.1

Summary: RDoc RCE vulnerability with .rdoc_options

Details:
An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0.

When parsing `.rdoc_options` (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored.

When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache.

We recommend to update the RDoc gem to version 6.6.3.1 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.0 users: Update to `rdoc` 6.3.4.1
* For Ruby 3.1 users: Update to `rdoc` 6.4.1.1
* For Ruby 3.2 users: Update to `rdoc` 6.5.1.1

You can use `gem update rdoc` to update it. If you are using bundler, please add `gem "rdoc", ">= 6.6.3.1"` to your `Gemfile`.

Note: 6.3.4, 6.4.1, 6.5.1 and 6.6.3 have a incorrect fix. We recommend to upgrade 6.3.4.1, 6.4.1.1, 6.5.1.1 and 6.6.3.1 instead of them.
GitHub Security Advisory: GHSA-v5h6-c2hv-hv3r
Package: stringio (RUBYGEMS)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), CWE-126: Buffer Over-read
Vulnerable versions: < 3.0.1.1
Patched in: 3.0.1.1

Summary: StringIO buffer overread vulnerability

Details:
An issue was discovered in StringIO 3.0.1, as distributed in Ruby 3.0.x through 3.0.6 and 3.1.x through 3.1.4.

The `ungetbyte` and `ungetc` methods on a StringIO can read past the end of a string, and a subsequent call to `StringIO.gets` may return the memory value.

This vulnerability is not affected StringIO 3.0.3 and later, and Ruby 3.2.x and later.

We recommend to update the StringIO gem to version 3.0.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.0 users: Update to `stringio` 3.0.1.1
* For Ruby 3.1 users: Update to `stringio` 3.1.0.2

You can use `gem update stringio` to update it. If you are using bundler, please add `gem "stringio", ">= 3.0.1.2"` to your `Gemfile`.
GitHub Security Advisory: GHSA-9822-6m93-xqf4
Package: rails (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 7.1.0, < 7.1.3.1
Patched in: 7.1.3.1

Summary: Rails has possible XSS Vulnerability in Action Controller

Details:
# Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(`translate`, `t`, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected:  >= 7.0.0.
Not affected:       < 7.0.0
Fixed Versions:     7.1.3.1, 7.0.8.1

Impact
------
Applications using translation methods like `translate`, or `t` on a
controller, with a key ending in "_html", a `:default` key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

```ruby
class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end
```

To reiterate the pre-conditions, applications must:

* Use a translation function from a controller (i.e. _not_ I18n.t, or `t` from
  a view)
* Use a key that ends in `_html`
* Use a default value where the default value is untrusted and unescaped input
* Send the text to the victim (whether that's part of a template, or a
  `render` call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases
--------
The fixed releases are available at the normal locations.

Workarounds
-----------
There are no feasible workarounds for this issue.

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

*  7-0-translate-xss.patch - Patch for 7.0 series
*  7-1-translate-xss.patch - Patch for 7.1 series

Credits
-------

Thanks to [ooooooo_q](https://hackerone.com/ooooooo_q) for the patch and fix!