CVE Vulnerability Catalog

IBM TRIRIGA Application Platform 5.0.0 through 5.0.8 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of file paths during archive extraction.

Frappe ERPNext before 14.92.1 and 15.x before 15.83.0 contains a reflected cross-site scripting vulnerability due to missing input validation on a certain page, allowing arbitrary JavaScript to execute in authenticated sessions. Remote attackers can lure a logged-in user into opening a crafted URL to run injected script and take over the victim's account.

Frappe before 14.81.4 and 15.x before 15.41.0 contains an improper privilege management vulnerability involving a certain document action that permits escalation from the Website User role to System Manager. Authenticated attackers with Website User access can combine this document action with additional steps to obtain administrative System Manager privileges in the Frappe application.

IBM Maximo Application Suite - IoT Component 9.2.0, 9.1.0, and 9.0.0 could allow a remote attacker to cause a denial of service due to uncontrolled recursion.

IBM Maximo AI Service 9.1.0 and 9.2.0 could allow a remote attacker to cause a denial of service due to improper handling of malformed frames, resulting in termination of the host process.

IBM Maximo AI Service 9.1.0 and 9.2.0 SaaS could allow a remote attacker to cause a denial of service due to uncontrolled recursion.

IBM Maximo AI Service 9.1.0 and 9.2.0 could allow a remote attacker to cause a denial of service due to uncontrolled resource consumption.

Nginx UI prior to 2.4.1 uses a constant OAuth state value and does not verify state in CasdoorCallback, allowing an unauthenticated attacker to hijack a user's session.

Code for IBMi prior to 3.0.1 accepts IBMi components without integrity verification, allowing a local account to modify programs and execute them under the connecting user's account.

IBM Power Systems Firmware FW1060.00 through FW1060.81 has a vulnerability in host firmware configuration parsing, allowing an attacker with service access to FSP to cause memory corruption during IPL, compromising boot stack and hypervisor.

IBM Power Systems Firmware FW1060.00 through FW1060.81 has a vulnerability in the service processor mailbox interface, allowing an attacker with service access to FSP to read/write arbitrary Hostboot memory, compromising boot stack and hypervisor.

IBM Power Systems Firmware FW1060.00 through FW1060.81 has a vulnerability in the service processor mailbox interface, allowing an attacker with service access to FSP to overflow host firmware runtime attribute storage, enabling arbitrary code execution in runtime.

IBM Power Systems Firmware FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, and FW1060.00 through FW1060.81 has a vulnerability in the host firmware boot process image validation path, allowing an attacker with service access to supply a malicious code update image, enabling arbitrary code execution on the host.

IBM Power Systems Firmware FW1060.00 through FW1060.81 has a vulnerability in the service processor mailbox interface, allowing an attacker with service access to FSP to overflow host firmware runtime attribute storage, enabling arbitrary code execution in runtime.

IBM Power Systems Firmware FW1060.00 through FW1060.81 is affected by a vulnerability in host firmware configuration parsing. An attacker with authenticated service-level access to the service processor can write specially crafted configuration data, causing the host firmware boot stack to crash with possible memory corruption during system initialisation, resulting in an integrity and availability impact to the managed system.

Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, the HTTP configuration mutation routes require RequireSecureSession, but /mcp and /mcp_message require only ordinary authentication before exposing nginx_config_add and nginx_config_modify. An OTP-enabled user with a normal JWT but no valid X-Secure-Session-ID can therefore create or modify Nginx configuration and trigger reload behavior through MCP, bypassing the intended step-up control. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1 rejects restricted Nginx directives such as load_module, js_import, and js_content in the regular HTTP configuration API. However, the MCP configuration interface allows a secondary authenticated user to write and apply equivalent restricted configuration content. This allows the user to load ngx_http_js_module.so, import attacker-controlled JavaScript, reload Nginx, and execute NJS in the Nginx worker context. This issue is fixed in version 2.4.1.

Nginx UI from 2.0.0-rc.6 until 2.4.1, the MCP tool nginx_config_add writes nginx configuration files to disk and triggers an nginx reload without calling config.ValidateConfigFile. The identical flow in the REST API (POST /api/configs) does call that function and correctly rejects dangerous directives. An authenticated attacker can exploit this gap to write config files containing any blocked directive (perl, js_import, load_module, user root, etc.), bypassing nginx-ui's entire security layer. On a server with the nginx Perl, njs, or Lua module loaded, this is post-authentication Remote Code Execution. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, internal/config/validation.go (ValidateConfigFile) is a security control that blocks dangerous nginx directives — js_*, perl_*, load_module of the njs/perl modules, and user root. It is enforced on three of the four config-write paths: api/config/add.go, api/config/modify.go, and mcp/config/config_modify.go. The fourth path — the MCP tool nginx_config_add (mcp/config/config_add.go) — does NOT call it: it writes the caller-supplied content straight to disk and reloads nginx. An authenticated MCP caller (or an MCP agent induced via prompt injection) can therefore inject exactly the directives the control is meant to block, leading to nginx code execution on deployments where the njs/perl module is available (e.g. the official Docker image). This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, config.ValidateConfigDirectives splits configuration by newline and checks only the first directive token on each line even though Nginx permits multiple semicolon-separated directives on one line. An authenticated caller can place a benign directive first and a restricted load_module, js_import, perl, or user root directive later on the same line, or can use an unrestricted include directive to load restricted content. These mechanisms bypass validation on REST, nginx_config_modify, site, and stream write paths; when an executable module is available, the injected configuration can execute code in the Nginx worker context. This issue is fixed in version 2.4.1.