CVE-2025-15467 - libssl3t64, openssl

[wutianchen]

https://us-east-1.console.aws.amazon.com/inspector/v2/home?region=us-east-1#/findings/container-image/arn%3Aaws%3Aecr%3Aus-east-1%3A819957634547%3Arepository%2Fdatasqrl%2Fflink-sql-runner%2Fsha256%3Ae45685ab21e30ee949cdaf97f4e0de0f50e6370374166abf8f5f970169129e6c

CVE-2025-15467 - libssl3t64, openssl

Finding ID: arn:aws:inspector2:us-east-1:819957634547:finding/dea440a8168de74b2891d966feadf90b
Issue summary: Parsing CMS AuthEnvelopedData message with maliciously crafted AEAD parameters can trigger a stack buffer overflow. Impact summary: A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution. When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without verifying that its length fits the destination. An attacker can supply a crafted CMS message with an oversized IV, causing a stack-based out-of-bounds write before any authentication or tag verification occurs. Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable. Because the overflow occurs prior to authentication, no valid key material is required to trigger it. While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-base

[velo]

This is a segurity issue we are inheriting from flink 2.2 base image.

If this is extreme critical, we can build our own flavor of flink image. But that is going against the flow. We should find a path to delegate the problem to flink.

Also, security issues should be reported under the security tab to not expose people using this image to a 0-day (if that is possiblem, I'm not sure how this can be exploited.

[velo]

https://github.com/DataSQRL/flink-sql-runner/security/advisories