Timhess

**Name of the Vulnerable Software and Affected Versions** Steeltoe.Management.Endpoint versions prior to 4.2.0 Steeltoe.Management.EndpointCore versions prior to 3.4.0 **Description** The `Sanitizer` component in the Environment actuator redacts configuration values by matching key names against a suffix list. However, the default list does not cover the standard .NET pattern `ConnectionStrings:<name>` or Steeltoe Connectors' `Steeltoe:Client:<type>:Default:ConnectionString`. Because there is no value-based scrubbing, full connection string values, including embedded `Password=` and `user:pass@host` segments, are returned verbatim in the '/actuator/env' endpoint responses. **Recommendations** Update Steeltoe.Management.Endpoint to version 4.2.0. Update Steeltoe.Management.EndpointCore to version 3.4.0. Remove `env` from the actuator exposure list. Add `.*connectionstring.*` to `KeysToSanitize` as a defense-in-depth measure. Require authorization on actuator endpoints.

**Name of the Vulnerable Software and Affected Versions** Steeltoe.Security.Authentication.CloudFoundryBase versions prior to 3.4.0 Steeltoe.Security.Authentication.JwtBearer versions prior to 4.2.0 Steeltoe.Security.Authentication.OpenIdConnect versions prior to 4.2.0 **Description** The JWT signing key cache in the `TokenKeyResolver` function uses `kid` as the sole cache key without namespacing by authority. In applications utilizing multiple `JwtBearer` schemes that point to different identity providers, a key retrieved for one scheme may satisfy token validation for another. Furthermore, cached keys lack an expiration mechanism, meaning rotated or revoked keys continue to be trusted until the application process is restarted. **Recommendations** Update Steeltoe.Security.Authentication.CloudFoundryBase to version 3.4.0. Update Steeltoe.Security.Authentication.JwtBearer to version 4.2.0. Update Steeltoe.Security.Authentication.OpenIdConnect to version 4.2.0. In multi-scheme deployments, configure only one `JwtBearer` scheme per application when different identity providers are required. Restart the application process after an identity provider signing key rotation to clear stale cached keys.

**Name of the Vulnerable Software and Affected Versions** Steeltoe.Discovery.Eureka versions prior to 3.2.8 **Description** The issue concerns credential leakage in logs when utilizing multiple Eureka server service URLs with basic auth and encountering an issue with fetching the service registry. Only the first URL is masked in the error log, potentially exposing credentials of subsequent URLs. The code in question is located in the `DiscoveryClient.cs` file. **Recommendations** For Steeltoe.Discovery.Eureka versions prior to 3.2.8, update to version 3.2.8 of the Steeltoe.Discovery.Eureka nuget package to address the credential leakage issue. As a temporary workaround, consider restricting log access to minimize the risk of exposed credentials.