OpenKM fixes workflow flaw that lets any user run commands as root

OpenKM fixes workflow flaw that lets any user run commands as root

13 November 2026: Two high-severity flaws in OpenKM Community Edition, the open-source document management system, let any logged-in user reach well beyond their role: CVE-2026-112182 (CVSS 4.0 score 8.7) lets an ordinary user run operating system commands through the workflow engine, as root in the official Docker image, and CVE-2026-112181 (8.3) opens an XML external entity hole. Spain's INCIBE-CERT published the coordinated advisory and lists neither as exploited. Version 7.0.4 is out; the fix for the 6.3 line, 6.3.14, is still to come.

Not yet independently verified. The details come from INCIBE-CERT's advisory; we have not read an advisory from OpenKM itself, and the 6.3.14 release had not been published when INCIBE wrote. Neither CVE is listed as exploited. We will update this when it can be confirmed, and remove this note.

A workflow endpoint that checks the login but not the role

The worse flaw sits in workflow definition management in OpenKM CE 6.3.12 and 6.3.13. The REST endpoints registerProcessDefinition and runProcessDefinition require a user to be authenticated, but neither they nor the WorkflowService layer underneath check what role that user holds. Any account with ROLE_USER can therefore register a process definition containing BeanShell scripts and then run it. BeanShell executes Java code, and from there operating system commands, with the privileges of the OpenKM service. In the official Docker image that service runs as root, so a single compromised staff account becomes control of the host.

The 7.x branch is not affected by this flaw, because it no longer ships the jBPM workflow engine.

XML entities that reach files and internal services

CVE-2026-112181 affects OpenKM CE 6.3.3 to 6.3.13 and 7.0.3. XML processing in the FormUtils and LocalEntityResolver components does not properly restrict the resolution of external resources, so an authenticated user can send a crafted REST request that makes the server fetch what the attacker chooses. On 6.3.x that amounts to server-side request forgery, with the server making HTTP requests on the attacker's behalf. On 7.0.3 it goes further: the server can read local files and reach internal HTTP resources.

The flaws were reported by Carlos Alejandro Smith Tay (Las3rs).

Fixed versions and what is still pending

• OpenKM CE 7.0.4: published. The entity resolver is fixed, general and parameter external entities are disabled and secure XML processing is switched on.
• OpenKM CE 6.3.14: pending. It removes HTTP requests for non-local DTDs and, at the business layer, requires the administrator role to register or delete process definitions across REST, SOAP and the admin interface.

The vendor's advice, as INCIBE relays it, is to move to 7.0.4. Teams on 6.3 that depend on workflows have a harder choice, because 7.x drops the jBPM engine those workflows run on.

Closing the endpoints until 6.3.14 arrives

Until the 6.3 fix ships, INCIBE gives two temporary measures. At the reverse proxy or firewall, block non-administrator access to /OpenKM/services/rest/workflow/* and /OpenKM/services/OKMWorkflow. If the web services are not used at all, block everything under /OpenKM/services/. Neither measure touches the XML entity flaw on 6.3, so installations that accept REST requests from ordinary users stay exposed to it until the update.

Because both flaws need only a valid account, deployments that give document access to large numbers of staff, contractors or clients carry the most risk, and the Docker image's root process makes the workflow flaw the one to close first.

Sources

• INCIBE-CERT: Multiple vulnerabilities in OpenKM Community Edition (INCIBE-2026-895, Spanish), 13 November 2026
• INCIBE-CERT: Multiple vulnerabilities in OpenKM Community Edition (English), 13 November 2026
• OpenKM: Community Edition 7.0 changelog (read 14 November 2026), 14 November 2026