Description

SENAITE.CORE is the core framework for the SENAITE laboratory information management system. From 2.0.0 to 2.6.0, the SENAITE.CORE JSON API permits unauthenticated remote code execution through a two-request chain involving missing authorization and unsafe evaluation. The state-changing routes in src/bika/lims/jsonapi/update.py, including update, update_many, remove, doActionFor, doActionFor_many, and getusers, do not enforce the senaite.core: Access JSON API permission before resolving attacker-selected objects. In src/bika/lims/jsonapi/init.py, set_fields_from_request passes raw request values for RecordsField and RecordField instances to eval() before field mutator write-permission checks execute. An anonymous attacker can discover the bika_setup object identifier through @@uuid, send a value such as RejectionReasons to /@@API/update, and execute arbitrary Python in the Zope worker before a later mutation failure rolls back ZODB changes. The same unsafe evaluation pattern is present in src/senaite/core/browser/fields/record.py and src/senaite/core/browser/fields/records.py. Successful exploitation can expose or modify laboratory data, files, and accounts and can disrupt the service.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T16:16:27.733Z",
  "pubdate": "2026-08-26T16:16:27.733Z",
  "executiveSummary": "SENAITE.CORE versions 2.0.0 through 2.6.0 contain a critical vulnerability allowing unauthenticated remote code execution (RCE) within the laboratory information management system.\nThe vulnerability stems from an authorization bypass in the JSON API, coupled with unsafe evaluation of user-supplied data.\nAn unauthenticated attacker can exploit this to execute arbitrary Python code within the Zope worker process, leading to full system compromise.\nThe impact includes unauthorized access to laboratory data, modification of system configurations, account takeover, and potential service disruption.\nThe exploitation chain involves two distinct requests: the first leverages missing access control checks on state-changing API routes to target specific objects, while the second exploits unsafe eval() calls during the processing of RecordField and RecordsField types.\nBecause the execution occurs before permission checks are fully enforced, the attack succeeds even if subsequent mutations are rolled back by the ZODB.\nThis vulnerability represents a high risk to the confidentiality, integrity, and availability of the SENAITE laboratory environment.",
  "technicalDetails": "The vulnerability originates in the SENAITE.CORE JSON API, specifically within the implementation of state-changing routes located in src/bika/lims/jsonapi/update.py. The affected routes include update, update_many, remove, doActionFor, doActionFor_many, and getusers.\nThe root cause is a dual-layered failure. First, these routes fail to enforce the 'senaite.core: Access JSON API' permission before the application resolves attacker-specified object identifiers. This allows an anonymous user to interact with internal objects, such as the bika_setup object, which can be identified using the @@uuid endpoint.\nSecond, a critical injection point exists in src/senaite/core/browser/fields/record.py and src/senaite/core/browser/fields/records.py, utilized by src/bika/lims/jsonapi/init.py via the set_fields_from_request function. When processing RecordsField and RecordField instances, the application passes raw request values directly into the Python eval() function. This execution happens prior to the validation of field mutator write-permissions.\nThe exploitation flow proceeds as follows: An unauthenticated attacker first identifies the target object (e.g., bika_setup). The attacker then constructs a malicious payload containing Python expressions disguised as field values. By sending these to one of the unprotected API endpoints (such as /@@API/update), the attacker triggers the evaluation of the payload.\nBecause the eval() call is executed in the context of the Zope worker, the injected code runs with the privileges of the application process. Even though the subsequent mutation attempts may trigger a failure and result in a ZODB rollback, the execution of the injected code has already occurred, rendering the rollback ineffective at preventing the initial RCE.\nThis pattern of unsafe evaluation is pervasive across the identified components, exposing the underlying Zope instance to arbitrary command execution. Successful exploitation does not require prior authentication, and the network exposure is inherent to any installation where the SENAITE.CORE JSON API is reachable. The post-exploitation impact includes the ability to execute arbitrary commands, manipulate database contents, exfiltrate sensitive laboratory research data, and gain persistent control over the server environment."
}