Free security audit & remediation - You are welcome

[gbdevw]

Security Analysis of the phax/phase4 AS4 Implementation

This report examines phase4 (an AS4 client/server library) for vulnerabilities that could impact availability, integrity of documents (e.g. invoices), or data confidentiality. We focus on XML parsing, attachment handling, digital signature verification, cryptography, and adherence to Peppol eDelivery security requirements. Each finding below is categorized by severity and exploit type, with affected code areas and remediation recommendations.

XML Processing Vulnerabilities

XML External Entity (XXE) Injection – Critical (Data Exfiltration & DoS): The phase4 server likely parses inbound SOAP XML without fully disabling external entities. If an attacker sends a malicious XML with a <!DOCTYPE> and external entity, the parser could attempt to retrieve local files or remote URLs, exposing sensitive data or hanging the server. For example, a crafted invoice payload could include <!ENTITY xxe SYSTEM "file:///etc/passwd"> to steal server files. Affected code: The SOAP message parsing in phase4-lib appears to use default XML parsers (e.g. JAXB) without explicit secure settings (no evidence of XMLConstants.FEATURE_SECURE_PROCESSING being enabled). Recommendation: Configure all XML parsers (e.g. DocumentBuilderFactory, JAXB unmarshalers) to disable DTDs and external entities. Use JAXP secure processing features and/or prohibit DOCTYPE declarations to prevent XXE.

XML Entity Expansion (“Billion Laughs”) – High (Denial of Service): Even without external entities, an attacker can embed a large nested entity definition to blow up XML processing. If the parser doesn’t impose limits, a tiny message can expand into gigabytes of text and exhaust memory or CPU. Affected code: The default JDK XML parser will expand internal entities unless configured with limits. Phase4’s code does not show custom entity-expansion limits, so a payload with many nested <!ENTITY> definitions could freeze the server. Recommendation: Enable protective parser features (JAXP secure processing) and set limits on entity expansions and overall XML sizes ([XMLConstants.FeatureSecureProcessing Field (Javax.Xml)](https://learn.microsoft.com/en-us/dotnet/api/javax.xml.xmlconstants.featuresecureprocessing?view=net-android-35.0#:~:text=XMLConstants,as%20denial%20of%20service%20attacks)). In practice, ensure the SOAP/XML parsing layer uses defensive configurations (e.g. limit total nodes, attribute count, etc.) to mitigate XML bomb attacks.

Unbounded XML Schema Validation Loops – Medium (DoS): Phase4 uses XML Schema (XSD) validation for certain payloads (Peppol BIS invoices in SBDH) as seen in error logs ([Multi-Profile handling using Single Servlet different URL · phax phase4 · Discussion #273 · GitHub](#273)). Malicious XML that exploits pathological schema features (like maxOccurs with large values or recursive types) could cause extremely slow validation. Affected code: The Peppol SBDH parser (LoggingJAXBReadExceptionHandler in logs) attempts to validate incoming XML and failed on an unexpected root element ([Multi-Profile handling using Single Servlet different URL · phax phase4 · Discussion #273 · GitHub](#273)). Without runtime limits, an attacker could craft an XML that triggers worst-case behavior in the validator. Recommendation: Use a hardened XML schema factory with limits (JDK’s XMLConstants.W3C_XML_SCHEMA_NS_URI with secure processing) and consider imposing timeouts or abort conditions for extremely large or complex inputs during validation.

Attachment and Compression Handling

Large Payload/Attachment DoS – High (Memory Exhaustion): Phase4 supports binary attachments (e.g. an invoice document or PDF) sent via AS4 MIME parts. The server currently lacks explicit limits on the size or number of attachments. An attacker could send an oversized file or many attachments to overwhelm memory or disk. For instance, a 2GB fake invoice attachment could be accepted and loaded into memory, causing out-of-memory errors or disk fill. Affected component: The MIME parsing (via Eclipse Angus Mail 2.0.3) will faithfully parse whatever size data is provided, and phase4’s AS4IncomingHandler doesn’t impose a cap. Recommendation: Implement configurable size limits (both per attachment and total message size). The servlet processing should check the Content-Length (if known) or stream attachments to disk with quotas. Reject messages that exceed reasonable bounds, and consider a maximum attachments count to prevent abuse.

Compression “Zip Bomb” – High (CPU/Memory DoS): Phase4 allows optional AS4 payload compression. In fact, the client defaults to compressing the main payload (e.g. UBL XML) ([phase4/phase4-peppol-client/src/main/java/com/helger/phase4/peppol/Phase4PeppolSender.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-client/src/main/java/com/helger/phase4/peppol/Phase4PeppolSender.java#:~:text=public%20static%20final%20boolean%20DEFAULT_COMPRESS_PAYLOAD,true)) ([phase4/phase4-peppol-client/src/main/java/com/helger/phase4/peppol/Phase4PeppolSender.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-client/src/main/java/com/helger/phase4/peppol/Phase4PeppolSender.java#:~:text=compressPayload%20)). While this improves efficiency, it opens the server to decompression bombs: a small compressed payload that expands hugely. If an attacker sends a 10KB AS4 message that decompresses to 500MB of XML, the server will consume extreme memory or trigger lengthy processing. Affected code: On receiving, phase4 will decompress payloads marked with the compression flag using standard GZIP. No limit is imposed on the expanded size relative to input. Recommendation: Treat compressed inputs carefully. Set a threshold for the decompressed data size – e.g. if a payload claims to be 10KB but expands beyond a set limit, abort processing. Additionally, monitor compression ratios and consider disabling compression for untrusted senders or in profiles where it’s not strictly needed.

MIME Boundary Parsing and Injection – Medium (Integrity Bypass): The library relies on JavaMail/Angus to parse MIME boundaries of AS4 messages. Malformed MIME parts or boundary spoofing could potentially confuse the parser. For example, an attacker could craft a MIME boundary that appears early, causing parts of the SOAP envelope or attachments to be ignored or mis-parsed. While no specific parser flaw is known in Angus Mail 2.0.3 (it’s a recent JavaMail implementation), careful validation is needed. Affected code: The MimeMessage handling (via MailcapCommandMap seen in Issue #23) suggests reliance on Java Activation handlers ([no object DCH for MIME type application/soap+xml;charset=UTF-8 · Issue #23 · phax/phase4 · GitHub](#23)) ([no object DCH for MIME type application/soap+xml;charset=UTF-8 · Issue #23 · phax/phase4 · GitHub](#23)). If the MIME structure is unexpected (multiple nested multipart sections or incorrect headers), the library might still proceed without error. Recommendation: Employ strict MIME parsing – accept only the expected structure (a single SOAP part and one payload part by Peppol spec). If additional or unknown MIME parts are present, or if content types are abnormal, reject the message. Also ensure that text fields (filenames, content-IDs) from MIME headers are handled safely to avoid any injection into logs or path names.

Unsigned Attachment Content – Medium (Document Tampering): By design, AS4 can sign the SOAP envelope (which includes references to attachments), but the actual binary attachment (e.g. the XML invoice payload) may not be covered by the signature if not configured. If phase4 does not include the attachment in the WS-Security signature, a man-in-the-middle or rogue Access Point could swap out the invoice content without detection. Affected code: The phase4 client uses WSS4J to sign messages; however, it’s unclear if the attachment is included in the ds:Reference. No explicit code reference to attachment signing was found, raising concern that only the SOAP body (UserMessage) is signed. Recommendation: Ensure that the payload attachment is always covered by a digest in the signature (e.g. using WS-Security “Attachment Content Signature Transform”). If the current library version cannot sign attachments, this is a design gap – consider using an <xop:Include> or hashing the attachment and placing the hash in a signed element. This will prevent any tampering of invoice or document content in transit.

Digital Signature Verification and Enforcement

Acceptance of Unsigned/Unencrypted Messages – High (Integrity & Authenticity Bypass): In the default configuration, the phase4 server would accept an AS4 message with no XML Digital Signature and no encryption, without even logging a warning ([How to enforce signature and encryption for receiving messages? · Issue #162 · phax/phase4 · GitHub](#162)). This means an attacker could send a plain SOAP with an unsigned invoice and phase4 would process it as if legitimate. This violates Peppol security requirements (messages must be signed) and allows trivially forging documents. Affected component: AS4IncomingHandler processing pipeline – as of a recent version, it did not enforce a <wsse:Security> header’s presence ([How to enforce signature and encryption for receiving messages? · Issue #162 · phax/phase4 · GitHub](#162)). The only indication was a debug log in WSSConfigManager when no signature was found, which is insufficient ([How to enforce signature and encryption for receiving messages? · Issue #162 · phax/phase4 · GitHub](#162)). Recommendation: Require a valid signature (and encryption if profile mandates) before processing the user payload. Phase4 v3.0.0+ introduced an option to enforce this (in response to issue #162). Make sure phase4.profile.* settings mark signature as mandatory, and fail messages that lack expected security. This prevents attackers from bypassing authentication by simply omitting the Security header.

Signature Wrapping Attack – High (Payload Tampering): Phase4 uses Apache WSS4J for XML Signature validation. Without additional safeguards, it could be susceptible to signature wrapping, where an attacker inserts a duplicate element (e.g. a fake <eb:UserMessage>) and reorders the SOAP structure so that the signed element is not the one actually used by the application. If the code later retrieves the invoice content by tag name rather than by the specific wsu:Id, the attacker’s unsigned content might be processed. WSS4J and Santuario provide partial mitigation (they’ll by default sign/verify by ID and JDK 17+ disallows duplicate IDs ([Migration Troubleshooting - Platform 6](https://doc.p6.sidetrade.io/6.9.1/releases/migration/migration-troubleshooting/#:~:text=minKeySize%20DSA%201024%2C,noRetrievalMethodLoops))). However, the phase4 library does not explicitly enforce the one-signature-one-payload mapping beyond what WSS4J does internally. Affected code: The SOAPHeaderElementProcessorWSS4J and WSS4J engine will locate elements by their Id references. If a duplicate ID is present, the behavior depends on parser configuration. Unless the noDuplicateIds policy is enabled (which JDK’s java.xml.dsig.secureValidation covers in newer Java ([Migration Troubleshooting - Platform 6](https://doc.p6.sidetrade.io/6.9.1/releases/migration/migration-troubleshooting/#:~:text=minKeySize%20DSA%201024%2C,noRetrievalMethodLoops))), an older runtime might be tricked. Recommendation: Enable secure validation in the XMLSignature factory explicitly. Phase4 should configure XMLSecurityProperties or WSS4J WSHandlerResult to enforce that all expected elements are signed and no extraneous elements exist. As a developer, ensure that after signature verification you use the returned document from WSS4J (which strips out or resolves Security elements) rather than parsing the raw XML again. This ensures the application only sees the vetted content.

Use of Weak Signature Algorithms – Medium (Crypto Weakness): The Peppol SMP lookup in phase4 requires accepting SHA-1 based XML signatures (for Service Metadata). By default Java 17+ forbids SHA-1 in XML DSig, causing lookup failures ([Migration Troubleshooting - Platform 6](https://doc.p6.sidetrade.io/6.9.1/releases/migration/migration-troubleshooting/#:~:text=%E2%80%9CThe%20SMP%20lookup%20part%20does,signature%20method%20and%20digest%20method%E2%80%9D)). Phase4’s documentation notes that one must override JDK security policy to allow SHA-1 ([Migration Troubleshooting - Platform 6](https://doc.p6.sidetrade.io/6.9.1/releases/migration/migration-troubleshooting/#:~:text=%E2%80%9CThe%20SMP%20lookup%20part%20does,signature%20method%20and%20digest%20method%E2%80%9D)). This is an insecure default mandated by the Peppol network (not the fault of phase4), but it does lower security by allowing a deprecated hash algorithm. Moreover, AS4 message signatures themselves should use SHA-256; any use of SHA-1 for message signing (e.g. if configured for compatibility) would be a vulnerability. Affected component: XML signature configuration – phase4’s WSSConfigManager likely sets algorithms per profile. If the Peppol profile or others allow RSA-SHA1 or DSA-SHA1 for user messages, that’s a risk. Recommendation: Avoid SHA-1 where possible. For SMP, use it only because the network forces it, and push the Peppol community to upgrade to SHA-256. In phase4, ensure all WS-Security signatures for AS4 messages use strong hashes (SHA-256/384) and encryption (AES-128/256). Also verify that the code doesn’t allow downgrade attacks (e.g. if a message uses a weaker algorithm unexpectedly, treat it as invalid).

Improper Signature Validation Error Handling – Low: If a signature fails to verify (e.g. wrong key or message modified), the server will throw an exception and not process the message – which is correct. However, ensure that this failure is logged and handled securely. There was an indication in the code that if no signature is present it only logs debug ([How to enforce signature and encryption for receiving messages? · Issue #162 · phax/phase4 · GitHub](#162)), but if a signature is present and bad, it should at least warn or error. We assume WSS4J would throw a WSSecurityException that phase4 bubbles up (resulting in an error SOAP fault or similar). Recommendation: Confirm that any signature verification error results in a failed message processing (no document handed to business logic) and an appropriate error Message is returned. No partial processing should occur on failed signatures.

Certificate-Based Authentication and Trust

Trusting Untrusted Certificates – High (Unauthorized Access): AS4 relies on X.509 certificates to authenticate Access Points (APs). Phase4 must ensure the sender’s certificate is valid and belongs to the expected partner. In Peppol mode, phase4 fetches the recipient’s AP certificate from the SMP directory and compares it to the message’s signing certificate ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=if%20%28LOGGER)) ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=if%20%28LOGGER)). If this check were missing or incorrect, any actor with a certificate from the same PKI could forge messages to others. Affected code: In Phase4PeppolServletMessageProcessorSPI, after verifying the XML signature, it obtains the signing cert (aState.getSigningCertificate()) and compares its Subject Common Name (C2 ID) to the SMP lookup result ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=%2F%2F%20Incoming%20message%20signed%20by,C2)) ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=return%20PeppolReportingItem)). The code throws an exception if there’s a mismatch (ensuring you aren’t accepting a signature from an imposter). For other profiles (e.g. BDEW, ENTSOG), if similar validation isn’t done, there may be a gap. Recommendation: Maintain strict certificate mapping for all profiles: either via an SMP-like mechanism or a configured trust list mapping. Never accept a message signed by a certificate that isn’t explicitly trusted or expected for that sender. This includes verifying the certificate chain (up to a known root) and checking certificate expiry and revocation status.

Revocation Checking Disabled – Medium (Using Revoked Credentials): By default, phase4 disables CRL/OCSP checks on certificate validity to avoid latency issues. In a discussion log, “phase4 Peppol signing certificate revocation check is now disabled” is shown on startup ([Multi-Profile handling using Single Servlet different URL · phax phase4 · Discussion #273 · GitHub](#273)). This means if a partner’s private key was compromised and their cert revoked, an attacker could still use that certificate to sign messages and phase4 would accept it (until the cert expires or is removed from trust store). Affected component: Phase4PeppolServletConfiguration likely has a flag for revocation checking, defaulting to off for performance ([Multi-Profile handling using Single Servlet different URL · phax phase4 · Discussion #273 · GitHub](#273)). Recommendation: Enable certificate revocation checking in production deployments. This can be done by importing CRLs of Peppol CAs or using OCSP. At minimum, phase4 should allow toggling this on. Given the potentially large window of trust if not checked, enabling it significantly improves security. If performance is a concern, consider caching CRL responses or limiting frequency of checks, but do not entirely forego this protection.

Incomplete Certificate Chain Validation – Low (Trust Bypass): Phase4 relies on the Java default PKI validation (via WSS4J) to verify that the signing certificate is issued by a trusted authority (e.g. Peppol Root or equivalent). It’s important that the full chain is validated and that only specifically trusted roots are accepted. If the server’s truststore is misconfigured to trust an overly broad set of CAs (e.g. system default CAs), an attacker might use a certificate from a public CA to sign messages and get trusted. Affected code: The WSS4J crypto configuration is set in phase4 (they likely use BouncyCastle or WSS4J’s Merlin with a keystore of Peppol trust anchors). If an operator mistakenly uses the JVM default keystore, this could trust unrelated CAs. Recommendation: Use a dedicated truststore containing only the authorized CAs for the network (e.g. the Peppol PKI CA certificates). Phase4’s documentation should stress this. Technically, ensure the crypto.properties or Merlin instance in WSS4J is pointed at the correct certificate store. This prevents accepting certificates from entities outside the intended network. (In code, the WSSConfigManager likely loads phase4-truststore.jks – verify that it’s correctly used and protected).

Compliance with Peppol Security Profiles

Missing Timestamp in UserMessage – Low (Replay Risk): The AS4 UserMessage/MessageInfo/Timestamp is a required field that phase4 uses for logging and duplicate detection. In cases where neither the AS4 message timestamp nor the SBDH CreationDateTime are present, phase4 simply logs a warning and uses the current time ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=%2F%2F%20Neither%20in%20AS4%20nor,in%20SBDH)). This forgiving behavior could be abused by an attacker to omit timestamps, potentially complicating replay detection (each replayed message gets a new “current” timestamp on the receiver, bypassing simple replay checks). Affected code: Phase4PeppolServletMessageProcessorSPI warns “Incoming message does not contain a Timestamp… Using current date time” ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=%2F%2F%20Neither%20in%20AS4%20nor,in%20SBDH)) and continues processing. Recommendation: Follow the Peppol profile strictly: require the Timestamp element. If it’s missing, reject the message as non-compliant instead of auto-fixing it. This will enforce that senders include proper timestamps (which can be used to detect stale or replayed messages). If you do accept messages without it, implement a robust alternative for replay detection (e.g. check message IDs against a cache).

Lack of Replay Protection – Medium (Duplicate Message Processing): Phase4 does not appear to include a built-in message ID cache or nonce storage to prevent replay attacks. An attacker who intercepts an AS4 message could resend it verbatim at a later time; if the original receiver hasn’t implemented business-level duplicate handling, they might process the invoice twice. AS4 relies on the MessageId and ConversationId for idempotency, but enforcement is left to implementations. Affected component: There is a MetaAS4Manager.getTimestampMgr() and possibly a Message ID registry in phase4, but it might only be used for generating IDs, not storing received ones. Recommendation: Implement (or advise implementers to add) a replay detection layer. For example, maintain an in-memory or database store of recently seen MessageInfo/MessageId values and reject duplicates within a certain timeframe. This will prevent attackers from replaying valid signed messages to cause unintended effects (like duplicate invoice payments).

Peppol Profile Strictness – Low (Protocol Downgrade): The phase4 library aims to support multiple profiles (Peppol, e-SENS, etc.). Ensure that when running in Peppol mode, all Peppol-specific security rules are enforced: e.g. correct SOAP MPC, required encryption algorithm, specific certificate CN format, etc. Any laxness in profile enforcement could be abused. For instance, if a sender tries to use a non-Peppol service or action, will phase4 accept it? The code logs details like Service and Action ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=match%20at%20L3139%20LOGGER,%2B%20sService%20%2B)). If those don’t match the profile, it should reject the message. Affected code: The IncomingProfileSelector should match the incoming message to a profile definition. If not found, the message might be rejected or default to some profile. There was a debug log “No Source PMode present” ([phase4/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/phase4-peppol-servlet/src/main/java/com/helger/phase4/peppol/servlet/Phase4PeppolServletMessageProcessorSPI.java#:~:text=match%20at%20L3131%20LOGGER,No%20Source%20PMode%20present)) which suggests if it can’t find a configured agreement, it still proceeds. Recommendation: Configure explicit PModes for all expected scenarios. If a message doesn’t match any known profile (wrong service/action or missing agreements), do not process it. This prevents attackers from bypassing profile-specific security by sending a message that doesn’t trigger the profile rules.

Dependency and Configuration Security

Use of Updated Security Libraries – Good Practice: Phase4 uses Apache Santuario XMLSec 3.0.5 and WSS4J 3.0.4, which are relatively recent. This is good, as older versions had known CVEs (e.g. Santuario <3.0.3 had a private key info leak in logs ([CVE-2023-44483 Detail - NVD](https://nvd.nist.gov/vuln/detail/cve-2023-44483#:~:text=CVE,are%20vulnerable%20to%20an%20issue)), and WSS4J <3.0.3 had various WS-Security bypass issues). The chosen versions include fixes for those vulnerabilities. For example, WSS4J 3.0.4 addresses CVE-2024-34447 and others (related to secure Parts enforcement). Affected components: If any submodule or consuming project uses an older version of phase4 (e.g. 2.x), they should update to 3.x to get these fixes. Recommendation: Continue to keep security libraries updated. Monitor releases of WSS4J and XMLSec for critical fixes (Apache periodically announces patches for XML signature wrapping and encryption bypass issues). Also ensure BouncyCastle (if used for crypto) is up to date to avoid any known flaws in cryptographic primitives or ASN.1 parsing.

Logging of Sensitive Data – Low: Review logging to ensure no sensitive info is printed in production logs. By default, phase4’s logs appear to be mostly metadata. One potential issue is if the library logs the entire incoming SOAP or error with stack trace including message content. The snippet in issue #23 shows an exception with message content type ([no object DCH for MIME type application/soap+xml;charset=UTF-8 · Issue #23 · phax/phase4 · GitHub](#23)). Ensure things like passwords (if any) or private keys are never logged. The Santuario CVE-2023-44483 was about logging private key material in certain debug modes ([CVE-2023-44483 Detail - NVD](https://nvd.nist.gov/vuln/detail/cve-2023-44483#:~:text=CVE,are%20vulnerable%20to%20an%20issue)) – phase4 excludes OpenSAML (not used) and likely doesn’t log keys, but caution is warranted. Recommendation: Use conservative logging. The library already has FindBugs exclude configs, but as a deployer, run it in production mode (no debug logging for security events). If using the provided LoggingJAXBReadExceptionHandler, be mindful that it might log portions of the XML on parse errors – consider sanitizing or disabling that in sensitive environments.

Default Credentials/Keys in Test Code – Informational: The phase4-test module and the standalone demo come with example keystores and credentials (for testing). These are not meant for production (as noted by the maintainer). However, a developer might accidentally reuse them. For instance, if phase4-test war is deployed as-is, its private key and certificate are public. Affected code: The phase4-test webapp uses a known dummy certificate. Recommendation: Never use the test keys in production. Generate fresh AS4 keys and get them issued by the proper authority. This isn’t a vulnerability in the library per se, but a reminder for deployment security.

Conclusion and Remediation Summary

In summary, phase4 is a well-designed AS4 solution with support for multiple eDelivery profiles, but like any XML security software it must be configured correctly to be secure. Key recommendations include:

• Hardening XML parsing: disable external entities and enable secure processing to thwart XXE and XML bomb attacks.
• Imposing size limits: on incoming messages, attachments, and expansions to prevent denial-of-service by large or compressed payloads.
• Enforcing signatures and encryption: so that unsigned or unencrypted messages are rejected per the profile’s security policy ([How to enforce signature and encryption for receiving messages? · Issue #162 · phax/phase4 · GitHub](How to enforce signature and encryption for receiving messages? #162)). Always verify that the expected parts (SOAP body, attachments) are covered by the XML DSig.
• Strengthening signature validation: enable all anti-wrapping measures (unique ID enforcement ([Migration Troubleshooting - Platform 6](https://doc.p6.sidetrade.io/6.9.1/releases/migration/migration-troubleshooting/#:~:text=minKeySize%20DSA%201024%2C,noRetrievalMethodLoops)), strict reference matching) and use strong algorithms (avoid SHA-1 where possible).
• Validating certificates rigorously: only trust known CAs, check that sender certs match the intended sender (via SMP or config), and enable revocation checks to avoid trusting compromised keys ([Multi-Profile handling using Single Servlet different URL · phax phase4 · Discussion #273 · GitHub](Multi-Profile handling using Single Servlet different URL #273)).
• Improving compliance checks: require all mandatory fields (timestamps, etc.), implement replay detection, and strictly apply profile rules to every message.

By addressing the above issues, developers using phase4 can significantly improve the security of their AS4 implementations. The library maintainers have already made some changes (e.g. adding options to enforce security headers and excluding insecure dependencies ([phase4/pom.xml at master · phax/phase4 · GitHub](https://github.com/phax/phase4/blob/master/pom.xml#:~:text=%3C%21,))); it is crucial to use those features and keep the library up to date. With careful configuration, phase4 can be used to build an AS4 Access Point that is robust against attacks aiming to bring down the service, forge invoice documents, or steal data.

[phax]

@gbdevw Thank you very much for the report - very valuable and lot to digest and process! Detailed answers will follow

Would you mind telling me via PM whom I'm owing the pleasure of sponsoring this report? I really want to say thank you.

[gbdevw]

Hello @phax,

You can find me here if you’d like to connect:
🔗 https://www.linkedin.com/in/guillaume-braibant-905861152/

Let me clarify the intent behind the audit:

While my tone may seem blunt, my motivation is genuine — I’m deeply concerned by the architectural flaws of the PEPPOL network, especially in terms of security. These are issues that go beyond implementation and touch on core design assumptions. That said, I fully recognize the scale and adoption of your project — which is precisely why I started with it.

When I saw that phase4 was among the most widely used libraries by PEPPOL Access Point Providers, I naturally became curious. And since the code involves XML handling, I began with the usual suspects: classic vulnerabilities like XML bombs and unsafe compression. Finding signs of potential issues, I have asked ChatGPT (in full transparency) to perform an assisted static audit to identify weaknesses ranging from DoS and data exfiltration to signature bypasses and trust violations. Invoices are sensitive, legally binding documents — and often directly tied to payments. Tampering with them can result in both serious harm and substantial illicit gains.

Even though I’m currently working on an alternative to PEPPOL, I chose to share the report openly because the risks are real and could impact many businesses.

Most of the issues raised — such as insecure XML parsing — are well-documented and preventable with proper configurations. Unfortunately, many providers use phase4 without auditing or hardening their setup, and that’s where the danger lies.

If I may suggest:

• Ship the library with secure settings by default
• A PEPPOL-specific hardening guide for implementers could go a long way. Many vulnerabilities could be mitigated at the deployment level with sane defaults and awareness.

Thanks again for your work and openness.

Looking forward to your feedback.

Best regards,
Guillaume Braibant

[phax]

So, let me respond piece by piece.

On XML Processing Vulnerabilities

All XML reading that happens inside phase4 should be using the DOMReader class from ph-commons project. This class makes sure, that the following DocumentBuilderFactory properties are set by default (https://github.com/phax/ph-commons/blob/master/ph-xml/src/main/java/com/helger/xml/XMLFactory.java#L137) to ensure safe processing:

• Secure Processing to true
• Disallow Document Type Declaration to true
• External General Entities to false
• External Parameter Entities to false
• Load External DTD to false

Those settings make sure XML External Entity (XXE) Injection and XML Entity Expansion (“Billion Laughs”) cannot happen.

For all XML Schemas used inside phase4, local copies are used. There should be no access to external XML schema (parts) - everything is shipped as part of the application. This should avoid the Unbounded XML Schema Validation Loops mention. XML Schemas handled are SOAP 1.2, Standard Business Document (SBD/SBDH) as well as ebMS Messaging (AS4 User Message, AS4 Signal Message etc.). Payload specific XSDs like UBL Invoice or UBL Application Response are usually read in the client code.
See the used XSDs:

• https://github.com/phax/phase4/tree/master/phase4-lib/src/main/resources/external/schemas
• https://github.com/phax/ph-sbdh/tree/master/src/main/resources/external/schemas/sbdh
• https://github.com/phax/ph-xsds/tree/master/ph-xsds-xml/src/main/resources/schemas

On Attachment and Compression Handling

This topic is a bit harder to respond to, because it gives more degrees of freedom :)
In general phase4 tries to be capable of receiving messages of all size, but that is indeed an area that needs some work, because it uses size capped byte arrays in certain places. OpenPeppol doesn't require maximum upper limits in their SLAs but instead they require a minimum supported size per Access Point.

Looking at the code it is clearly visible, that reception of files larger than 2 GB will currently not work. I tried to improve the processing of large files in v3.1.0 by not doing everything in memory but by relying on temporary files to handle stuff. However, there is a caveat than an existing callback requires providing the SBDH payload as byte[]. So this can only be dealt with in the next major version, when these deprecated methods are removed.

To be continued