fix(security): upgrade arangodb-java-driver to 7.25.0 to remediate CVE-2025-52999#41789
fix(security): upgrade arangodb-java-driver to 7.25.0 to remediate CVE-2025-52999#41789
Conversation
WalkthroughArangoDB Java Driver upgraded to 7.25.0. Query calls updated to new overloads using ChangesArangoDB Driver 7.x Upgrade
🎯 3 (Moderate) | ⏱️ ~20 minutes
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/server/appsmith-plugins/arangoDBPlugin/src/test/java/com/external/plugins/ArangoDBPluginTest.java (1)
152-165: ⚡ Quick winAssert the
Longcoercion on the read path.These fixtures now set up the JSON integer case that
USE_LONG_FOR_INTSis meant to preserve, but the read-query assertions still only checkasText(). That would keep passing if deserialization regressed back toInteger, so the main compatibility goal of this PR is not directly covered in CI.🧪 Suggested assertion for
testExecuteReadQuery()+import com.fasterxml.jackson.core.JsonParser; ... assertEquals("Kierra Gentry", node.get("name").asText()); assertEquals("F", node.get("gender").asText()); assertEquals("40", node.get("age").asText()); + assertEquals(JsonParser.NumberType.LONG, node.get("age").numberType());🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/server/appsmith-plugins/arangoDBPlugin/src/test/java/com/external/plugins/ArangoDBPluginTest.java` around lines 152 - 165, The test currently inserts a large integer (luckyNumber = 987654321L) but only asserts the read result via asText(); update testExecuteReadQuery to explicitly assert the numeric field is deserialized as a Long on the read path (e.g., retrieve the node/result for "luckyNumber" and assert its Java type or value equals a Long with the same value), ensuring the fixture from collection.insertDocuments triggers USE_LONG_FOR_INTS behavior and the assertion fails if deserialization reverts to Integer.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@app/server/appsmith-plugins/arangoDBPlugin/src/main/java/com/external/utils/ArangoDBErrorUtils.java`:
- Around line 71-74: The current check in ArangoDBErrorUtils that maps errors to
DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG uses the generic "Cannot contact any
host" string and thus collapses all connectivity failures into an "invalid
hostname" error; update the logic in ArangoDBErrorUtils (the block that inspects
externalErrorMessage and sets DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG) to only
treat true DNS/name-resolution failures as hostname errors by: 1) inspecting the
exception cause chain (externalError.getCause() recursively) for an actual
UnknownHostException type, and 2) matching only DNS-specific textual signals
(e.g., "UnknownHostException", "Name or service not known", "nodename nor
servname", etc.), and stop using a blanket match on "Cannot contact any host".
---
Nitpick comments:
In
`@app/server/appsmith-plugins/arangoDBPlugin/src/test/java/com/external/plugins/ArangoDBPluginTest.java`:
- Around line 152-165: The test currently inserts a large integer (luckyNumber =
987654321L) but only asserts the read result via asText(); update
testExecuteReadQuery to explicitly assert the numeric field is deserialized as a
Long on the read path (e.g., retrieve the node/result for "luckyNumber" and
assert its Java type or value equals a Long with the same value), ensuring the
fixture from collection.insertDocuments triggers USE_LONG_FOR_INTS behavior and
the assertion fails if deserialization reverts to Integer.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 489fc5f9-9fdb-4338-9201-f2dda6020938
📒 Files selected for processing (4)
app/server/appsmith-plugins/arangoDBPlugin/pom.xmlapp/server/appsmith-plugins/arangoDBPlugin/src/main/java/com/external/plugins/ArangoDBPlugin.javaapp/server/appsmith-plugins/arangoDBPlugin/src/main/java/com/external/utils/ArangoDBErrorUtils.javaapp/server/appsmith-plugins/arangoDBPlugin/src/test/java/com/external/plugins/ArangoDBPluginTest.java
| String externalErrorMessage = externalError.getMessage(); | ||
| if (externalErrorMessage != null | ||
| && (externalErrorMessage.contains("UnknownHostException") | ||
| || externalErrorMessage.contains("Cannot contact any host"))) { |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In arangodb-java-driver 7.x, is the top-level message "Cannot contact any host" specific to UnknownHostException, or is it also used for other connection failures such as timeouts, TLS handshake failures, or connection refused?
💡 Result:
In arangodb-java-driver 7.x, the top-level message “Cannot contact any host” / “Was not able to connect to any host” is not specific to UnknownHostException. It is a general “all hosts failed” wrapper that can be thrown for multiple kinds of connection failures (e.g., DNS/host reachability problems as well as other TCP/SSL/connectivity issues). Evidence: - When ArangoDB is unreachable, users report the driver throwing com.arangodb.ArangoDBException with message “Was not able to connect to any host” after connection attempts fail (alongside lower-level connection exceptions like ConnectException). [1] - In that same report, the lower-level failure can include “or SSL Handshake failed”, demonstrating that the driver’s top-level “connect to any host” failure is used even when the underlying cause is SSL/TLS handshake failure—not just DNS/UnknownHostException. [1] - The driver’s host failover behavior is designed around “first host is used … When this host is not reachable the next host … is used,” which implies the final “any host” failure is about reachability/connection establishment broadly, not a single exception type. [2] So, you should treat “Cannot contact any host” as “the driver could not establish a connection to any configured host,” and inspect the underlying cause/stacktrace/logs for the specific failure (UnknownHostException vs timeouts vs TLS handshake vs connection refused). The driver has changed its HTTP client to Vert.x WebClient in v7, but the existence of this generic wrapper behavior is evidenced by the reported exception handling. [3][2][1]
Citations:
- 1: Exceptions issues when driver connects to unreachable ArangoDB arangodb/arangodb-java-driver#270
- 2: https://docs.arangodb.com/3.13/develop/drivers/java/reference-version-7/driver-setup
- 3: https://docs.arangodb.com/3.13/develop/drivers/java/reference-version-7/changes-in-version-7
Don't collapse the generic v7 connectivity error into "invalid hostname".
The message "Cannot contact any host" is a generic wrapper used by arangodb-java-driver 7.x for all connection failures—not just DNS issues. It covers SSL/TLS handshake failures, timeouts, connection refused, and general host reachability problems. With this fallback, these non-hostname errors will be rewritten to DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG whenever the underlying cause type is lost in wrapping.
🔎 Narrow the fallback to DNS-specific signals only
- if (externalErrorMessage != null
- && (externalErrorMessage.contains("UnknownHostException")
- || externalErrorMessage.contains("Cannot contact any host"))) {
+ if (externalErrorMessage != null && externalErrorMessage.contains("UnknownHostException")) {
return DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| String externalErrorMessage = externalError.getMessage(); | |
| if (externalErrorMessage != null | |
| && (externalErrorMessage.contains("UnknownHostException") | |
| || externalErrorMessage.contains("Cannot contact any host"))) { | |
| String externalErrorMessage = externalError.getMessage(); | |
| if (externalErrorMessage != null && externalErrorMessage.contains("UnknownHostException")) { | |
| return DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG; | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app/server/appsmith-plugins/arangoDBPlugin/src/main/java/com/external/utils/ArangoDBErrorUtils.java`
around lines 71 - 74, The current check in ArangoDBErrorUtils that maps errors
to DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG uses the generic "Cannot contact any
host" string and thus collapses all connectivity failures into an "invalid
hostname" error; update the logic in ArangoDBErrorUtils (the block that inspects
externalErrorMessage and sets DS_HOSTNAME_MISSING_OR_INVALID_ERROR_MSG) to only
treat true DNS/name-resolution failures as hostname errors by: 1) inspecting the
exception cause chain (externalError.getCause() recursively) for an actual
UnknownHostException type, and 2) matching only DNS-specific textual signals
(e.g., "UnknownHostException", "Name or service not known", "nodename nor
servname", etc.), and stop using a blanket match on "Cannot contact any host".
…E-2025-52999 CVE-2025-52999 (jackson-core deeply-nested-JSON DoS, CVSS 8.7) was reachable through the arangoDBPlugin runtime because arangodb-java-driver 6.12.3 transitively pulled in com.arangodb:velocypack:2.5.3, which shades a relocated copy of com.fasterxml.jackson.core:jackson-core:2.11.3 inside its jar. The shaded classes were used by velocypack to convert ArangoDB responses, so a deeply-nested JSON payload from a user-configured ArangoDB server could trigger StackOverflowError on the parsing thread. Industry-standard remediation: upgrade the parent library, not the transitive. Driver 7.25.0 removes velocypack from the default transitive set, so the shaded vulnerable jar disappears entirely. The replacement runtime classpath ships jackson-core 2.17.0 (un-shaded, well above the 2.15.0 fix threshold). Driver 7.5.0+ also auto-configures Jackson StreamReadConstraints as defense-in-depth, directly hardening the per-request DoS vector. Changes: - pom.xml: bump arangodb-java-driver 6.12.3 -> 7.25.0; drop unused org.apache.httpcomponents:httpclient (v7 uses Vert.x WebClient internally) - ArangoDBPlugin.java: migrate to v7 query() argument order, rename useProtocol() -> protocol(), switch wire format from Protocol.HTTP_VPACK to Protocol.HTTP2_JSON (the v7 default), and register a custom JacksonSerde with USE_LONG_FOR_INTS so query results preserve Long for integer values (matches the v6 VPACK behavior so the structure-tree column types stay stable for users) - ArangoDBErrorUtils.java: walk the cause chain for UnknownHostException and also detect the v7 "Cannot contact any host" message, so the user-visible bad-host error stays the same as v6 - ArangoDBPluginTest.java: align fixture with the protocol/serde change and adjust two test-fixture values so the inserted documents match the collection schema cleanly under the v7 JSON serde (no production impact) Validation: - mvn dependency:tree on arangoDBPlugin: arangodb-java-driver:7.25.0, jackson-core:2.17.0; velocypack absent - target/lib scan: zero jars contain META-INF jackson-core/pom.properties at version 2.11.3 (the shaded copy is gone) - mvn -pl arangoDBPlugin -am test: 207/207 passing including all testcontainer-backed ArangoDB integration tests against arangodb:3.7.12 - live smoke test against arangodb:3.11.14: connect, read AQL, write AQL (writesExecuted/Ignored), and getCollections all succeed; numeric values return as Long as before Refs: CVE-2025-52999, CVSS 8.7, jackson-core <2.15.0
subrata71
force-pushed
the
fix/cve-2025-52999-jackson-core
branch
from
ef9e0a5 to
a15e212
Compare
Update: Fixed PluginClassLoader / parent-classloader collisionThe shadow EE PR (appsmithorg/appsmith-ee#9045) had all 60 Cypress shards failing at the same step ( Root cause (from the EE deploy-preview pod logs in
|
1 participant
Summary
Remediates CVE-2025-52999 (jackson-core deeply-nested-JSON DoS, CVSS 8.7 High) in the arangoDBPlugin runtime by upgrading the parent library that bundles the vulnerable jackson-core, rather than overriding the transitive dependency.
Root cause (verified)
arangodb-java-driver:6.12.3(June 2021, EOL) transitively pullscom.arangodb:velocypack:2.5.3, which shades a relocated copy ofcom.fasterxml.jackson.core:jackson-core:2.11.3at the package pathcom.arangodb.velocypack.deps.com.fasterxml.jacksoninside the velocypack jar. The relocatedMETA-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.propertiesdeclaresversion=2.11.3— that is what Docker Scout detects at/opt/appsmith/server/mongo/plugins/arangodbPlugin-1.0-SNAPSHOT/lib/. velocypack uses these shaded classes to convert ArangoDB responses on the parsing path, so a deeply-nested JSON payload from a user-configured ArangoDB server can triggerStackOverflowErrorper the original customer justification.Fix approach (industry-standard, no transitive override)
Upgrade the parent library:
arangodb-java-driver6.12.3→7.25.0(Jan 2026, latest stable). Driver 7.x:velocypackfrom the default transitive set (only used when HTTP_VPACK content type is selected, which we no longer use after switching to the v7 defaultHTTP2_JSON). The shaded vulnerable jar disappears entirely.jackson-core:2.20.0via thecom.arangodb:jackson-serde-jsonmodule, resolved to2.17.0after parent-managedjackson-bom.version. Both are well above the 2.15.0 fix threshold.StreamReadConstraints(added in driver 7.5.0) as defense-in-depth, directly hardening the per-request DoS vector named in the customer justification.No
<dependencyManagement>overrides, no transitive pinning, no shading workarounds.Changes
pom.xml— bump driver6.12.3→7.25.0; drop now-unusedorg.apache.httpcomponents:httpclient(v7 uses Vert.x WebClient internally; verified zero direct usages in plugin source viarg "org\.apache\.http").ArangoDBPlugin.java— migrate to v7 API:db.query(query, null, null, Map.class)→db.query(query, Map.class, null, null)(parameter order changed in v7)useProtocol(...)→protocol(...)(renamed in v7)Protocol.HTTP_VPACK→Protocol.HTTP2_JSON(the v7 default; avoids needing thejackson-serde-vpackextra module)JacksonSerdewithUSE_LONG_FOR_INTSso query results preserveLongfor integer values, matching v6 VPACK behavior. This keeps the structure-tree column types stable for users (e.g., a small integer likeage=20still surfaces asLong, notInteger).ArangoDBErrorUtils.java— walk the cause chain forUnknownHostExceptionand also detect the v7Cannot contact any hostmessage, so the user-visible bad-host error message stays the same as v6.ArangoDBPluginTest.java— align fixture with the protocol/serde change; replace test-fixtureLocalDate.of(...)with aMapmatching the test's own JSON Schema, andBigDecimal(...)with aStringfor the currency field (more realistic; doesn't depend on driver wire-format quirks). No production impact.Validation
mvn dependency:tree— vulnerable deps absentvelocypackis no longer present.jackson-core:2.17.0(above the 2.15.0 fix threshold).Runtime
lib/jar scan — vulnerable shaded copy goneThe only
jackson-core/pom.propertiesinlib/now belongs to the un-shadedjackson-core-2.17.0.jaritself.Tests — all green
mvn -pl appsmith-plugins/arangoDBPlugin -am test: 207/207 passing (181 from interfaces parent + 26 from the plugin module, including the 4 testcontainer-backed end-to-end ArangoDB integration tests againstarangodb/arangodb:3.7.12— connect, read AQL, write AQL withwritesExecuted/Ignored, and structure discovery).arangodb/arangodb:3.11.14: all four production code paths exercised; numeric values come back asLongas before; string values remainString.CE→EE sync simulation
Cherry-pick simulation shows a small mechanical conflict in the import block of
ArangoDBPlugin.java(EE has additional Jackson imports for its EE-onlygetConfigurationContentmethod). Resolution is a union of imports. A pre-staged shadow EE PR with the resolved version will be opened immediately after this CE PR.Test plan
RETURNquery, verify result shape and structure-tree column types match pre-fix (numeric →Long).Refs: CVE-2025-52999, customer-shared "Affected, fix planned" justification.
Summary by CodeRabbit
Bug Fixes
Chores
Caution
🔴 🔴 🔴 Some tests have failed.
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/25637088241
Commit: a15e212
Cypress dashboard.
Tags: @tag.All
Spec:
The following are new failures, please fix them before merging the PR:
- cypress/e2e/Sanity/Datasources/Arango_Basic_Spec.ts
List of identified flaky tests.Mon, 11 May 2026 02:23:34 UTC
Automation
/ok-to-test tags="@tag.All"