Fix XXE in XML batch parsing

[mgaffigan]

CVE-2026-82578 found an XXE vulnerability in XML batch parsing. This closes that vulnerability and adds regression tests.

Review notes:

• See Fix XXE in XML batch parsing for the actual fix
• Most of this is tests, since the feature was not previously tested

[github-actions]

Test Results

124 files  + 1  124 suites  +1   2m 57s ⏱️ + 1m 8s
695 tests + 5  694 ✅ + 4  0 💤 ±0  1 ❌ +1 
725 runs  +23  724 ✅ +22  0 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 0fb4c05. ± Comparison against base commit 9359d9a.

♻️ This comment has been updated with latest results.

[gibson9583]

Requesting changes before merge.

The new batch endpoint can report success without accepting a batch, and its response collector retains all processed message payloads. Please address the two inline comments.

The Oracle integration check is also failing in the new CSV batch test: Expected source transformed content but the server stored none. Please investigate and get a passing Oracle run before merging. I have not established whether the missing content is caused by this PR.

Failing Oracle check

[mgaffigan]

@gibson9583, the oracle issue was opened with issue #454 and fixed in #455

Items raised are non-blocking now.

[gibson9583]

Items raised are non-blocking. Approved

[tonygermano]

My requests are for documentation improvements and not to challenge the code.

Can you expand the commit messages? Some of these changes are not small, and it would be good to have a summary of the changes and justification for why they are needed, especially when they touch multiple files or appear at a glance to change workflows.

Normally batch processing is controlled by the channel definition. What is the expected behavior when calling the new API method batchMessagesWithObj on a channel which doesn't have batch processing enabled? Is the only difference between calling this method and the existing method the return value? I think the method description implies that might be the case, but it should also describe what happens when called on a channel with batch processing disabled.

[mgaffigan]

Can you expand the commit messages? Some of these changes are not small, and it would be good to have a summary of the changes and justification for why they are needed, especially when they touch multiple files or appear at a glance to change workflows.

You should have write access to the branch. Feel free to reword. The commits are thematically made, already, so there should not be much explanation I can think of - and no issue is open to link to (nor do I think these are nuanced enough to warrant one).

Normally batch processing is controlled by the channel definition. What is the expected behavior when calling the new API method batchMessagesWithObj on a channel which doesn't have batch processing enabled? Is the only difference between calling this method and the existing method the return value? I think the method description implies that might be the case, but it should also describe what happens when called on a channel with batch processing disabled.

Not sure - but the change is to return the message ID's from process batch. It does not change the processing. Whatever happened previously would still happen, just now you have an endpoint which gives all of the message ID's instead of just 1.

[pacmano1]

This rejects batches whose DOCTYPE declares only internal entities and points nowhere. I added a case to 210-xml-batch-xxe: a batch declaring <!ENTITY site "CLINIC-A"> with two messages. On main it splits into the two expected messages with the entity resolved; on this branch the server refuses it with a 500. 02-two-messages passes on both, so the difference is the DOCTYPE rather than the batch path.

jonbartels flagged the same behaviour change on #441 on 15 Sep and offered a changelog entry, and abhinavagarwal07 asked there about a release note. Neither got a reply, and nothing here mentions it.

#453 goes the other way, permitting the DOCTYPE and setting only ACCESS_EXTERNAL_DTD. Measured alone, that setting errors on the external-entity payload and still accepts an internal-only DOCTYPE, so both approaches close the CVE and only this one drops traffic that works today. The two PRs should probably agree.

[mgaffigan]

This rejects batches whose DOCTYPE declares only internal entities and points nowhere. I added a case to 210-xml-batch-xxe: a batch declaring <!ENTITY site "CLINIC-A"> with two messages. On main it splits into the two expected messages with the entity resolved; on this branch the server refuses it with a 500. 02-two-messages passes on both, so the difference is the DOCTYPE rather than the batch path.

jonbartels flagged the same behaviour change on #441 on 15 Sep and offered a changelog entry, and abhinavagarwal07 asked there about a release note. Neither got a reply, and nothing here mentions it.

#453 goes the other way, permitting the DOCTYPE and setting only ACCESS_EXTERNAL_DTD. Measured alone, that setting errors on the external-entity payload and still accepts an internal-only DOCTYPE, so both approaches close the CVE and only this one drops traffic that works today. The two PRs should probably agree.

You and Tony are right. The rest of the app blocks DTDs entirely. I had tried to leave a small hole in the XSLT on the basis that someone might be using XHTML source messages, but it did not work, and I see no reasonable way to make it work.

Updated that PR to block DTD entirely, making it consistent with this PR (and the majority of the engine, which already blocks DTDs).