Remove AWS SDK v1 from the AWS plugin + bump amqp-client to fix 3 CVEs (PR #27074, targets 7.1)

Development
1

Hi all — opened a PR against 7.1 and wanted to give some context and get eyes on it before it goes further: Remove AWS SDK v1 from the AWS plugin and bump amqp-client to 5.34.0 by pranavp26 · Pull Request #27074 · Graylog2/graylog2-server · GitHub

What’s in it

Two independent fixes bundled on one branch:

1. Remove AWS SDK v1 from the legacy AWS plugin

org.graylog.aws.* (the instance-name-lookup processor and the CloudTrail input’s region/proxy handling) was the last part of the codebase still depending on AWS SDK v1 (com.amazonaws). Everything else — Kinesis, CloudWatch, S3 GeoIP, SQS/SNS, and even the rest of the CloudTrail input itself — was already on SDK v2. This closes that gap:

  • AWSAuthProvider now implements SDK v2’s AwsCredentialsProvider, delegating to AWSAuthFactory (the same factory the rest of the AWS integrations already use) instead of hand-rolling v1 credential logic.
  • InstanceLookupTable’s EC2 client moves from AmazonEC2Client (v1) to Ec2Client (v2) — same business logic, just the v2 API surface.
  • Added a com.amazonaws:aws-java-sdk-* ban to the dependency enforcer rules so v1 can’t quietly come back.

AWS SDK v1 has been in maintenance mode past its announced EOL, so this seemed worth doing on its own merits even outside of any specific CVE.

2. Bump com.rabbitmq:amqp-client 5.29.0 → 5.34.0

Fixes three CVEs in the RabbitMQ Java client used by the AMQP input:

  • CVE-2026-63335 — malformed body frame triggers a raw exception (DoS)
  • CVE-2026-63336 — ConnectionFactory.useSslProtocol() defaults to a trust-everything TLS manager with no hostname verification (MITM). This one’s directly reachable in our own code — AmqpConsumer.java calls exactly this overload whenever TLS is enabled on an AMQP input.
  • CVE-2026-69220 — unbounded recursion parsing nested AMQP tables lets a malicious/compromised broker crash the client with a pre-auth StackOverflowError

Why now / why bundled

Different motivations, same branch for convenience — happy to split into two PRs if maintainers would prefer that.

Testing

  • Clean compile + clean test-compile with license headers, forbiddenapis, and the dependency enforcer (including the new ban) all passing
  • Full org.graylog.aws.* unit-test suite: 39/39 passing
  • AmqpTransportIT against a real RabbitMQ container (Testcontainers): 2/2 passing
  • For the AWS side, since none of this had integration-test coverage even on v1: ran a manual smoke test against a real EC2 instance — launched a tagged t3.micro, ran InstanceLookupTable directly against it, confirmed it correctly resolved both the instance’s private and public IP to its Name tag via the live describeNetworkInterfaces/describeInstances calls, then tore the instance down
  • Confirmed via grep/mvn dependency:tree that no com.amazonaws:aws-java-sdk-* references remain anywhere (the one leftover com.amazonaws-groupId artifact, dynamodb-lock-client, is unrelated — pulled in transitively by the Kinesis Client Library, and is itself built entirely on SDK v2)

One user-visible thing worth flagging: AWS’s own SDK v2 region metadata uses different display text than v1 did (e.g. "EU (London)" → "Europe (London)"), which shows up in the AWS plugin’s region dropdowns. Not a bug in the migration — just AWS changing their own naming between SDK versions — but wanted to call it out explicitly rather than have it be a surprise in review.

Would appreciate any early feedback, especially on whether bundling the two changes is fine or should be split, and whether the AWS side needs more than the manual smoke test before merging.

1 Like
2

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.