Description

jshERP through 3.6 contains an information disclosure vulnerability that allows any authenticated user to read platform-wide configuration secrets via the getInfoByKey handler of PlatformConfigController. Low-privilege users of any tenant can request arbitrary platformKey values such as email_auth_code or activation_code to obtain SMTP authorization codes and activation secrets, because only aliOss and weixin keys are blocked.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-12T13:17:32.173Z",
  "pubdate": "2026-10-12T13:17:32.173Z",
  "executiveSummary": "The jshERP platform, in versions through 3.6, suffers from an improper access control vulnerability within its configuration management subsystem.\nThis vulnerability is classified as an information disclosure flaw, enabling authenticated, low-privilege users to exfiltrate sensitive platform-wide configuration secrets.\nThe issue resides in the 'getInfoByKey' handler of the 'PlatformConfigController', which fails to implement adequate authorization checks for requested configuration keys.\nBy manipulating requests to the application, an attacker can retrieve highly sensitive information, such as SMTP authorization credentials ('email_auth_code') and system activation secrets ('activation_code').\nThis flaw poses significant risk, as the leaked secrets may facilitate further attacks, including unauthorized email relay, system impersonation, or compromise of integrated third-party services.\nSuccessful exploitation requires minimal privileges; the attacker must be a legitimately authenticated user within any tenant of the affected jshERP system to trigger the vulnerable functionality.",
  "technicalDetails": "The vulnerability is localized within the 'PlatformConfigController' component of jshERP, specifically in the logic handling the 'getInfoByKey' function.\nRoot Cause Analysis: The application employs an insecure allow-list mechanism that restricts access to only a subset of configuration keys (specifically 'aliOss' and 'weixin'). However, the implementation fails to enforce a 'deny-by-default' posture for all other keys, effectively treating all unspecified keys as publicly readable by any authenticated user.\nExploitation Method: An attacker with valid, low-privileged credentials can invoke the 'getInfoByKey' handler by supplying an arbitrary 'platformKey' parameter. Due to the incomplete filtering logic, the application processes the request and returns the requested configuration value from the backend database or configuration store.\nAttack Flow: 1. The attacker authenticates as a low-privileged user within any tenant. 2. The attacker crafts an HTTP request directed at the 'PlatformConfigController' targeting the 'getInfoByKey' endpoint. 3. The attacker passes a targeted 'platformKey' (e.g., 'email_auth_code') as a query parameter. 4. The server-side logic fails to validate if the authenticated user has authorization to access the requested key, skipping only the explicitly blocked 'aliOss' and 'weixin' keys. 5. The application returns the plaintext value of the requested configuration key in the response body.\nImpact: The exposure of 'email_auth_code' allows an attacker to gain unauthorized access to the configured SMTP server, enabling phishing, spam, or credential harvesting via the platform's email features. Access to 'activation_code' or other system-level secrets may allow an attacker to bypass licensing restrictions or gain elevated control over the application's configuration state, leading to full system compromise depending on the sensitivity of the stored secrets.\nAffected Versions: jshERP versions up to and including 3.6 are impacted by this security flaw. The lack of granular, role-based access control (RBAC) on the 'PlatformConfigController' ensures that even the lowest privilege level is sufficient to query the application's sensitive backend configurations."
}