Script Guard and Backpressure: how EximeeBPMS addresses RCE and overload risks in banking

Critical banking processes operate under pressure from two fundamental technical risks. The first is Remote Code Execution (RCE) hidden in BPMN process definitions—the possibility that malicious code is executed by the process engine simply because it appears in the model. The other is overload in External Task workers, which can halt processing during sudden traffic spikes or slowdowns in downstream systems.

With version 1.3.0, EximeeBPMS introduced two mechanisms designed specifically for high-availability environments: Script Guard and Backpressure. Together, they form a foundation for security and operational resilience in banking, supported by a modern Java stack.

What you should know:

• Script Guard blocks RCE in BPMN definitions at parse time and runtime.
• Backpressure stabilizes External Tasks and prevents worker overload.
• Both mechanisms run on supported Java versions 21 and 25.
• They strengthen compliance with the Polish financial supervisory authority (KNF), DORA, and internal banking security policies.

RCE in BPMN: a real attack vector

BPMN engines execute scripts embedded in process models, which means a process definition can become a carrier of malicious code.

RCE (Remote Code Execution) is a situation in which malicious code is executed by the process engine—remotely, solely based on the BPMN model content.

Where RCE risks commonly appear:

• Script Task – Groovy, JavaScript, JUEL,
• Execution Listener / Task Listener – code executed at the start or end of an activity,
• I/O Mapping – expressions that process input and output data,
• JUEL – the ability to invoke Java methods directly from expressions,
• Process XML – injection of malicious code directly into the process definition.

In banking, this is particularly dangerous: the script executes automatically, in a production environment, often with access to transactional data or external systems. This is a classic RCE scenario.

How does Script Guard block RCE?

Script Guard currently enforces 38 security rules that detect 26 distinct classes of RCE techniques (marked as SCRIPT_SECURITY_*). These include, among others::

• system calls (ProcessBuilder, Runtime.exec),
• reflection and dynamic class loading,
• file access (java.io, java.nio),
• network access (sockets, HTTP, URL),
• Groovy constructs (shell, metaclass),
• analogous techniques in JavaScript (GraalVM) and JUEL.

The rules are enforced at two independent control points:

The policy is enabled by default, configurable, and auditable, which is essential for regulatory compliance.

Why is this critical for banks?

• Compliance with the financial supervisory authority and DORA – eliminating RCE is a requirement for execution security and operational resilience,
• Security of critical processes – no risk of executing unauthorized code,
• Audit predictability – the policy is transparent, documented, and can be presented to auditors.

External Task overload: how Backpressure stabilizes processing

Why are External Tasks prone to overload?

External Tasks are often used for integrations with external systems. This means their performance depends on:

• sudden traffic spikes (e.g., campaigns, transactional peaks),
• slow or stalled workers,
• delays in downstream systems.

In such situations, a worker may fetch more tasks than it is able to process, which leads to overload, process blocking, and operational incidents.

How does Backpressure work in EximeeBPMS?

EximeeBPMS extends the Backpressure mechanism known from Camunda, adapting it to the requirements of high-availability environments so that a worker never fetches more tasks than it can actually process.

The mechanism operates in three areas:

Dynamic fetch size limiting

• The limit of fetched tasks is recalculated continuously based on the number of currently occupied threads in the worker’s pool.
• If the worker is under load, the fetch size is automatically reduced.
• When a topic temporarily has no new tasks, Backpressure automatically increases the pauses between subsequent fetch attempts: it starts at 500 ms and doubles the interval with each attempt (the maximum interval can reach 60 seconds). Thanks to this, the worker stabilizes itself—both during sudden inflows of tasks and during idle periods—without manual parameter tuning.
• This means that Backpressure regulates both the number of fetched tasks and the frequency of fetch attempts, keeping the worker in a stable state regardless of the nature of the load.

ThreadPoolExecutor per topic (optional)

• EximeeBPMS does not require a separate executor per topic—this is a configurable option that can be consciously applied in environments requiring workload isolation.

Stabilized task flow under heavy load

• The mechanism prevents the worker from being “flooded” with tasks, stabilizes processing, and eliminates blocking errors.

Why is this critical for banks?

• Continuity of critical processes: no risk of processing being halted,
• Resilience to traffic spikes: the system remains stable even during sudden changes in load,
• Predictable operations: reduced risk of incidents and blocking errors.

Currently supported Java versions as the foundation of security and resilience

Supported Java versions (21/25)

Compatibility is tested on Eclipse Temurin JDK, which ensures predictability and stability of environments.

Why modern Java versions are crucial for Script Guard and Backpressure

• JVM security improvements → reduced risk of exploits,
• Modern concurrency mechanisms → more stable Backpressure behavior,
• Long-term LTS support → alignment with banking policies and audits.

What this means for banks

• Predictable environment lifecycle: easier upgrade planning,
• Reduced risk resulting from outdated libraries,
• Compliance with regulatory requirements: financial supervisory authority, DORA, internal ICT security policies.

Alignment with banking practices

Script Guard and Backpressure align with key requirements of the financial sector:

• Critical processes: protection of integrity and continuity of operations,
• Security audits: the mechanisms are transparently documented and operate automatically,
• Regulatory compliance: financial supervisory authority, DORA, ICT security policies,
• Operational resilience: stability under load, predictability, absence of incidents.

Conclusions

Script Guard and Backpressure form two pillars of EximeeBPMS security and resilience: the former blocks RCE in BPMN process definitions, and the latter stabilizes External Tasks under load. Combined with the supported, modern Java 21 and Java 25 stack, they create a foundation that meets banking requirements for security, continuity of operations, and regulatory compliance.

FAQ

Does Script Guard work both during deployment and execution of a process?

Yes, the security policy is enforced at two levels: during BPMN parsing and at runtime. This ensures that both malicious scripts in the process definition and attempts to execute them are blocked.

Does Script Guard require changes to BPMN models?

No, the mechanism does not modify BPMN models. It protects script execution only and does not interfere with process semantics.

Does Backpressure require changes on the External Task worker side?

No, the mechanism operates on the engine side. The worker does not need to implement any additional functionality.

Does Backpressure prevent overload when the downstream system is slow?

Yes, it limits the fetch size proportionally to worker load, ensuring workers are not “flooded” with tasks when the downstream system slows down.

Which Java versions does EximeeBPMS support?

Starting from version 1.4.0, EximeeBPMS supports Java 21 and Java 25, ensuring optimal performance, security, and stability for Script Guard and Backpressure.

Do Script Guard and Backpressure support DORA compliance?

Yes, Script Guard strengthens execution security, and Backpressure enhances operational resilience. Both mechanisms align with DORA requirements related to stability and ICT risk controls.

Sources

1. EximeeBPMS – External Tasks: https://docs.eximeebpms.org/manual/latest/user-guide/ext-client/
2. EximeeBPMS – Supported Environments: https://docs.eximeebpms.org/manual/latest/introduction/supported-environments/
3. Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng
4. EximeeBPMS 1.3.0 release notes: https://docs.eximeebpms.org/manual/latest/release-notes/release-notes-1.3.0/
5. EximeeBPMS – Security Instructions: https://docs.eximeebpms.org/manual/latest/user-guide/security/
6. EximeeBPMS – Script Guard: https://docs.eximeebpms.org/manual/latest/user-guide/process-engine/script-guard/
7. EximeeBPMS – Script Task: https://docs.eximeebpms.org/manual/latest/reference/bpmn20/tasks/script-task/
8. DORA: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en