π¨ CVE-2026-56425
The Azure Active Directory (AAD) authentication implementation contained multiple weaknesses in its OAuth 2.0 authorization flow that could allow attackers to bypass important security guarantees provided by the protocol.
The application used the PHP session identifier (session_id()) as the OAuth state parameter. Because session identifiers are long-lived authentication credentials, exposing them in OAuth redirect URLs could leak valid session tokens through browser history, HTTP Referer headers, reverse proxies, access logs, or third-party infrastructure involved in the authentication flow. If obtained by an attacker, the leaked session identifier could potentially be used for session hijacking.
Additionally, the implementation did not regenerate the session identifier after successful authentication, leaving authenticated sessions susceptible to session fixation attacks where an attacker forces a victim to use a known session identifier before login and later reuses that identifier after authentication.
The OAuth state value was also not implemented as a dedicated, single-use nonce. This weakened CSRF protections and increased the risk of replay attacks against the OAuth callback process.
The authentication flow further failed to enforce HTTPS for the configured OAuth redirect URI. If a non-HTTPS redirect URI was used, OAuth authorization codes and access tokens could traverse the network in plaintext, exposing sensitive credentials to network attackers.
Finally, OAuth error responses containing attacker-controlled GET parameters were logged verbatim. An attacker could inject control characters or crafted log content, leading to log forging, log injection, or corruption of audit records.
The fix introduces:
*
A dedicated cryptographically random OAuth state value.
*
Single-use state validation and invalidation.
*
Constant-time state comparison using hash_equals().
*
Session identifier rotation after successful authentication.
*
Enforcement of HTTPS-only redirect URIs.
*
Sanitized and length-limited logging of OAuth error parameters.
AAD Authentication Plugin (OAuth 2.0 / Azure Active Directory integration)
π@cveNotify
The Azure Active Directory (AAD) authentication implementation contained multiple weaknesses in its OAuth 2.0 authorization flow that could allow attackers to bypass important security guarantees provided by the protocol.
The application used the PHP session identifier (session_id()) as the OAuth state parameter. Because session identifiers are long-lived authentication credentials, exposing them in OAuth redirect URLs could leak valid session tokens through browser history, HTTP Referer headers, reverse proxies, access logs, or third-party infrastructure involved in the authentication flow. If obtained by an attacker, the leaked session identifier could potentially be used for session hijacking.
Additionally, the implementation did not regenerate the session identifier after successful authentication, leaving authenticated sessions susceptible to session fixation attacks where an attacker forces a victim to use a known session identifier before login and later reuses that identifier after authentication.
The OAuth state value was also not implemented as a dedicated, single-use nonce. This weakened CSRF protections and increased the risk of replay attacks against the OAuth callback process.
The authentication flow further failed to enforce HTTPS for the configured OAuth redirect URI. If a non-HTTPS redirect URI was used, OAuth authorization codes and access tokens could traverse the network in plaintext, exposing sensitive credentials to network attackers.
Finally, OAuth error responses containing attacker-controlled GET parameters were logged verbatim. An attacker could inject control characters or crafted log content, leading to log forging, log injection, or corruption of audit records.
The fix introduces:
*
A dedicated cryptographically random OAuth state value.
*
Single-use state validation and invalidation.
*
Constant-time state comparison using hash_equals().
*
Session identifier rotation after successful authentication.
*
Enforcement of HTTPS-only redirect URIs.
*
Sanitized and length-limited logging of OAuth error parameters.
AAD Authentication Plugin (OAuth 2.0 / Azure Active Directory integration)
π@cveNotify
GitHub
fix: [security] AAD auth hardening Β· MISP/MISP@146bc40
- as reported by Cormac Doherty
π¨ CVE-2026-56446
MISP allowed a site administrator to configure an arbitrary filesystem path for the NDJSON error log used by JsonLogTool. Because log entries can include attacker-controlled content, an authenticated attacker with site administrator privileges could direct log output to a PHP file in a web-accessible directory and inject PHP code through logged data. Accessing the resulting file could lead to remote code execution with the privileges of the web server process.
The fix restricts log destinations to existing directories beneath APP/tmp/logs or /var/log, requires absolute paths, rejects stream wrappers and traversal-related input, and limits filenames to .log or .ndjson extensions while disallowing executable extension segments.
π@cveNotify
MISP allowed a site administrator to configure an arbitrary filesystem path for the NDJSON error log used by JsonLogTool. Because log entries can include attacker-controlled content, an authenticated attacker with site administrator privileges could direct log output to a PHP file in a web-accessible directory and inject PHP code through logged data. Accessing the resulting file could lead to remote code execution with the privileges of the web server process.
The fix restricts log destinations to existing directories beneath APP/tmp/logs or /var/log, requires absolute paths, rejects stream wrappers and traversal-related input, and limits filenames to .log or .ndjson extensions while disallowing executable extension segments.
π@cveNotify
GitHub
fix: [security] RCE via arbitrary ndjson log paths. Β· MISP/MISP@9600d48
- previously mitigated by requiring a compromised site admin account
- strictly control the log file path + name to avoid such cases in the future (next commit will add CLI only to the setting, jus...
- strictly control the log file path + name to avoid such cases in the future (next commit will add CLI only to the setting, jus...
π¨ CVE-2026-56447
MISP allowed an authenticated site administrator to set the Kafka_rdkafka_config setting to an arbitrary filesystem path. MISP subsequently parsed the referenced INI file and passed its options to rdkafka. A crafted attacker-controlled configuration file could use rdkafka options such as plugin.library.paths to load an external library, resulting in arbitrary code execution with the privileges of the MISP process. An attacker could leverage a MISP-writable location, such as an uploaded file or administrative image, to host the malicious configuration file.
The issue is fixed by restricting the setting to absolute .ini files located only in approved configuration directories outside the webroot and MISP upload targets.
π@cveNotify
MISP allowed an authenticated site administrator to set the Kafka_rdkafka_config setting to an arbitrary filesystem path. MISP subsequently parsed the referenced INI file and passed its options to rdkafka. A crafted attacker-controlled configuration file could use rdkafka options such as plugin.library.paths to load an external library, resulting in arbitrary code execution with the privileges of the MISP process. An attacker could leverage a MISP-writable location, such as an uploaded file or administrative image, to host the malicious configuration file.
The issue is fixed by restricting the setting to absolute .ini files located only in approved configuration directories outside the webroot and MISP upload targets.
π@cveNotify
GitHub
fix: [security] RCE via arbitrary ndjson log paths. Β· MISP/MISP@9600d48
- previously mitigated by requiring a compromised site admin account
- strictly control the log file path + name to avoid such cases in the future (next commit will add CLI only to the setting, jus...
- strictly control the log file path + name to avoid such cases in the future (next commit will add CLI only to the setting, jus...
π¨ CVE-2026-56448
A path traversal vulnerability exists in AIL Framework before the release containing commit 0041456af25da0cdea1c1c4624e46baff2731d8f. An authenticated AIL user can supply crafted object identifiers through the investigation workflow to cause file paths to resolve outside the intended image, favicon, or screenshot storage directories. This may allow the attacker to download and read arbitrary files that are accessible to the AIL process.
The issue occurs because user-controlled path components were joined with application storage paths without verifying that the resolved path remained within the expected directory. The affected download functionality could then include the contents of such files in a generated archive.
π@cveNotify
A path traversal vulnerability exists in AIL Framework before the release containing commit 0041456af25da0cdea1c1c4624e46baff2731d8f. An authenticated AIL user can supply crafted object identifiers through the investigation workflow to cause file paths to resolve outside the intended image, favicon, or screenshot storage directories. This may allow the attacker to download and read arbitrary files that are accessible to the AIL process.
The issue occurs because user-controlled path components were joined with application storage paths without verifying that the resolved path remained within the expected directory. The affected download functionality could then include the contents of such files in a generated archive.
π@cveNotify
GitHub
fix: [security] /investigation/download path transversal allowing aut⦠· ail-project/ail-framework@0041456
β¦henticated AIL users to read file accessible to the AIL process. Reported by Stephen O and TomΓ‘s Illuminati
π¨ CVE-2026-56450
AIL did not restrict repeated failed attempts to verify a two-factor authentication (OTP) code. An attacker who had reached the 2FA verification step, such as after successfully completing the password-authentication stage, could submit an unlimited number of OTP guesses. This could enable brute-force guessing of a valid code and bypass the intended second authentication factor, resulting in unauthorized account access.
The patch introduces per-user failed-OTP tracking, blocks verification after 30 failed attempts for one hour, clears the counter after a successful OTP verification, and provides administrator recovery actions to purge affected lockouts.
π@cveNotify
AIL did not restrict repeated failed attempts to verify a two-factor authentication (OTP) code. An attacker who had reached the 2FA verification step, such as after successfully completing the password-authentication stage, could submit an unlimited number of OTP guesses. This could enable brute-force guessing of a valid code and bypass the intended second authentication factor, resulting in unauthorized account access.
The patch introduces per-user failed-OTP tracking, blocks verification after 30 failed attempts for one hour, clears the counter after a successful OTP verification, and provides administrator recovery actions to purge affected lockouts.
π@cveNotify
GitHub
chg: [security] add 2FA brute force protection. Reported by Stephen O⦠· ail-project/ail-framework@d3a394f
β¦ + admin can purge global password and user 2FA timeout
π¨ CVE-2026-6653
Use After Free in libxml2's xmlParseInternalSubset from GNOME libxml2 version 2.9.11 to 2.11.0 allows a remote attacker to cause a denial-of-service via maliciously crafted XML input with improper entity resolution handling.
π@cveNotify
Use After Free in libxml2's xmlParseInternalSubset from GNOME libxml2 version 2.9.11 to 2.11.0 allows a remote attacker to cause a denial-of-service via maliciously crafted XML input with improper entity resolution handling.
π@cveNotify
Launchpad
Bug #2141260 βlibxml2 2.9.14+dfsg-1.3ubuntu3.7 on Ubuntu Ubuntu ...β : Bugs : libxml2 package : Ubuntu
libxml2 2.9.14+dfsg-1.3ubuntu3.7 on Ubuntu Ubuntu 24.04.3 LTS contains bug a bug causing unauthorized memory access. I discovered this bug while conducting research on techniques for scaling distributed fuzzers. I was not able to find a CVE with its exactβ¦
π¨ CVE-2026-41950
Dify before version 1.14.0 contains an authorization bypass vulnerability that allows authenticated users to read the full contents of files uploaded by other users within the same tenant by supplying an arbitrary file UUID in the files array of a chat-messages request. Attackers can exploit insufficient permission verification in the chat-messages endpoints to access files without ownership validation, bypassing workspace separation and signed URL protections to retrieve sensitive file contents through workflow processing.
π@cveNotify
Dify before version 1.14.0 contains an authorization bypass vulnerability that allows authenticated users to read the full contents of files uploaded by other users within the same tenant by supplying an arbitrary file UUID in the files array of a chat-messages request. Attackers can exploit insufficient permission verification in the chat-messages endpoints to access files without ownership validation, bypassing workspace separation and signed URL protections to retrieve sensitive file contents through workflow processing.
π@cveNotify
GitHub
Release v1.14.0 Β· langgenius/dify
π What's New in v1.14.0?
Collaboration
Collaboration allows workspace members to edit the same workflow together, with synced graph updates, online presence, and shared visibility into who is ...
Collaboration
Collaboration allows workspace members to edit the same workflow together, with synced graph updates, online presence, and shared visibility into who is ...
π¨ CVE-2026-41947
Dify before version 1.14.2 contains an authorization bypass vulnerability that allows authenticated editor users to set and enable trace configurations for any application regardless of tenant ownership. Attackers can exploit missing tenant ownership checks in the trace configuration endpoints to redirect all messages and responses from victim applications to attacker-controlled LLM trace providers. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
Dify before version 1.14.2 contains an authorization bypass vulnerability that allows authenticated editor users to set and enable trace configurations for any application regardless of tenant ownership. Attackers can exploit missing tenant ownership checks in the trace configuration endpoints to redirect all messages and responses from victim applications to attacker-controlled LLM trace providers. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
GitHub
fix(security): enforce tenant scoping on app trace-config endpoints (β¦ Β· langgenius/dify@55d05fe
β¦GHSA-48xc-wmw8-3jr3) (#35793)
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Ido Shani <ido@zafran.io>
Co-authore...
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Ido Shani <ido@zafran.io>
Co-authore...
π¨ CVE-2026-41948
Dify version 1.14.1 and prior contain a path traversal vulnerability that allows authenticated users to manipulate requests forwarded to the Plugin Daemon's internal REST API by exploiting insufficient URL path sanitization. Attackers can traverse out of their authorized tenant path using unencoded dot sequences in task identifiers or manipulated filename parameters to access internal endpoints such as debug interfaces, requiring only knowledge of the victim tenant's UUID. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
Dify version 1.14.1 and prior contain a path traversal vulnerability that allows authenticated users to manipulate requests forwarded to the Plugin Daemon's internal REST API by exploiting insufficient URL path sanitization. Attackers can traverse out of their authorized tenant path using unencoded dot sequences in task identifiers or manipulated filename parameters to access internal endpoints such as debug interfaces, requiring only knowledge of the victim tenant's UUID. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
GitHub
fix(security): reject path traversal sequences before plugin daemon forward (GHSA-gvc6-fh3x-89xh) by xr843 Β· Pull Request #35796β¦
Summary
BasePluginClient._prepare_request (api/core/plugin/impl/base.py) joins a caller-supplied path onto the plugin daemon's inner-API base URL without checking for traversal sequences. T...
BasePluginClient._prepare_request (api/core/plugin/impl/base.py) joins a caller-supplied path onto the plugin daemon's inner-API base URL without checking for traversal sequences. T...
π¨ CVE-2026-41949
Dify before version 1.14.2 contains an authorization bypass vulnerability in the file preview endpoint that allows any authenticated user to read up to 3,000 characters of any uploaded document across all tenants and workspaces using only the file's UUID. Attackers can access the /console/api/files/{file_id}/preview endpoint with an intercepted file UUID to extract sensitive content from documents without ownership or workspace permission verification. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
Dify before version 1.14.2 contains an authorization bypass vulnerability in the file preview endpoint that allows any authenticated user to read up to 3,000 characters of any uploaded document across all tenants and workspaces using only the file's UUID. Attackers can access the /console/api/files/{file_id}/preview endpoint with an intercepted file UUID to extract sensitive content from documents without ownership or workspace permission verification. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.
π@cveNotify
GitHub
fix(security): tenant-scope FilePreviewApi text-extract endpoint (GHS⦠· langgenius/dify@432a641
β¦A-2qwc-c2cc-2xwv) (#35797)
Signed-off-by: xr843 <137012659+xr843@users.noreply.github.com>
Co-authored-by: Ido Shani <ido@zafran.io>
Co-authored-by: autofix-ci[bot] &a...
Signed-off-by: xr843 <137012659+xr843@users.noreply.github.com>
Co-authored-by: Ido Shani <ido@zafran.io>
Co-authored-by: autofix-ci[bot] &a...
π¨ CVE-2026-9804
A flaw was found in KubeVirt's virt-exportserver component. An attacker with specific namespace-level access can exploit a path traversal vulnerability in the VMExport directory endpoint. By placing a symbolic link (symlink) within an exported filesystem Persistent Volume Claim (PVC) that points outside its designated mount root, the attacker can read arbitrary files from the exporter pod's filesystem. This leads to information disclosure, potentially exposing sensitive data.
π@cveNotify
A flaw was found in KubeVirt's virt-exportserver component. An attacker with specific namespace-level access can exploit a path traversal vulnerability in the VMExport directory endpoint. By placing a symbolic link (symlink) within an exported filesystem Persistent Volume Claim (PVC) that points outside its designated mount root, the attacker can read arbitrary files from the exporter pod's filesystem. This leads to information disclosure, potentially exposing sensitive data.
π@cveNotify
π¨ CVE-2026-45177
Idira Secrets Manager SaaS Edge versions prior to 1.8 exhibit improper access control within its internal authentication components. A remote, unauthenticated attacker could exploit this by submitting a specially crafted request. Under specific circumstances, this could allow the attacker to manipulate internal validation mechanisms, potentially leading to a bypass of identity verification and the unauthorized acquisition of an access token. CyberArk Security Bulletin: CA26-20
π@cveNotify
Idira Secrets Manager SaaS Edge versions prior to 1.8 exhibit improper access control within its internal authentication components. A remote, unauthenticated attacker could exploit this by submitting a specially crafted request. Under specific circumstances, this could allow the attacker to manipulate internal validation mechanisms, potentially leading to a bypass of identity verification and the unauthorized acquisition of an access token. CyberArk Security Bulletin: CA26-20
π@cveNotify
π¨ CVE-2026-45178
Idira Secrets Manager Self-Hosted versions 13.8.0 and lower exhibit improper access control within internal cluster endpoints. A remote, authenticated attacker possessing standard node-level credentials could leverage these endpoints to potentially retrieve unauthorized secrets or cause a denial of service (DoS). CyberArk Security Bulletin: CA26-20
π@cveNotify
Idira Secrets Manager Self-Hosted versions 13.8.0 and lower exhibit improper access control within internal cluster endpoints. A remote, authenticated attacker possessing standard node-level credentials could leverage these endpoints to potentially retrieve unauthorized secrets or cause a denial of service (DoS). CyberArk Security Bulletin: CA26-20
π@cveNotify
π¨ CVE-2026-40641
Dell PowerFlex Manager, version(s) 4.6.0.1, contain(s) an Use of a Broken or Risky Cryptographic Algorithm vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure and Information tampering.
π@cveNotify
Dell PowerFlex Manager, version(s) 4.6.0.1, contain(s) an Use of a Broken or Risky Cryptographic Algorithm vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure and Information tampering.
π@cveNotify
π¨ CVE-2026-10696
Use of an incorrectly resolved name or reference in the pinget backend
in Devolutions UniGetUI 2026.2.0 and earlier allows a WinGet community
catalog contributor to cause an installed application to be correlated
to an unrelated, attacker-controlled catalog package and to execute an
attacker-controlled installer via a crafted catalog package whose
normalized name is contained as a substring within the installed
application name when a user applies the proposed update.
π@cveNotify
Use of an incorrectly resolved name or reference in the pinget backend
in Devolutions UniGetUI 2026.2.0 and earlier allows a WinGet community
catalog contributor to cause an installed application to be correlated
to an unrelated, attacker-controlled catalog package and to execute an
attacker-controlled installer via a crafted catalog package whose
normalized name is contained as a substring within the installed
application name when a user applies the proposed update.
π@cveNotify
Devolutions
advisories
Stay informed with Devolutions' latest security advisories on vulnerabilities, threats, and incident responses to enhance your cybersecurity posture.
π¨ CVE-2026-50194
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. When Steeltoe management endpoints versions 3.2.2 through 3.3.0 and 4.1.0 are configured to listen on an alternate port (`Management:Endpoints:Port` is configured), the middleware responsible for restricting access to the endpoints uses the `Host` HTTP header rather than the actual network socket port. Versions 3.4.0 and 4.2.0 patch the issue. If an immediate upgrade to a patched version is not possible, add explicit ASP.NET Core authorization (`RequireAuthorization`) to all sensitive actuator endpoints as a defense-in-depth measure independent of port isolation and/or configure the reverse proxy or load balancer to enforce the `Host` header value and prevent clients from setting an arbitrary port.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. When Steeltoe management endpoints versions 3.2.2 through 3.3.0 and 4.1.0 are configured to listen on an alternate port (`Management:Endpoints:Port` is configured), the middleware responsible for restricting access to the endpoints uses the `Host` HTTP header rather than the actual network socket port. Versions 3.4.0 and 4.2.0 patch the issue. If an immediate upgrade to a patched version is not possible, add explicit ASP.NET Core authorization (`RequireAuthorization`) to all sensitive actuator endpoints as a defense-in-depth measure independent of port isolation and/or configure the reverse proxy or load balancer to enforce the `Host` header value and prevent clients from setting an arbitrary port.
π@cveNotify
GitHub
Fix management port isolation bypass Β· SteeltoeOSS/Steeltoe@4cbc352
* Use HttpContext.Connection.LocalPort when evaluating management port
π¨ CVE-2026-50196
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Discovery.Eureka prior to versions 4.2.0 and 3.4.0, `DataCenterInfo.FromJson` throws `ArgumentException` for any `name` value other than `"MyOwn"` or `"Amazon"`, despite the Java Eureka specification defining a third valid value: `"Netflix"`. The exception propagates through the entire registry deserialization chain and is swallowed by the periodic cache refresh task, leaving the local service registry permanently empty or stale. Versions 4.2.0 and 3.4.0 patch the issue. If an immediate upgrade is not possible, remove any registrations using unsupported `DataCenterInfo.name` values from the registry. In mixed Java/Spring and Steeltoe environments, audit for the `Netflix` data center type before deploying Steeltoe Eureka clients.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Discovery.Eureka prior to versions 4.2.0 and 3.4.0, `DataCenterInfo.FromJson` throws `ArgumentException` for any `name` value other than `"MyOwn"` or `"Amazon"`, despite the Java Eureka specification defining a third valid value: `"Netflix"`. The exception propagates through the entire registry deserialization chain and is swallowed by the periodic cache refresh task, leaving the local service registry permanently empty or stale. Versions 4.2.0 and 3.4.0 patch the issue. If an immediate upgrade is not possible, remove any registrations using unsupported `DataCenterInfo.name` values from the registry. In mixed Java/Spring and Steeltoe environments, audit for the `Netflix` data center type before deploying Steeltoe Eureka clients.
π@cveNotify
GitHub
Fix Eureka DataCenterInfo poisoning Β· SteeltoeOSS/Steeltoe@b8ed855
.NET Components for Externalized Configuration, Database Connectors, Service Discovery, Logging and Distributed Tracing, Application Management, Security, and more. - Fix Eureka DataCenterInfo poisoning Β· SteeltoeOSS/Steeltoe@b8ed855
π¨ CVE-2026-50200
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Management.Endpoint prior to version 4.2.0 and Steeltoe.Management.EndpointCore prior to version 3.4.0, the `Sanitizer` component in the Environment actuator redacts configuration values by matching the configuration key name against a suffix list. The default list (`password`, `secret`, `key`, `token`, `.*credentials.*`, `vcap_services`) does not cover the standard .NET pattern `ConnectionStrings:<name>` or Steeltoe Connectors' `Steeltoe:Client:<type>:Default:ConnectionString`. There is no value-based scrubbing, so full connection string values including embedded `Password=` and `user:pass@host` segments are returned verbatim in `/actuator/env` responses. Steeltoe.Management.Endpoint 4.2.0 and Steeltoe.Management.EndpointCore 3.4.0 patch the issue. If an immediate upgrade is not possible: On the standard path, remove `env` from the actuator exposure list; add `.*connectionstring.*` to `KeysToSanitize` as a defense-in-depth measure for both paths; and/or require authorization on actuator endpoints.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Management.Endpoint prior to version 4.2.0 and Steeltoe.Management.EndpointCore prior to version 3.4.0, the `Sanitizer` component in the Environment actuator redacts configuration values by matching the configuration key name against a suffix list. The default list (`password`, `secret`, `key`, `token`, `.*credentials.*`, `vcap_services`) does not cover the standard .NET pattern `ConnectionStrings:<name>` or Steeltoe Connectors' `Steeltoe:Client:<type>:Default:ConnectionString`. There is no value-based scrubbing, so full connection string values including embedded `Password=` and `user:pass@host` segments are returned verbatim in `/actuator/env` responses. Steeltoe.Management.Endpoint 4.2.0 and Steeltoe.Management.EndpointCore 3.4.0 patch the issue. If an immediate upgrade is not possible: On the standard path, remove `env` from the actuator exposure list; add `.*connectionstring.*` to `KeysToSanitize` as a defense-in-depth measure for both paths; and/or require authorization on actuator endpoints.
π@cveNotify
GitHub
Enhance /env sanitizer Β· SteeltoeOSS/Steeltoe@bef9f14
* sanitize connection strings and embedded credentials
---------
Co-authored-by: Bart Koelman <104792814+bart-vmware@users.noreply.github.com>
---------
Co-authored-by: Bart Koelman <104792814+bart-vmware@users.noreply.github.com>
π¨ CVE-2026-50201
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Management.Endpoint prior to version 4.2.0 and Steeltoe.Management.EndpointCore prior to version 3.4.0, all Steeltoe actuator endpoints default to `EndpointPermissions.Restricted`, which is mappeds to Cloud Foundry's `read_basic_data` permission (granted to Space Auditors and similar low-trust roles). Sensitive actuators including heap dump, environment, and thread dump do not raise this to `EndpointPermissions.Full`, so CF's `read_sensitive_data` permission flag is not enforced for those endpoints. Spring Boot's equivalent Cloud Foundry integration gates these endpoints with `read_sensitive_data` by default. Steeltoe.Management.Endpoint 4.2.0 and Steeltoe.Management.EndpointCore 3.4.0 patch the issue. If an immediate upgrade is not possible, explicitly set `RequiredPermissions = EndpointPermissions.Full` in the options for `HeapDumpEndpointOptions`, `EnvironmentEndpointOptions`, and `ThreadDumpEndpointOptions`; and/or if heap dump, thread dump, or environment are not needed in production, register only the required actuators individually instead of using `AddAllActuators()`.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Management.Endpoint prior to version 4.2.0 and Steeltoe.Management.EndpointCore prior to version 3.4.0, all Steeltoe actuator endpoints default to `EndpointPermissions.Restricted`, which is mappeds to Cloud Foundry's `read_basic_data` permission (granted to Space Auditors and similar low-trust roles). Sensitive actuators including heap dump, environment, and thread dump do not raise this to `EndpointPermissions.Full`, so CF's `read_sensitive_data` permission flag is not enforced for those endpoints. Spring Boot's equivalent Cloud Foundry integration gates these endpoints with `read_sensitive_data` by default. Steeltoe.Management.Endpoint 4.2.0 and Steeltoe.Management.EndpointCore 3.4.0 patch the issue. If an immediate upgrade is not possible, explicitly set `RequiredPermissions = EndpointPermissions.Full` in the options for `HeapDumpEndpointOptions`, `EnvironmentEndpointOptions`, and `ThreadDumpEndpointOptions`; and/or if heap dump, thread dump, or environment are not needed in production, register only the required actuators individually instead of using `AddAllActuators()`.
π@cveNotify
GitHub
Require FULL Permissions on /env, /threaddump, /heapdump by default Β· SteeltoeOSS/Steeltoe@b39defa
.NET Components for Externalized Configuration, Database Connectors, Service Discovery, Logging and Distributed Tracing, Application Management, Security, and more. - Require FULL Permissions on /env, /threaddump, /heapdump by default Β· SteeltoeOSS/Steeltoe@b39defa
π¨ CVE-2026-50202
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Security.Authentication.CloudFoundryBase prior to version 3.4.0, Steeltoe.Security.Authentication.JwtBearer prior to version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect prior to version 4.2.0, the JWT signing key cache in `TokenKeyResolver` uses `kid` as the sole cache key without namespacing by authority. In applications with multiple `JwtBearer` schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another. Additionally, cached keys have no expiration, so rotated or revoked keys remain trusted until the application process restarts. Steeltoe.Security.Authentication.CloudFoundryBase version 3.4.0, Steeltoe.Security.Authentication.JwtBearer version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect version 4.2.0 patch the issue. If an immediate upgrade is not possible: In multi-scheme deployments, configure only one `JwtBearer` scheme per application when different identity providers are required; and/or restart the application process after an identity provider signing key rotation to clear stale cached keys.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Security.Authentication.CloudFoundryBase prior to version 3.4.0, Steeltoe.Security.Authentication.JwtBearer prior to version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect prior to version 4.2.0, the JWT signing key cache in `TokenKeyResolver` uses `kid` as the sole cache key without namespacing by authority. In applications with multiple `JwtBearer` schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another. Additionally, cached keys have no expiration, so rotated or revoked keys remain trusted until the application process restarts. Steeltoe.Security.Authentication.CloudFoundryBase version 3.4.0, Steeltoe.Security.Authentication.JwtBearer version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect version 4.2.0 patch the issue. If an immediate upgrade is not possible: In multi-scheme deployments, configure only one `JwtBearer` scheme per application when different identity providers are required; and/or restart the application process after an identity provider signing key rotation to clear stale cached keys.
π@cveNotify
GitHub
Add expiration to JWT/OpenID keys caching Β· SteeltoeOSS/Steeltoe@04db2ac
Refactor cache invalidation for JWT keys and tests
---------
Co-authored-by: Tim Hess <tim.hess@broadcom.com>
---------
Co-authored-by: Tim Hess <tim.hess@broadcom.com>
π¨ CVE-2026-50267
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Configuration.Abstractions 4.0.0 through 4.1.0, when MySQL or PostgreSQL service bindings from `VCAP_SERVICES` include TLS client credentials, the Connectors library writes those credentials to temporary files in `Path.GetTempPath()` using `File.CreateText`. On Linux, `File.CreateText` creates files with mode `0644` (world-readable) under the process umask, and the files are never deleted. The same key material is protected at mode `0400` in `/proc/<pid>/environ`. Steeltoe.Configuration.Abstractions version 4.2.0 patches the issue. If an immediate upgrade is not possible, prevent other processes from running in the container under a different UID with access to `/tmp`.
π@cveNotify
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Configuration.Abstractions 4.0.0 through 4.1.0, when MySQL or PostgreSQL service bindings from `VCAP_SERVICES` include TLS client credentials, the Connectors library writes those credentials to temporary files in `Path.GetTempPath()` using `File.CreateText`. On Linux, `File.CreateText` creates files with mode `0644` (world-readable) under the process umask, and the files are never deleted. The same key material is protected at mode `0400` in `/proc/<pid>/environ`. Steeltoe.Configuration.Abstractions version 4.2.0 patches the issue. If an immediate upgrade is not possible, prevent other processes from running in the container under a different UID with access to `/tmp`.
π@cveNotify
GitHub
Harden temporary files written by MySQL/PostgreSQL Connectors Β· SteeltoeOSS/Steeltoe@8dd97cc
* Create temp file with user-only access
* Delete temporary cert files
* Delete temporary cert files