Unauthenticated RCE in SENAITE LIMS via JSON API Eval Injection (CVE-2026-54569)

A critical unauthenticated remote code execution vulnerability has been disclosed in SENAITE.CORE, the open-source laboratory information management system (LIMS) forked from Bika LIMS. The advisory, published via GitHub Security Advisories (GHSA-jrw6-7x4q-w25j) and tracked as CVE-2026-54569, carries a CVSS score of 9.8 and a public proof-of-concept.

What Was Reported

According to the advisory, the flaw is a chain of two independent bugs in SENAITE's JSON API:

• Missing authorization (CWE-862) — the /@@API/update route (and several sibling routes: update_many, remove, doActionFor, doActionFor_many, getusers) does not enforce the senaite.core: Access JSON API permission before processing a request, unlike the equivalent create route.
• Eval injection (CWE-95) — when updating a RecordField or RecordsField, the API helper calls Python's eval() directly on attacker-supplied request data, before any field-level write-permission check runs.

Per the advisory, the two flaws combine into a credential-free attack: an anonymous caller can discover the UID of the anonymously-readable bika_setup object via Plone's standard @@uuid view, then POST a Python expression as a value for one of its RecordsField fields (e.g. RejectionReasons) to /@@API/update, achieving arbitrary Python execution in the Zope worker process. Both flaws reportedly predate the SENAITE fork, dating back to 2013, and remain present through SENAITE.CORE 2.6.0 and the current 2.x development tip.

Why It Matters for Defenders

The advisory states this affects all SENAITE.CORE 2.x releases (2.0.0–2.6.0) where the Plone Site root grants View to Anonymous — the upstream default — and where the API is network-reachable. SENAITE is used as a LIMS, meaning affected instances may hold sensitive laboratory and patient-adjacent data. Per the advisory, successful exploitation grants full read/write access to the ZODB backing store, filesystem access on the container's data volume, outbound network egress, and the ability to create administrator accounts via direct access to Plone's user folder — enabling durable post-exploitation persistence, especially where the ZMI (/manage) is also exposed.

What Defenders Should Do Now

• Identify any SENAITE.CORE deployments (2.0.0–2.6.0) reachable from untrusted networks and treat them as high priority for patching or isolation once a fix is available.
• Restrict or firewall access to /@@API/* endpoints and the Plone ZMI (/manage) from the internet where a patched release is not yet deployed.
• Review Plone Site root permissions — confirm whether View is granted to Anonymous, and tighten if not operationally required.
• Hunt for anomalous POST requests to /@@API/update (and related update/remove/action routes) containing Python-expression-like payloads (e.g. references to __import__, os.popen, urlopen) in field values such as RejectionReasons or IDFormatting.
• Watch for unexpected outbound connections or subprocess activity originating from Zope/Plone worker processes, and for unexplained new accounts in the Plone PAS user folder.
• Note the advisory's suggested fixes: add the missing AccessJSONAPI permission check to the affected routes, and replace the eval() calls in the record field handlers with json.loads().

This is developing intel based on a same-day advisory disclosure; details may be refined as the vendor response and patch timeline become clearer. Full technical writeup, proof-of-concept, and credits are in the original GitHub Security Advisory.