Question: is SpEL evaluation of task execContent in ApiTaskHandler considered a vulnerability? (StandardEvaluationContext)

## Question / security inquiry — SpEL evaluation of task `execContent` in `ApiTaskHandler`

This is a **question**, not an assertion that a vulnerability exists. We noticed that the job
worker evaluates a task-defined string as a Spring Expression Language (SpEL) expression in an
unrestricted `StandardEvaluationContext`, and we would like to know whether the maintainers
consider this a security issue or expected behaviour.

We are aware that the SREWorks job/task module is **designed to run arbitrary actions** (e.g. the
`api` task type performs outbound HTTP calls), so the ability to evaluate expressions may well be an
intended feature for users who already have task-creation privileges. Our question is specifically
about whether this grants execution **beyond** that intended capability.

## Where

`saas/job/.../sreworks-job-worker/.../taskhandlers/ApiTaskHandler.java`

```java
private void patchVarConf(Map varConfMap, String responseBody) {
// ...
JSONObject responseObject = JSONObject.parseObject(responseBody);
StandardEvaluationContext context = new StandardEvaluationContext();
context.setVariables(responseObject);
ExpressionParser parser = new SpelExpressionParser();
for (String key : varConfMap.keySet()) {
String value = varConfMap.get(key);
value = parser.parseExpression(value).getValue(context, String.class); // evaluated here
varConf.put(key, value);
}
// ...
}
```

`varConfMap` comes from the task's `execContent` (`ApiContent.getVarConfMap()`), which is supplied
when a task is created (`POST /task/create` → persisted to MySQL) and later read back by the worker.
The intent appears to be extracting output variables from the API response. Because the context is a
full `StandardEvaluationContext`, an expression value such as
`#{T(java.lang.Runtime).getRuntime().exec('calc')}` would also be evaluated (`calc` used here only as
a harmless placeholder), i.e. the expression engine has full type/reflection access rather than just
property extraction from the response object.

## What we'd like to confirm

1. **Is this considered a vulnerability, or expected functionality?** If task creation already implies
the ability to run arbitrary code by design, then SpEL function-call capability here may be within
the intended trust model — in which case this is not a vulnerability and can be closed.

2. **Does this chain grant code execution *beyond* the task module's intended capability?** For example:
- Can a **lower-privileged** user (someone who can influence `varConfMap` / the stored task but is
*not* otherwise authorized to execute arbitrary code) reach this evaluation?
- Is there any **unauthenticated** or cross-tenant/cross-context path to set or trigger it?
- Is the stored expression ever evaluated in a **different security context** than the creator's?

If any of the above is true, the unrestricted `StandardEvaluationContext` would represent a privilege
escalation / stored-injection issue rather than just expected behaviour.

## If you do consider hardening worthwhile

Independent of the trust-model question, the evaluation could be narrowed to its apparent purpose
(extracting fields from the response) by using a restricted `SimpleEvaluationContext`
(e.g. `SimpleEvaluationContext.forPropertyAccessors(DataBindingPropertyAccessor.forReadOnlyAccess())`),
which disables type references / `T(...)`, constructors and arbitrary method calls while still allowing
property access against the response object. This would be defence-in-depth and would not change the
legitimate variable-extraction feature.

Thanks for any clarification — happy to provide more detail or close this if it is intended behaviour.

Start in saas/job/.../sreworks-job-worker/.../taskhandlers/ApiTaskHandler.java and trace POST /task/create through persistence to patchVarConf. Check the authorization and execution paths for varConfMap, including tenant or security-context changes. Done means documenting whether unrestricted SpEL exceeds the intended trust model and, if hardening is accepted, confirming the response-field extraction behavior remains supported.

Written by the indexing model from the issue text.