Description

UnoPim versions before 2.0.1 and 2.1.1 trust all connecting clients as proxies and honor the X-Forwarded-Host header without validation, allowing unauthenticated attackers to inject arbitrary origins into admin layout pages. Attackers can set X-Forwarded-Host to redirect JavaScript asset loading to their server, and when responses are cached by shared proxies, subsequent administrators execute attacker-supplied code in their authenticated sessions.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.7",
  "pubDate": "2026-09-29T16:17:06.523Z",
  "pubdate": "2026-09-29T16:17:06.523Z",
  "executiveSummary": "UnoPim versions prior to 2.0.1 and 2.1.1 are susceptible to a critical vulnerability arising from the improper validation of the X-Forwarded-Host HTTP header. The application incorrectly trusts all connecting clients as proxies, allowing unauthenticated attackers to manipulate the host information used to generate administrative layout pages.\nBy injecting arbitrary hostnames into the X-Forwarded-Host header, an attacker can coerce the application into redirecting the loading of JavaScript assets to a remote, attacker-controlled server. This facilitates a form of cross-site scripting (XSS) or supply-chain style injection, where malicious payloads are served directly into the authenticated sessions of administrative users.\nThe risk is significantly amplified in environments utilizing shared caching proxies, as the malicious host-specific responses may be cached and served to subsequent administrative users. This effectively compromises the integrity of the administrative dashboard, leading to unauthorized code execution, potential session hijacking, and the exposure of sensitive PIM (Product Information Management) data. Successful exploitation requires no authentication, making this an highly attractive target for remote attackers seeking to compromise administrative integrity within the UnoPim ecosystem.",
  "technicalDetails": "The vulnerability resides in the application's request handling logic, which unconditionally trusts the X-Forwarded-Host HTTP header provided by the client without verifying the trustworthiness of the source. In standard web architecture, this header is intended to inform the application of the original host requested by the client when passing through a trusted reverse proxy. However, UnoPim treats all incoming requests as if they originated from a trusted proxy, failing to sanitize or whitelist the host value.\nThe attack flow begins when an unauthenticated attacker sends a crafted HTTP request to the UnoPim server, including a malicious 'X-Forwarded-Host' header pointing to an external domain under their control. The application processes this header to dynamically construct internal URLs for JavaScript assets within its admin layout pages. Consequently, the HTML rendered by the server includes script tags that reference the attacker-supplied domain rather than the legitimate application server.\nWhen an administrator accesses the affected layout page, their browser attempts to fetch the required JavaScript assets from the attacker's server. The attacker responds with malicious JavaScript designed to execute within the security context of the administrative session. This enables the attacker to perform actions on behalf of the administrator, such as modifying product data, creating new administrative accounts, or exfiltrating sensitive session tokens.\nFurthermore, the impact is compounded by the presence of intermediate caching layers. If a shared proxy caches the response containing the attacker-injected script reference, the malicious payload will be served to subsequent administrators who request the same resource, even if their requests did not include the malicious header. This results in a persistent and widespread compromise of administrative sessions.\nThis vulnerability is present in UnoPim versions before 2.0.1 and 2.1.1. It exploits the application's reliance on client-supplied input for critical infrastructure configuration, namely asset path resolution. Because the application lacks a strict 'Host' header validation mechanism or a defined whitelist of allowed proxy sources, it remains entirely dependent on the integrity of the client request, which is inherently insecure in a public-facing network environment.\nThe post-exploitation impact includes full administrative session compromise, unauthorized modification of PIM data, and the potential for a lateral pivot into the underlying server infrastructure if administrative functionality includes file system or command execution capabilities."
}