CVE-2026-114515 in OCO-Server
Summary
by MITRE • 10/22/2026
OCO-Server is a self-hosted endpoint management application for computer inventory, software deployment, and mobile device management. Prior to 1.2.3, a valid Self-Service Portal user with permission to create job containers and read visibility on a computer and package can queue an uninstall job without deploy permission for those resources. Requests to `self-service/ajax-handler/job-containers.php` pass `uninstall_package_assignment_id[]` values to `lib/SelfService/CoreLogic.class.php::uninstallSelfService()`. Its permission-check loop continues after denied `METHOD_DEPLOY` checks without removing rejected IDs from `$installationIds`, then passes the original list to `lib/CoreLogic.class.php::uninstall()`. The CoreLogic object is constructed with a null SystemUser, causing `lib/CoreLogic.class.php::checkPermission()` to treat the operation as system context and unconditionally permit it. Enumerable `computer_package.id` values allow selection of readable installed-package assignments, including those on other users' computers. The `deploySelfService()` install path instead aborts on denied deployment permission, and resources lacking read permission remain blocked. This permits unauthorized software-removal jobs across resources visible to the acting user's role. This issue is fixed in version 1.2.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
OCO-Server versions prior to 1.2.3 contain a critical authorization bypass vulnerability within its Self-Service Portal that allows authenticated users with limited privileges to execute unauthorized software uninstallation operations on resources they should not have permission to modify. This flaw stems from an improper implementation of access control checks in the backend logic responsible for handling job container requests, specifically affecting the process initiated when a user attempts to queue an uninstall job via the self-service interface. The vulnerability exploits a logical error where the system fails to properly enforce separation between read-only visibility permissions and write or deployment privileges, effectively allowing users who can view software inventory details to manipulate that state without explicit authorization for modification actions.
The technical root cause lies in the handling of input parameters within the file lib/SelfService/CoreLogic.class.php, specifically inside the uninstallSelfService method which processes requests directed at self-service/ajax-handler/job-containers.php. When a user submits an uninstall request containing one or more package assignment identifiers via the uninstall_package_assignment_id array parameter, the application enters a permission verification loop to validate whether the current user has the necessary METHOD_DEPLOY permissions for each specified resource. However, this validation logic is flawed because it continues iterating through all provided identifiers even after encountering entries where deployment permission is explicitly denied by the access control system. Crucially, instead of filtering out or removing these unauthorized identifiers from the $installationIds array during this loop, the code retains them alongside any valid ones and passes the unmodified list to lib/CoreLogic.class.php::uninstall for execution.
This retention of invalid identifiers leads directly to a secondary authorization bypass mechanism involving system context elevation. The CoreLogic object instantiated by uninstallSelfService is constructed with a null SystemUser parameter rather than an authenticated user session object representing the requesting individual. When this object subsequently calls checkPermission within lib/CoreLogic.class.php, the absence of a valid user context causes the permission checking routine to default to treating the operation as if it were running under system-level privileges or administrative context. Consequently, the security checks are effectively bypassed, and the uninstallation process proceeds unconditionally for all identifiers in the list, regardless of whether the original requester had actual deployment rights for those specific resources.
The operational impact of this vulnerability is significant because it allows an attacker with basic Self-Service Portal access to remove software installations from computers they can view but do not own or manage. Since computer_package.id values are enumerable and often predictable based on database sequences, attackers can iterate through known identifiers to target systems belonging to other users within the organization. This capability undermines the integrity of endpoint management operations, potentially leading to service disruptions for end-users whose critical applications are removed without authorization. Furthermore, it violates the principle of least privilege by granting write access equivalent to deployment rights based solely on read visibility permissions, creating a pathway for lateral movement or denial-of-service attacks against managed endpoints.
In contrast, other functional paths within the application such as deploySelfService correctly implement these safeguards by aborting execution immediately upon detecting denied deployment permissions and ensuring that resources lacking appropriate read access remain blocked from modification attempts. This inconsistency highlights a lack of uniform security design across different modules of the OCO-Server codebase. The vulnerability is classified under CWE-269 Improper Privilege Management as it involves an actor obtaining privileges they are not entitled to, and aligns with MITRE ATT&CK techniques related to unauthorized access and potential impact on availability through resource manipulation.
To mitigate this risk, organizations running OCO-Server must upgrade immediately to version 1.2.3 or later where the permission-check loop has been corrected to properly filter out rejected identifiers before passing them to the core logic layer. Until upgrading is possible, administrators should restrict self-service portal access to only those users who genuinely require software deployment capabilities and monitor logs for unusual patterns of uninstall requests targeting resources outside expected user boundaries. Regular audits of job container creation events can also help detect exploitation attempts in real time by identifying sequences where multiple package assignments are submitted simultaneously with mixed permission statuses.