A Semantic Attack on Google Gemini - Read the Latest Research
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| go.temporal.io/server | go | >= 1.24.0, < 1.27.4 | 1.27.4 |
| go.temporal.io/server | go | >= 1.28.0, < 1.28.2 | 1.28.2 |
| go.temporal.io/server | go | >= 1.29.0, < 1.29.2 | 1.29.2 |
The vulnerability is a namespace policy bypass in Temporal's ExecuteMultiOperation feature. An authenticated user with permissions for one namespace can craft a request that causes validation and feature gating to be performed against a different namespace.
The root cause is in the WorkflowHandler.convertToHistoryMultiOperationItem function. This function is responsible for processing individual operations (like starting or updating a workflow) within a batch ExecuteMultiOperationRequest. Before the patch, this function did not verify that the namespace field on the inner operations matched the namespace of the parent, authorized request.
The patch, found in commit a3734a3d330d941440724c973c69c207ff0e8a99, introduces a check in convertToHistoryMultiOperationItem to compare the inner operation's namespace with the parent request's namespace. If they don't match, it returns an errMultiOpNamespaceMismatch error.
During exploitation, a call to the WorkflowHandler.ExecuteMultiOperation API endpoint would trigger this vulnerability. A runtime profiler would show WorkflowHandler.ExecuteMultiOperation calling WorkflowHandler.convertToHistoryMultiOperationRequest, which in turn calls the vulnerable function WorkflowHandler.convertToHistoryMultiOperationItem. Therefore, ExecuteMultiOperation (the entrypoint) and convertToHistoryMultiOperationItem (the root cause) are key indicators of this vulnerability being triggered.
WorkflowHandler.convertToHistoryMultiOperationItemservice/frontend/workflow_handler.go
WorkflowHandler.ExecuteMultiOperationservice/frontend/workflow_handler.go
WorkflowHandler.convertToHistoryMultiOperationRequestservice/frontend/workflow_handler.go