Update dependency org.assertj:assertj-core to v3.27.7 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.assertj:assertj-core (source)	3.23.1 → 3.27.7
org.assertj:assertj-core (source)	3.26.3 → 3.27.7

---

AssertJ has XML External Entity (XXE) vulnerability when parsing untrusted XML via isXmlEqualTo assertion

CVE-2026-24400 / GHSA-rqfh-9r24-8c9r

More information

Details

An XML External Entity (XXE) vulnerability exists in org.assertj.core.util.xml.XmlStringPrettyFormatter: the toXmlDocument(String) method initializes DocumentBuilderFactory with default settings, without disabling DTDs or external entities. This formatter is used by the isXmlEqualTo(CharSequence) assertion for CharSequence values.

An application is vulnerable only when it uses untrusted XML input with one of the following methods:

• isXmlEqualTo(CharSequence) from org.assertj.core.api.AbstractCharSequenceAssert
• xmlPrettyFormat(String) from org.assertj.core.util.xml.XmlStringPrettyFormatter

Impact

If untrusted XML input is processed by the methods mentioned above (e.g., in test environments handling external fixture files), an attacker could:

• Read arbitrary local files via file:// URIs (e.g., /etc/passwd, application configuration files)
• Perform Server-Side Request Forgery (SSRF) via HTTP/HTTPS URIs
• Cause Denial of Service via "Billion Laughs" entity expansion attacks

Mitigation

isXmlEqualTo(CharSequence) has been deprecated in favor of XMLUnit in version 3.18.0 and will be removed in version 4.0. Users of affected versions should, in order of preference:

1. Replace isXmlEqualTo(CharSequence) with XMLUnit, or
2. Upgrade to version 3.27.7, or
3. Avoid using isXmlEqualTo(CharSequence) or XmlStringPrettyFormatter with untrusted input.

XmlStringPrettyFormatter has historically been considered a utility for isXmlEqualTo(CharSequence) rather than a feature for AssertJ users, so it is deprecated in version 3.27.7 and removed in version 4.0, with no replacement.

References

• CWE-611: Improper Restriction of XML External Entity Reference
• OWASP XXE Prevention Cheat Sheet

Severity

• CVSS Score: 8.2 / 10 (High)
• Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:H/SI:N/SA:N

References

• https://github.com/assertj/assertj/security/advisories/GHSA-rqfh-9r24-8c9r
• https://github.com/assertj/assertj/commit/85ca7eb6609bb179c043b85ae7d290523b1ba79a
• https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
• https://github.com/assertj/assertj/releases/tag/assertj-build-3.27.7
• https://nvd.nist.gov/vuln/detail/CVE-2026-24400
• https://github.com/advisories/GHSA-rqfh-9r24-8c9r

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Never, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonar-review-alpha]

Summary

⚠️ The PR description exceeded the analysis limit and was truncated. The review may not reflect all context.

Single dependency version bump: org.assertj:assertj-core upgraded from 3.26.3 to 3.27.7 (test scope). This addresses CVE-2026-24400, an XXE vulnerability in AssertJ's XML parsing methods (isXmlEqualTo and XmlStringPrettyFormatter). The fix hardens XML parsing to prevent external entity exploitation. This is a patch-level security update with no code changes required.

What reviewers should know

Review checklist:

• Verify the project doesn't use the affected XML assertion methods (isXmlEqualTo or XmlStringPrettyFormatter). If it does, assess whether they process untrusted XML input and consider the migration path to XMLUnit mentioned in the advisory.
• This is a straightforward dependency bump with no code modifications—focus on confirming the version is correct and compatible.
• The vulnerability is high-severity (CVSS 8.2) but only impacts code that explicitly calls the vulnerable XML methods with external/untrusted input, typically in test fixtures.

No further action needed unless the codebase actively uses the deprecated XML methods with potentially untrusted sources.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[hashicorp-vault-sonar-prod]

Renovate Jira issue ID: JAVASE-216

[sonar-review-alpha]

Clean security dependency update. No functional code changes. The project does not use isXmlEqualTo() or XmlStringPrettyFormatter anywhere, so it was never directly exposed to CVE-2026-24400 — this upgrade is still correct as a precautionary measure and keeps the dependency current.

One structural maintenance issue is worth fixing alongside this: the version pinning in checks-test-sources/pom.xml caused the pre-PR drift (3.23.1 there vs 3.26.3 in the root). Removing the explicit version tag there would let it inherit from the root's <dependencyManagement> like all other modules do, making future bumps a single-file change.

🗣️ Give feedback

[sonar-review-alpha]

Logic duplication: The assertj-core version is managed centrally in the root pom.xml <dependencyManagement> (line 247), and also pinned explicitly here. This caused the two declarations to drift out of sync pre-PR (3.23.1 here vs 3.26.3 in root), requiring this dual-file update.

The <scope>provided</scope> override below can be kept without specifying a version — Maven resolves the version from <dependencyManagement> independently of scope overrides. Removing the <version> tag here means future bumps only require touching pom.xml.

Suggested change

	<artifactId>assertj-core</artifactId>
	<version>3.23.1</version>
	<version>3.27.7</version>
	<artifactId>assertj-core</artifactId>

• Mark as noise

[sonar-review-alpha]

The security fix itself is correct and complete for the modules that inherit their version from root dependencyManagement. However, the version drift in java-symbolic-execution-checks-test-sources/pom.xml is not addressed, leaving that module pinned to the vulnerable 3.23.1.

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube