CVE-2026-109178 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains a missing authorization vulnerability in LogController that allows any authenticated user to forge, modify, or delete audit log entries. Low-privilege users can call /log/add, /log/update, /log/delete, and /log/deleteBatch to fabricate entries, rewrite user and IP fields, or erase records to hide activity.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in jshERP versions up to 3.6 represents a critical failure in access control mechanisms within the LogController component of the application architecture. This flaw is classified as an insecure direct object reference combined with broken access control, allowing authenticated users who possess only low-level privileges to interact directly with endpoints designed for administrative or audit purposes. Specifically, the API routes /log/add, /log/update, /log/delete, and /log/deleteBatch lack proper authorization checks that verify whether the requesting user has the requisite permissions to perform these actions on log data. In a secure implementation, such operations should be restricted exclusively to system administrators or security auditors who have been explicitly granted elevated privileges for managing audit trails. The absence of this verification allows any logged-in user, regardless of their role within the organization's hierarchy, to manipulate the integrity and availability of critical logging mechanisms.
The operational impact of this vulnerability is severe due to its direct effect on forensic capabilities and accountability measures. By exploiting the /log/add endpoint, an attacker can forge audit log entries, potentially creating false records that attribute malicious activities to innocent users or fabricate evidence of legitimate actions for unauthorized operations. The ability to use /log/update enables attackers to rewrite metadata fields such as user identifiers and IP addresses associated with specific events, thereby obfuscating the true originator of attacks or internal policy violations. Furthermore, the access to /log/delete and /log/deleteBatch allows adversaries to permanently erase existing records, effectively covering their tracks after a compromise has occurred. This capability undermines the fundamental principle of non-repudiation in information security, making it nearly impossible for incident responders to reconstruct the timeline of events or identify the scope of a breach based on application logs alone.
From a technical perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-732 Incorrect Permission Assignment for Critical Resource. The root cause lies in the controller logic which likely relies solely on session existence rather than role-based access control checks when processing requests to these specific endpoints. This design oversight permits lateral movement within the application's trust boundary, as low-privilege accounts can escalate their effective capabilities by manipulating system-critical data structures that are not intended for user modification. The vulnerability also facilitates persistence and evasion strategies commonly associated with ATT&CK technique T1070 Indicator Removal on Host, specifically through log deletion or modification to avoid detection by security information and event management systems.
Mitigation of this issue requires immediate implementation of strict role-based access control policies within the LogController class. Developers must ensure that all methods handling audit logs verify not only authentication but also authorization against a predefined list of allowed roles before executing any write operations. Additionally, implementing immutable logging mechanisms where log entries are written to append-only storage or transmitted immediately to an external SIEM system can prevent local tampering even if the application layer is compromised. Regular security audits and code reviews focusing on access control lists for sensitive endpoints should be conducted to identify similar gaps in other modules of the jshERP platform.