AWS's extended SQS and SNS clients inherit Jackson pins from a library last released in March 2024

The Jackson exposure in AWS's extended clients is narrower than a scanner report suggests. Christoph Sens, who ported the clients to Kotlin, wrote that "whether an advisory is exploitable depends on how Jackson is used, and the extended clients only (de)serialize a small pointer object" ^[8][20]. The advisories include bypasses of Jackson's polymorphic type validation and a denial-of-service bug in the async parser ^[4]. Seven advisories is a lot of paperwork for a small pointer. The paperwork also repeats: "every dependency scanner flags these versions, someone has to triage the findings again and again," Sens wrote ^[9].

The pin sits one layer below the clients. July's SQS release left it in place ^[5]. Neither the common library nor the SNS client has shipped since March 2024 ^[6]. By the September 2026 advisory count, the component that owns the Jackson versions had gone 30 months without a release ^[1].

Java teams can override Jackson in their own build ^[9]. Sens's objection is that "forcing newer Jackson versions under a library that was never tested against them is its own risk" ^[9]. The Java libraries also compile for Java 8 and keep separate sync and async classes with largely duplicated pass-through code ^[11]. His answer is removal. "Removing Jackson from this code path makes the question disappear," he wrote ^[10].

The port gets substitution right. SqsExtendedClient is an SqsClient, so it goes anywhere a plain client goes ^[13]. Because aws-sdk-kotlin clients are suspend-based, one class replaces the Java pair of AmazonSQSExtendedClient and AmazonSQSExtendedAsyncClient ^[13][11]. Below the size threshold, a message goes straight to SQS. Above it, the body goes to S3 and the queue carries a small JSON pointer plus an ExtendedPayloadSize attribute ^[14]. Receive fetches the object. Delete removes it too, through cleanupS3Payload, on by default ^[15].

SNS has no receive side, so a topic that fans out to SQS with raw message delivery relies on sqsoverflow's client at the subscriber ^[19]. I'd set cleanupS3Payload explicitly on those queues. If several subscribers resolve pointers to one S3 object, the default lets the first delete remove it before the others have fetched it ^[15][19].

The size limits moved under both libraries. SQS has accepted 1 MiB, body plus attributes, since August 2025, up from 256 KiB ^[16], a fourfold rise ^[2]. SNS still defaults to 256 KiB, though since September 2026 a topic can take 1 MiB once its MaximumMessageSize attribute is raised ^[17]. sqsoverflow offloads at 1 MiB by default and snsoverflow at 256 KiB, both adjustable through payloadSizeThreshold ^[18].

For a Kotlin service, I think the port is the right call. The Java clients wrap the AWS SDK for Java v2 clients, so they never fit aws-sdk-kotlin ^[7]. The cost is taking on sqsoverflow 1.1.0, a library one developer ported, in place of AWS's own ^[12][7].