GPM LIGHT has a Sensitive Data Exposure vulnerability that allows unauthenticated remote access to system logs; the vendor has patched it.
According to a TWCERT/CC announcement, GPM LIGHT (Green Supply Chain Management System), developed by ezGlobal, has a Sensitive Data Exposure vulnerability, identified as TVN-202609010 and corresponding to CVE-2026-97181. The announcement states that unauthenticated remote attackers can directly access system logs, indicating insufficient access control over sensitive information and a network-level exposure surface.
The public disclosure date for this case is 2026-09-24, with a CVSS score of 6.9 (Medium) and a CVSS 3.1 score of 5.3 (Medium). The announcement also notes that the vendor has proactively contacted users and completed the patch; if maintenance needs remain, users should contact the vendor's technical support.
From the vulnerability description, the core issue is not a complex privilege bypass, but rather that the access boundary for system logs is not properly protected. When an attacker can directly read logs without authentication, it means that at least one of the following has a gap: the log viewing interface, file path, API, or backend access control. This type of issue is typically classified as Sensitive Data Exposure, and if the logs contain account information, operation records, internal paths, error stacks, or other identifiable information, the downstream risk expands further.
Based on the announcement, the attack prerequisite for this vulnerability is remote and unauthenticated, so it does not require internal network penetration or prior credentials to trigger. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, reflecting a low exploitation barrier and direct network exposure, but with the main impact concentrated on confidentiality rather than integrity or availability. This also means that risk assessment should prioritize data leakage, exposure of operational traces, and environmental information that may be revealed in the logs.
From a defensive perspective, logs are often regarded as maintenance tools rather than high-value assets, which makes it easy for design to favor readability over access control. Once log content includes sensitive data, attackers can passively read it to obtain system behavior, internal naming conventions, error messages, and potential weakness clues, thereby providing intelligence for follow-up attacks. Although the announcement does not disclose more detailed exploitation steps, the mere exposure of logs is enough to constitute a clear information security incident.
The affected product is ezGlobal's GPM LIGHT - Green Supply Chain Management System. According to the announcement, the affected area is the accessibility of system logs rather than a single functional module or local page, so the actual scope depends on the deployment method, the contents retained in logs, and whether the system exposes access interfaces to the outside world.
If GPM LIGHT is used in a production environment to handle supply chain workflows, accounting records, or maintenance traces, log leakage may further expose internal organizational processes, system architecture, and sensitive operational information. For security governance, this type of issue affects not only a single system, but may also indirectly affect auditing, incident investigation, and subsequent remediation, because once log data is read by unauthorized parties, the evidence chain originally used to trace incidents may also be obtained by third parties.
The announcement does not provide other affected versions or specific deployment conditions, so in the absence of more details, all currently used GPM LIGHT deployments should be included in the inventory scope and it should be confirmed whether the vendor patch has been applied. Environments whose patch status has not been confirmed should be considered still at risk.
The first step is to immediately confirm whether GPM LIGHT has applied the vendor patch and to inventory all instances still in operation. If the system has not yet been updated, priority should be given to contacting the vendor's technical support to obtain maintenance and patching guidance, rather than relying on temporary configurations as a long-term substitute for the official fix.
The second step is to check log access permissions and ensure that log files, download interfaces, query APIs, and backend storage paths are all subject to least-privilege control. Any path that can be read directly by unauthenticated users should be closed immediately or protected with authentication, and logs should be prevented from returning complete error stacks, internal paths, and sensitive field contents.
The third step is to review the log content itself and remove or mask unnecessary sensitive information, such as credentials, tokens, personal data, internal identifiers, and detailed system parameters. If the logic that generates logs cannot be adjusted immediately, at minimum the likelihood of outputting sensitive fields should be reduced, and the log retention period should be shortened to reduce exploit value after a leak.
The fourth step is to strengthen monitoring and auditing, and to establish alerts for abnormal log reads, unexpected query behavior, and continued access attempts after failed logins. Because this vulnerability involves remote and unauthenticated information exposure, any abnormal log-related traffic should be prioritized for observation.
The fifth step is to incorporate this incident into vulnerability management and vendor risk management processes, and to require clearer access control documentation and patch verification results in future version updates. Internally, a log data classification system should also be established to avoid mixing operational information with sensitive data in the same channel that is public or accessible with low privileges.