Steeltoeoss
Monthly
Malformed service-registry records can blank out service discovery for Steeltoe-based cloud-native applications: EurekaDiscoveryClient versions 4.0.0 through 4.2.x deserialize the entire Eureka registry response as one atomic unit, so a single instance entry with an unrecognized actionType or status, a non-Boolean isCoordinatingDiscoveryServer, or a nonnumeric timestamp aborts the whole payload and leaves every connected client with an empty or stale instance list. The vendor rates this 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) while the independent assessment rates the vector with PR:L and scope changed, reflecting that a practical attacker must be a principal able to register or update an instance in the Eureka registry that victim clients consume; impact is availability-only, with no data exposure or code execution, and the effect self-heals once the bad registration is removed. No public exploit code has been identified at time of analysis and the issue is fixed in Steeltoe 4.3.0.
Consul service discovery in Steeltoe 4.0.0 through 4.2.x can be rendered persistently unusable by a single malformed service registration, because ConsulServiceInstance parses the registration's 'secure' metadata with a strict Boolean conversion that throws on any value other than 'true' or 'false'. A principal able to write to the Consul catalog - i.e. holding a valid ACL token with service-registration rights, or reaching a Consul deployment that runs without ACLs - can register a service whose 'secure' metadata is set to a value such as 'yes', '1' or an empty string; the resulting exception aborts construction of the instance list, and because GetAllInstancesAsync throws on the first bad entry, enumeration of every discovered service fails, taking the target (or the entire discovery surface) offline until the offending registration is removed. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (the advisory's vector differs only in reporting PR:N instead of PR:L), and while no public exploit code has been identified at time of analysis, no CISA KEV entry exists, and no EPSS score was supplied, the impact is low-complexity and requires no user interaction, so Consul catalog write access should be treated as a denial-of-service primitive.
Sensitive credential disclosure in Steeltoe.Management.Endpoint before 4.2.0 and Steeltoe.Management.EndpointCore before 3.4.0 allows remote attackers to retrieve plaintext database connection strings, embedded passwords, and URI userinfo segments via the `/actuator/env` endpoint. The Sanitizer's default key-suffix list omits the standard .NET `ConnectionStrings:<name>` pattern and the Steeltoe Connectors' `Steeltoe:Client:<type>:Default:ConnectionString` pattern, and performs no value-based scrubbing. No public exploit identified at time of analysis, but the fix and test cases are committed in public GitHub history, making the vulnerable behavior easy to reproduce.
Denial of service in Steeltoe.Discovery.Eureka client (.NET) versions prior to 4.2.0 and 3.4.0 allows a remote Eureka registry containing service registrations with DataCenterInfo.name="Netflix" to permanently break the local service discovery cache. The client's DataCenterInfo.FromJson rejects any value other than "MyOwn" or "Amazon" with an ArgumentException that is silently swallowed by the periodic cache refresh task, leaving downstream .NET services unable to discover peers. No public exploit identified at time of analysis, but the trigger is trivially reachable in mixed Java/Spring-Cloud and Steeltoe environments.
Improper authentication in Steeltoe management endpoints versions 3.2.2 through 3.3.0 and 4.1.0 allows remote unauthenticated attackers to reach actuator endpoints intended to be isolated on a separate management port by spoofing the HTTP Host header. The middleware trusted the client-supplied Host header port instead of the actual TCP socket port, defeating port-based access restrictions and enabling information disclosure from sensitive actuator endpoints. No public exploit identified at time of analysis, though the fix commit and a regression test demonstrating Host-header spoofing are publicly available on GitHub.
Authentication bypass in Steeltoe.Security.Authorization.Certificate (Steeltoe prior to 4.3.0) lets remote unauthenticated attackers spoof the X-Client-Cert header to defeat the SameOrg and SameSpace authorization policies, gaining access to resources belonging to another organization or space. The flaw is that AddOrgAndSpacePolicies() combined with UseCertificateAuthorization() trusts a client-supplied public certificate without verifying proof of possession of the matching private key, and common Cloud Foundry routers pass the header through to the application. Exploitation is unauthenticated (PR:N) but high complexity (AC:H) and only succeeds when ingress does not restrict inbound traffic to a known trusted proxy source IP and the attacker already holds the public certificate of an application instance in the target org or space; there is no public exploit code and no CISA KEV entry, and EPSS data was not provided, so the practical risk is moderate and deployment-dependent. Fixed in Steeltoe 4.3.0.
Information disclosure in Steeltoe's Management Endpoint actuator (Steeltoe.Management.Endpoint) prior to 4.3.0 allows an unauthenticated remote attacker who can reach the exposed /actuator/httpexchanges endpoint to harvest secrets that were previously captured in recorded request query strings - OAuth and password-reset tokens, API keys, and signed-URL signatures - because MaskedUri only redacts URI user-info and never inspects the query string. The same recorded URIs are written by the Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger, giving anyone with log access a second disclosure channel. Exploitation is config-gated (IncludeQueryString must be enabled, the endpoint must be explicitly exposed, and prior traffic must actually have carried query-string secrets), scoring CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N); no public exploit identified at time of analysis, and the issue is remediated in Steeltoe 4.3.0.
Steeltoe.Configuration.Encryption 4.0.0 through 4.1.0 silently downgrades RSA encryption from OAEP to PKCS#1 v1.5 when operators explicitly configure `encrypt:rsa:algorithm=OAEP`. The root cause is an incorrect BouncyCastle transformation string in `RsaKeyStoreDecryptor.cs` - the `OAEP` branch passed `"RSA/ECB/PKCS1"` to `CipherUtilities.GetCipher()` instead of the correct `"RSA/NONE/OAEPWithSHA1AndMGF1Padding"`, meaning both the `OAEP` and `DEFAULT` settings silently selected the same weaker algorithm. No public exploit is identified at time of analysis, and CVSS scores this at 1.9 (Low) given the high-privilege local attack vector; however, the security consequence is a cryptographic guarantee failure that exposes encrypted configuration secrets to Bleichenbacher-class padding oracle attacks that OAEP was chosen to prevent.
Steeltoe.Configuration.Abstractions 4.0.0-4.1.0 permanently exposes TLS client private key material to world-readable temporary files on Linux when Cloud Foundry MySQL or PostgreSQL service bindings supply SSL credentials via VCAP_SERVICES. The Connectors library writes SSL certificate, private key, and CA files to Path.GetTempPath() using File.CreateText, which on Linux creates files at mode 0644 (owner read/write, group read, world read) with no cleanup mechanism, leaving key material readable by any co-located process for the container's lifetime. Vendor-released patch 4.2.0 resolves both the permission issue (restricting new temp files to mode 0600) and the missing cleanup via IDisposable; no public exploit has been identified at time of analysis.
Cross-authority JWT signing key confusion in Steeltoe authentication libraries allows tokens issued by one identity provider to be accepted by application schemes configured for a different authority. Affected are CloudFoundryBase prior to 3.4.0, JwtBearer prior to 4.2.0, and OpenIdConnect prior to 4.2.0 when deployed in multi-scheme configurations. No public exploit has been identified at time of analysis; vendor patches are available and no CISA KEV listing exists.
Sensitive actuator endpoints in Steeltoe.Management.Endpoint and Steeltoe.Management.EndpointCore expose heap dumps, environment variables, and thread dumps to low-trust Cloud Foundry roles (Space Auditors) due to incorrect default permission levels. Affected versions inherit the base class default of EndpointPermissions.Restricted - which maps to CF's read_basic_data scope - rather than overriding to EndpointPermissions.Full (read_sensitive_data), the permission level Spring Boot's equivalent integration correctly enforces. No public exploit code or KEV listing exists at time of analysis; however, the CVSS PR:L rating reflects that any valid CF credential with Space Auditor privileges is sufficient to reach the affected endpoints.
Malformed service-registry records can blank out service discovery for Steeltoe-based cloud-native applications: EurekaDiscoveryClient versions 4.0.0 through 4.2.x deserialize the entire Eureka registry response as one atomic unit, so a single instance entry with an unrecognized actionType or status, a non-Boolean isCoordinatingDiscoveryServer, or a nonnumeric timestamp aborts the whole payload and leaves every connected client with an empty or stale instance list. The vendor rates this 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) while the independent assessment rates the vector with PR:L and scope changed, reflecting that a practical attacker must be a principal able to register or update an instance in the Eureka registry that victim clients consume; impact is availability-only, with no data exposure or code execution, and the effect self-heals once the bad registration is removed. No public exploit code has been identified at time of analysis and the issue is fixed in Steeltoe 4.3.0.
Consul service discovery in Steeltoe 4.0.0 through 4.2.x can be rendered persistently unusable by a single malformed service registration, because ConsulServiceInstance parses the registration's 'secure' metadata with a strict Boolean conversion that throws on any value other than 'true' or 'false'. A principal able to write to the Consul catalog - i.e. holding a valid ACL token with service-registration rights, or reaching a Consul deployment that runs without ACLs - can register a service whose 'secure' metadata is set to a value such as 'yes', '1' or an empty string; the resulting exception aborts construction of the instance list, and because GetAllInstancesAsync throws on the first bad entry, enumeration of every discovered service fails, taking the target (or the entire discovery surface) offline until the offending registration is removed. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (the advisory's vector differs only in reporting PR:N instead of PR:L), and while no public exploit code has been identified at time of analysis, no CISA KEV entry exists, and no EPSS score was supplied, the impact is low-complexity and requires no user interaction, so Consul catalog write access should be treated as a denial-of-service primitive.
Sensitive credential disclosure in Steeltoe.Management.Endpoint before 4.2.0 and Steeltoe.Management.EndpointCore before 3.4.0 allows remote attackers to retrieve plaintext database connection strings, embedded passwords, and URI userinfo segments via the `/actuator/env` endpoint. The Sanitizer's default key-suffix list omits the standard .NET `ConnectionStrings:<name>` pattern and the Steeltoe Connectors' `Steeltoe:Client:<type>:Default:ConnectionString` pattern, and performs no value-based scrubbing. No public exploit identified at time of analysis, but the fix and test cases are committed in public GitHub history, making the vulnerable behavior easy to reproduce.
Denial of service in Steeltoe.Discovery.Eureka client (.NET) versions prior to 4.2.0 and 3.4.0 allows a remote Eureka registry containing service registrations with DataCenterInfo.name="Netflix" to permanently break the local service discovery cache. The client's DataCenterInfo.FromJson rejects any value other than "MyOwn" or "Amazon" with an ArgumentException that is silently swallowed by the periodic cache refresh task, leaving downstream .NET services unable to discover peers. No public exploit identified at time of analysis, but the trigger is trivially reachable in mixed Java/Spring-Cloud and Steeltoe environments.
Improper authentication in Steeltoe management endpoints versions 3.2.2 through 3.3.0 and 4.1.0 allows remote unauthenticated attackers to reach actuator endpoints intended to be isolated on a separate management port by spoofing the HTTP Host header. The middleware trusted the client-supplied Host header port instead of the actual TCP socket port, defeating port-based access restrictions and enabling information disclosure from sensitive actuator endpoints. No public exploit identified at time of analysis, though the fix commit and a regression test demonstrating Host-header spoofing are publicly available on GitHub.
Authentication bypass in Steeltoe.Security.Authorization.Certificate (Steeltoe prior to 4.3.0) lets remote unauthenticated attackers spoof the X-Client-Cert header to defeat the SameOrg and SameSpace authorization policies, gaining access to resources belonging to another organization or space. The flaw is that AddOrgAndSpacePolicies() combined with UseCertificateAuthorization() trusts a client-supplied public certificate without verifying proof of possession of the matching private key, and common Cloud Foundry routers pass the header through to the application. Exploitation is unauthenticated (PR:N) but high complexity (AC:H) and only succeeds when ingress does not restrict inbound traffic to a known trusted proxy source IP and the attacker already holds the public certificate of an application instance in the target org or space; there is no public exploit code and no CISA KEV entry, and EPSS data was not provided, so the practical risk is moderate and deployment-dependent. Fixed in Steeltoe 4.3.0.
Information disclosure in Steeltoe's Management Endpoint actuator (Steeltoe.Management.Endpoint) prior to 4.3.0 allows an unauthenticated remote attacker who can reach the exposed /actuator/httpexchanges endpoint to harvest secrets that were previously captured in recorded request query strings - OAuth and password-reset tokens, API keys, and signed-URL signatures - because MaskedUri only redacts URI user-info and never inspects the query string. The same recorded URIs are written by the Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger, giving anyone with log access a second disclosure channel. Exploitation is config-gated (IncludeQueryString must be enabled, the endpoint must be explicitly exposed, and prior traffic must actually have carried query-string secrets), scoring CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N); no public exploit identified at time of analysis, and the issue is remediated in Steeltoe 4.3.0.
Steeltoe.Configuration.Encryption 4.0.0 through 4.1.0 silently downgrades RSA encryption from OAEP to PKCS#1 v1.5 when operators explicitly configure `encrypt:rsa:algorithm=OAEP`. The root cause is an incorrect BouncyCastle transformation string in `RsaKeyStoreDecryptor.cs` - the `OAEP` branch passed `"RSA/ECB/PKCS1"` to `CipherUtilities.GetCipher()` instead of the correct `"RSA/NONE/OAEPWithSHA1AndMGF1Padding"`, meaning both the `OAEP` and `DEFAULT` settings silently selected the same weaker algorithm. No public exploit is identified at time of analysis, and CVSS scores this at 1.9 (Low) given the high-privilege local attack vector; however, the security consequence is a cryptographic guarantee failure that exposes encrypted configuration secrets to Bleichenbacher-class padding oracle attacks that OAEP was chosen to prevent.
Steeltoe.Configuration.Abstractions 4.0.0-4.1.0 permanently exposes TLS client private key material to world-readable temporary files on Linux when Cloud Foundry MySQL or PostgreSQL service bindings supply SSL credentials via VCAP_SERVICES. The Connectors library writes SSL certificate, private key, and CA files to Path.GetTempPath() using File.CreateText, which on Linux creates files at mode 0644 (owner read/write, group read, world read) with no cleanup mechanism, leaving key material readable by any co-located process for the container's lifetime. Vendor-released patch 4.2.0 resolves both the permission issue (restricting new temp files to mode 0600) and the missing cleanup via IDisposable; no public exploit has been identified at time of analysis.
Cross-authority JWT signing key confusion in Steeltoe authentication libraries allows tokens issued by one identity provider to be accepted by application schemes configured for a different authority. Affected are CloudFoundryBase prior to 3.4.0, JwtBearer prior to 4.2.0, and OpenIdConnect prior to 4.2.0 when deployed in multi-scheme configurations. No public exploit has been identified at time of analysis; vendor patches are available and no CISA KEV listing exists.
Sensitive actuator endpoints in Steeltoe.Management.Endpoint and Steeltoe.Management.EndpointCore expose heap dumps, environment variables, and thread dumps to low-trust Cloud Foundry roles (Space Auditors) due to incorrect default permission levels. Affected versions inherit the base class default of EndpointPermissions.Restricted - which maps to CF's read_basic_data scope - rather than overriding to EndpointPermissions.Full (read_sensitive_data), the permission level Spring Boot's equivalent integration correctly enforces. No public exploit code or KEV listing exists at time of analysis; however, the CVSS PR:L rating reflects that any valid CF credential with Space Auditor privileges is sufficient to reach the affected endpoints.