CVE-2026-59300

Overview

Spring Cloud Function is a Spring project that lets developers express business logic as plain java.util.function beans and then run those beans unchanged as standalone applications, web endpoints, stream listeners, or serverless functions. Platform adapters wrap a function for a specific runtime, and the AWS adapter supplies both the standard AWS Lambda handler integration and support for the AWS Lambda custom runtime, in which the application itself starts an event loop that polls the Lambda runtime API for invocation events.

An Information Exposure vulnerability (CVE-2026-59300) has been identified in the custom runtime components of the Spring Cloud Function AWS adapter, which allows attackers with access to application logs to read the entire AWS Lambda process environment, including access keys, session tokens, and any other secrets that the platform or the deployment injects as environment variables.

This issue affects the AWS Lambda custom runtime support of Spring Cloud Function.

Details

Module Info

• Product: Spring Cloud Function
• Affected packages: org.springframework.cloud:spring-cloud-function-adapter-aws
• Affected versions: >=3.1.1 <=4.1.6, >=4.2.0 <=4.2.7, >=4.3.0 <=4.3.4, >=5.0.0 <5.0.4
• GitHub repository: https://github.com/spring-cloud/spring-cloud-function
• Published packages: https://central.sonatype.com/artifact/org.springframework.cloud/spring-cloud-function-adapter-aws
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Cloud Function: patched releases for the 3.1.x, 3.2.x, 4.1.x, 4.2.x and 4.3.x lines, based on OSS 3.1.7, 3.2.12, 4.1.6, 4.2.4 and 4.3.4
  • OSS Spring Cloud Function 5.0.4

Vulnerability Info

This Low-severity vulnerability is found in the org.springframework.cloud:spring-cloud-function-adapter-aws package in the AWS Lambda custom runtime support of Spring Cloud Function.

Two components of the AWS adapter dumped the complete process environment into the application log as a diagnostic aid. CustomRuntimeInitializer.initialize runs as an application context initializer on every startup of an AWS adapter application, and CustomRuntimeEventLoop.eventLoop runs when the application is started under the Lambda custom runtime. Both called System.getenv() and concatenated the resulting map into a log message, guarded only by a log level check:

// CustomRuntimeInitializer.java
@Override
public void initialize(GenericApplicationContext context) {
    Environment environment = context.getEnvironment();
    if (logger.isDebugEnabled()) {
        logger.debug("AWS Environment: " + System.getenv());
    }
    ...
}

// CustomRuntimeEventLoop.java
private void eventLoop(ConfigurableApplicationContext context) {
    Environment environment = context.getEnvironment();
    logger.info("Starting spring-cloud-function CustomRuntimeEventLoop");
    if (logger.isDebugEnabled()) {
        logger.debug("AWS LAMBDA ENVIRONMENT: " + System.getenv());
    }
    ...
}

The only precondition is that DEBUG logging is enabled for these classes, which is a routine configuration while diagnosing a function deployment and is commonly switched on globally through a root logger level rather than per class. There was no opt-in, no allow list, and no redaction of sensitive keys, so the dump included the AWS Lambda credential variables that the execution environment injects, such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN, alongside any application secrets supplied as Lambda environment variables. Because Lambda writes standard output to CloudWatch Logs, those values were persisted to a log store whose read permissions are usually broader than the permissions granted over the secrets themselves, exposing them to operators, log shipping pipelines, and downstream log analysis systems that were never intended to hold credential material. The remediated code keeps the diagnostic behind an explicit opt-in property and lowers it to TRACE, so the environment is never written unless an operator deliberately requests it.

This vulnerability was introduced in 2021 with Spring Cloud Function 3.1.1.

Mitigation

Only recent versions of Spring Cloud Function receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Cloud Function.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.