Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Reused Component Instances Retain Stale Render Context Summary ViewComponent::Base instances retain multiple render-scoped objects across calls to renderin. If the same component, collection, or spacer component instance is reused across requests, users, tenants, or threads, later renders can use stale helpers, controller, request, viewflow, format/variant details, and slot child context from an earlier render. This can cause authorization-aware components to render privileged UI for a lower-privileged user, generate links using a stale Host header, leak slot/helper state, and mix request context under concurrent rendering. Severity The PoC demonstrates cross-user authorization impact in a realistic downstream application pattern. If the receiving program accepts downstream cross-user authorization impact as a scope-changing impact for a framework vulnerability, an alternative High score can be assigned: Alternative CVSS: 8.2 Alternative vector:…
Recommended action: Upgrade to 4.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ViewComponent::Base#aroundrender can return HTML-unsafe strings that bypass the escaping behavior applied to normal #call return values. This creates an XSS risk when downstream applications use aroundrender to wrap, replace, instrument, or conditionally return content that includes user-controlled data. The issue is especially dangerous in collection rendering because ViewComponent::Collection#renderin joins the per-item results and marks the entire output as htmlsafe, converting raw unsafe output into a trusted ActiveSupport::SafeBuffer. Affected Code Validated against: - Repository commit: eea79445 - Ruby: 3.4.9 Relevant locations: - lib/viewcomponent/base.rb - renderin - aroundrender - vcmaybeescapehtml - lib/viewcomponent/template.rb - InlineCall#safemethodnamecall - lib/viewcomponent/collection.rb - Collection#renderin Key code paths: Root Cause Normal inline #call output is passed through vcmaybeescapehtml, which escapes HTML-unsafe strings. However, when aroundrender…
Recommended action: Upgrade to 4.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The system test entrypoint canonicalizes a user-controlled file path with File.realpath, then checks whether the resolved path starts with the temp directory path. This is not a safe containment check because sibling directories can share the same string prefix. Severity: Medium; test-route scoped. Example: The outside path is not inside the base directory, but it passes: Relevant Code app/controllers/viewcomponentssystemtestcontroller.rb: The route then renders the resolved file: Exploit Flow Example request: Flow: 1. basepath resolves to .../tmp/viewcomponents. 2. The payload resolves to .../tmp/viewcomponentsevil/secret.html.erb. 3. That path is outside the intended temp directory. 4. The string prefix check still passes. 5. Rails renders the sibling file. The route is mounted only in Rails.env.test?, which is why Medium is more appropriate than P1. The issue matters if test routes are reachable in shared CI, staging, review apps, or any accidentally exposed test-mode…
Recommended action: Upgrade to 4.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The preview route derives an example name from the URL and calls it with publicsend. The code does not verify that the requested method is one of the preview examples explicitly defined by the preview class. As a result, inherited public methods on ViewComponent::Preview are route-reachable. The most important one is renderwithtemplate, which accepts template: and locals:. Those values can come from request params and are later passed to Rails as render template:. If previews are exposed, an attacker can render internal Rails templates that are not otherwise routable. Severity: High if preview routes are externally reachable; Medium otherwise. Affected files: - lib/viewcomponent/preview.rb - app/controllers/concerns/viewcomponent/previewactions.rb - app/views/viewcomponents/preview.html.erb Relevant Code app/controllers/concerns/viewcomponent/previewactions.rb: lib/viewcomponent/preview.rb: app/views/viewcomponents/preview.html.erb: The UI only lists direct preview methods…
Recommended action: Upgrade to 4.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? This is an XSS vulnerability that has the potential to impact anyone rendering a component directly from a controller with the viewcomponent gem. Note that only components that define a #call method (i.e. instead of using a sidecar template) are affected. The return value of the #call method is not sanitized and can include user-defined content. In addition, the return value of the #outputpostamble method is not sanitized, which can also lead to XSS issues. Patches Has the problem been patched? What versions should users upgrade to? Versions 3.9.0 has been released and fully mitigates both the #call and the #outputpostamble vulnerabilities. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Sanitize the return value of #call, eg: References Are there any links users can visit to find out more? https://github.com/ViewComponent/viewcomponent/pull/1950 For more information If you have…
Recommended action: Upgrade to 3.9.0 or 2.83.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an XSS vulnerability that has the potential to impact anyone using translations with the viewcomponent gem. Data received via user input and passed as an interpolation argument to the translate method is not properly sanitized before display. Versions 2.29.1 and 2.49.1 have been released and fully mitigate the vulnerability. Avoid passing user input to the translate function, or sanitize the inputs before passing them. For more information If you have any questions or comments about this advisory: Open an issue in the github/viewcomponent project
Recommended action: Upgrade to 2.49.1 or 2.31.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.