Common Weakness Enumeration

CWE-636

Allowed-with-Review

Not Failing Securely ('Failing Open')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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.

91 vulnerabilities reference this CWE, most recent first.

GHSA-J92G-9F8W-J867

Vulnerability from github – Published: 2026-07-21 17:47 – Updated: 2026-07-21 17:47
VLAI
Summary
PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms
Details

Impact

channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms.

Two issues combine in releases 42.7.4 through 42.7.11:

  1. The bundled com.ongres.scram:scram-client (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf.
  2. pgJDBC does not enforce channelBinding=require where it matters. ScramAuthenticator checks only that the server advertised a -PLUS mechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed scram-client, because the missing enforcement is in pgJDBC's own code.

Only connections that set channelBinding=require are affected. Under the default prefer policy, and under allow or disable, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.

Patches

Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the scram-client version:

  • Under channelBinding=require, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm.
  • After negotiation, it requires the selected mechanism to use channel binding (a -PLUS mechanism) whenever channelBinding=require is set, regardless of how negotiation resolved.

Upgrade to 42.7.12 or later.

Workarounds

No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.

If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set sslmode=verify-full with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on channelBinding=require in place of certificate verification have no equivalent workaround and should upgrade.

References

  • GHSA-p9jg-fcr6-3mhf — the related com.ongres.scram:scram-client issue (root cause of the empty channel-binding value).
  • scram-client 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3
  • pgJDBC fix in 42.7.12: commit
Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.postgresql:postgresql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "42.7.4"
            },
            {
              "fixed": "42.7.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T17:47:39Z",
    "nvd_published_at": "2026-07-06T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`channelBinding=require` connections can be silently downgraded from `SCRAM-SHA-256-PLUS` (with channel binding) to plain `SCRAM-SHA-256` (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no `tls-server-end-point` channel-binding hash. Examples are `Ed25519`, `Ed448`, and post-quantum algorithms.\n\nTwo issues combine in releases 42.7.4 through 42.7.11:\n\n1. The bundled `com.ongres.scram:scram-client` (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf).\n2. pgJDBC does not enforce `channelBinding=require` where it matters. `ScramAuthenticator` checks only that the server *advertised* a `-PLUS` mechanism; it neither rejects the empty binding nor checks that the *negotiated* mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed `scram-client`, because the missing enforcement is in pgJDBC\u0027s own code.\n\nOnly connections that set `channelBinding=require` are affected. Under the default `prefer` policy, and under `allow` or `disable`, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.\n\n### Patches\n\nFixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the `scram-client` version:\n\n- Under `channelBinding=require`, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm.\n- After negotiation, it requires the selected mechanism to use channel binding (a `-PLUS` mechanism) whenever `channelBinding=require` is set, regardless of how negotiation resolved.\n\nUpgrade to 42.7.12 or later.\n\n### Workarounds\n\nNo pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.\n\nIf you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set `sslmode=verify-full` with a truststore that contains only your server\u0027s CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on `channelBinding=require` in place of certificate verification have no equivalent workaround and should upgrade.\n\n### References\n\n-  [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf) \u2014 the related `com.ongres.scram:scram-client` issue (root cause of the empty channel-binding value).\n- `scram-client` 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3\n- pgJDBC fix in 42.7.12: [commit](https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99)",
  "id": "GHSA-j92g-9f8w-j867",
  "modified": "2026-07-21T17:47:39Z",
  "published": "2026-07-21T17:47:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-j92g-9f8w-j867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54291"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ongres/scram/releases/tag/3.3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgjdbc/pgjdbc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms"
}

GHSA-JGQ2-QV8V-5CMJ

Vulnerability from github – Published: 2026-04-14 20:00 – Updated: 2026-04-24 20:36
VLAI
Summary
free5gc UDR improper path validation allows unauthenticated creation and modification of Traffic Influence Subscriptions
Details

Summary

An improper path validation vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to create or overwrite Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected subs-to-notify path segment.

Details

The endpoint PUT /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:

  1. The function HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdPutin ./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.gochecks whether influenceId != "subs-to-notify".
  2. If the value is different, it calls c.String(http.StatusNotFound, "404 page not found"), but it does not return afterwards.
  3. Execution continues, the request body is still parsed, and the handler calls s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdPutProcedure(c, subscriptionId, &trafficInfluSub).
  4. The processor creates or updates the subscription identified by subscriptionId even 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 successfully create or modify the target subscription in the UDR.

The missing return after sending the 404 response in api_datarepository.go is the root cause of this vulnerability.

PoC

No authentication is required. The attacker can choose an arbitrary subscriptionId.

curl -v -X PUT "http://<udr-host>/nudr-dr/v2/application-data/influenceData/WRONGID/nuovoid" \
  -H "Content-Type: application/json" \
  -d '{
    "notificationUri":"http://evil.com",
    "dnns":["internet"],
    "supis":["imsi-999999999999999"]
  }'

Response:

HTTP/1.1 404 Not Found
404 page not found{"dnns":["internet"],"supis":["imsi-999999999999999"],"notificationUri":"http://evil.com"}

Now verify that the object was actually written:

curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify/nuovoid"

Response:

{"dnns":["internet"],"supis":["imsi-999999999999999"],"notificationUri":"http://evil.com"}

Impact

This is an unauthenticated unauthorized write vulnerability. Any attacker with network access to the SBI can create or overwrite Traffic Influence Subscriptions by choosing an arbitrary subscriptionId, even when using an invalid path that should have been rejected.

This allows injection of attacker-controlled subscription data, including arbitrary SUPIs and attacker-controlled notificationUri values. Depending on deployment behavior, this may enable malicious redirection of policy-related notifications, corruption of subscription state, or disruption of legitimate network policy logic.

The attack is also difficult to detect because the API returns a misleading 404 Not Found response even when the write operation is actually performed.

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 HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdPut:

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 create or modify subscription data.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/udr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:00:45Z",
    "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 create or overwrite Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected `subs-to-notify` path segment.\n\n### Details\nThe endpoint `PUT /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 `HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdPut`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, the request body is still parsed, and the handler calls `s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdPutProcedure(c, subscriptionId, \u0026trafficInfluSub)`.\n4. The processor creates or updates 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 successfully create or modify the target subscription in the UDR.\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. The attacker can choose an arbitrary `subscriptionId`.\n\n```bash\ncurl -v -X PUT \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/WRONGID/nuovoid\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"notificationUri\":\"http://evil.com\",\n    \"dnns\":[\"internet\"],\n    \"supis\":[\"imsi-999999999999999\"]\n  }\u0027\n```\n\nResponse:\n```\nHTTP/1.1 404 Not Found\n404 page not found{\"dnns\":[\"internet\"],\"supis\":[\"imsi-999999999999999\"],\"notificationUri\":\"http://evil.com\"}\n```\nNow verify that the object was actually written:\n\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify/nuovoid\"\n```\nResponse:\n```json\n{\"dnns\":[\"internet\"],\"supis\":[\"imsi-999999999999999\"],\"notificationUri\":\"http://evil.com\"}\n```\n### Impact\nThis is an unauthenticated unauthorized write vulnerability. Any attacker with network access to the SBI can create or overwrite Traffic Influence Subscriptions by choosing an arbitrary subscriptionId, even when using an invalid path that should have been rejected.\n\nThis allows injection of attacker-controlled subscription data, including arbitrary SUPIs and attacker-controlled notificationUri values. Depending on deployment behavior, this may enable malicious redirection of policy-related notifications, corruption of subscription state, or disruption of legitimate network policy logic.\n\nThe attack is also difficult to detect because the API returns a misleading 404 Not Found response even when the write operation is actually performed.\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 HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdPut:\n\n```go\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 create or modify subscription data.",
  "id": "GHSA-jgq2-qv8v-5cmj",
  "modified": "2026-04-24T20:36:00Z",
  "published": "2026-04-14T20:00:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-jgq2-qv8v-5cmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40248"
    },
    {
      "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:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "free5gc UDR improper path validation allows unauthenticated creation and modification of Traffic Influence Subscriptions"
}

GHSA-JGQ2-VQ69-GR6H

Vulnerability from github – Published: 2026-04-17 21:31 – Updated: 2026-04-24 20:49
VLAI
Summary
OpenViking: Unauthenticated remote bot control via OpenAPI HTTP routes
Details

OpenViking prior to commit c7bb167 contains an authentication bypass vulnerability in the VikingBot OpenAPI HTTP route surface where the authentication check fails open when the api_key configuration value is unset or empty. Remote attackers with network access to the exposed service can invoke privileged bot-control functionality without providing a valid X-API-Key header, including submitting attacker-controlled prompts, creating or using bot sessions, and accessing downstream tools, integrations, secrets, or data accessible to the bot.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "openviking"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T20:49:51Z",
    "nvd_published_at": "2026-04-17T19:16:39Z",
    "severity": "CRITICAL"
  },
  "details": "OpenViking prior to commit\u00a0c7bb167 contains an authentication bypass vulnerability in the VikingBot OpenAPI HTTP route surface where the authentication check fails open when the api_key configuration value is unset or empty. Remote attackers with network access to the exposed service can invoke privileged bot-control functionality without providing a valid X-API-Key header, including submitting attacker-controlled prompts, creating or using bot sessions, and accessing downstream tools, integrations, secrets, or data accessible to the bot.",
  "id": "GHSA-jgq2-vq69-gr6h",
  "modified": "2026-04-24T20:49:51Z",
  "published": "2026-04-17T21:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40525"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/pull/1447"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/commit/c7bb1676f4d037609f041bf39e4e2bd52e8f9820"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/volcengine/OpenViking"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcengine/OpenViking/releases/tag/v0.3.9"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openviking-authentication-bypass-via-vikingbot-openapi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenViking: Unauthenticated remote bot control via OpenAPI HTTP routes"
}

GHSA-JJQG-FQRM-G2VJ

Vulnerability from github – Published: 2023-02-14 18:30 – Updated: 2023-02-23 18:31
VLAI
Details

In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs. The vulnerability affects AoB and apps that AoB generates when using the REST API Modular Input functionality through its user interface. The vulnerability also potentially affects third-party apps and add-ons that call the cloudconnectlib.splunktacollectorlib.cloud_connect_mod_input Python class directly.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-22943"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs. The vulnerability affects AoB and apps that AoB generates when using the REST API Modular Input functionality through its user interface. The vulnerability also potentially affects third-party apps and add-ons that call the *cloudconnectlib.splunktacollectorlib.cloud_connect_mod_input* Python class directly.",
  "id": "GHSA-jjqg-fqrm-g2vj",
  "modified": "2023-02-23T18:31:05Z",
  "published": "2023-02-14T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22943"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2023-0213"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MV66-48P3-PFM6

Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-05-29 15:30
VLAI
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 — 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.

Severity
2.4 (Low)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
1.0 (Low)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-49318"
  ],
  "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-mv66-48p3-pfm6",
  "modified": "2026-05-29T15:30:35Z",
  "published": "2026-05-29T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49318"
    },
    {
      "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"
    }
  ]
}

GHSA-MV67-X3M9-JJ9P

Vulnerability from github – Published: 2023-08-17 18:31 – Updated: 2024-04-04 07:01
VLAI
Details

A vulnerability was reported in BIOS for ThinkPad P14s Gen 2, P15s Gen 2, T14 Gen 2, and T15 Gen 2 that could cause the system to recover to insecure settings if the BIOS becomes corrupt.

Severity
8.4 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-4030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-17T17:15:10Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was reported in BIOS for ThinkPad P14s Gen 2, P15s Gen 2, T14 Gen 2, and T15 Gen 2 that could cause the system to recover to insecure settings if the BIOS becomes corrupt.",
  "id": "GHSA-mv67-x3m9-jj9p",
  "modified": "2024-04-04T07:01:57Z",
  "published": "2023-08-17T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4030"
    },
    {
      "type": "WEB",
      "url": "https://support.lenovo.com/us/en/product_security/LEN-134879"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P9JG-FCR6-3MHF

Vulnerability from github – Published: 2026-07-01 21:51 – Updated: 2026-07-01 21:51
VLAI
Summary
OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms
Details

Summary

A flaw in com.ongres.scram:scram-client allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from SCRAM-SHA-256-PLUS (with channel binding) to standard SCRAM-SHA-256 (without channel binding), bypassing strict client-side enforcement policies.

Component Breakdown

This occurs due to a two-part failure in TlsServerEndpoint when a server presents an X.509 certificate using a modern signature algorithm that lacks traditional WITH naming structures (such as Ed25519 or post-quantum algorithms):

  1. The internal hash derivation method fails to parse the algorithm name, swallows the resulting NoSuchAlgorithmException, and silently returns an empty byte array via the deprecatedgetChannelBindingData()` API.
  2. The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.

Impact & Scope

This issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).

Drivers operating under a "prefer" or "allow" policy (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.

Remediation

Update your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.

If you are interacting with the ScramClient builder API directly (e.g., writing a custom driver or database extension):

  • Migrate Deprecated APIs: Stop using TlsServerEndpoint.getChannelBindingData(). Transition immediately to TlsServerEndpoint.getChannelBindingHash(), which correctly propagates NoSuchAlgorithmException up the stack.
  • Adopt Explicit Policies: Leverage the newly introduced ChannelBindingPolicy API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.
ScramClient client = ScramClient.builder()
    .advertisedMechanisms(serverMechanisms)
    .username(user)
    .password(pass)
    // Explicitly enforce strict boundaries if needed.
    .channelBindingPolicy(ChannelBindingPolicy.REQUIRE) 
    .channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)
    .build();
Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.ongres.scram:scram-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.ongres.scram:scram-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:51:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA flaw in `com.ongres.scram:scram-client` allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from `SCRAM-SHA-256-PLUS` (with channel binding) to standard `SCRAM-SHA-256` (without channel binding), bypassing strict client-side enforcement policies.\n\n## Component Breakdown\n\nThis occurs due to a two-part failure in `TlsServerEndpoint` when a server presents an `X.509` certificate using a modern signature algorithm that lacks traditional `WITH` naming structures (such as `Ed25519` or post-quantum algorithms):\n\n1. The internal hash derivation method fails to parse the algorithm name, swallows the resulting `NoSuchAlgorithmException, and silently returns an empty byte array via the deprecated `getChannelBindingData()` API.\n2. The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.\n\n## Impact \u0026 Scope\n\nThis issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).\n\nDrivers operating under a \"prefer\" or \"allow\" policy  (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.\n\n## Remediation\n\nUpdate your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.\n\nIf you are interacting with the `ScramClient` builder API directly (e.g., writing a custom driver or database extension):\n\n- Migrate Deprecated APIs: Stop using `TlsServerEndpoint.getChannelBindingData()`. Transition immediately to `TlsServerEndpoint.getChannelBindingHash()`, which correctly propagates `NoSuchAlgorithmException` up the stack.\n- Adopt Explicit Policies: Leverage the newly introduced `ChannelBindingPolicy` API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.\n\n```java\nScramClient client = ScramClient.builder()\n    .advertisedMechanisms(serverMechanisms)\n    .username(user)\n    .password(pass)\n    // Explicitly enforce strict boundaries if needed.\n    .channelBindingPolicy(ChannelBindingPolicy.REQUIRE) \n    .channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)\n    .build();\n```",
  "id": "GHSA-p9jg-fcr6-3mhf",
  "modified": "2026-07-01T21:51:17Z",
  "published": "2026-07-01T21:51:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ongres/scram"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms"
}

GHSA-Q2GC-XJQW-QP89

Vulnerability from github – Published: 2026-04-09 17:32 – Updated: 2026-05-06 02:40
VLAI
Summary
OpenClaw: strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts
Details

Impact

strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts.

The approval-timeout fallback could allow inline eval commands that strictInlineEval was meant to require explicit approval for.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <=2026.4.2
  • Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @zsxsoft and @KeenSecurityLab for reporting.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
5.9 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:32:49Z",
    "nvd_published_at": "2026-04-28T19:37:46Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nstrictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts.\n\nThe approval-timeout fallback could allow inline eval commands that strictInlineEval was meant to require explicit approval for.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c=2026.4.2`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @zsxsoft and @KeenSecurityLab for reporting.",
  "id": "GHSA-q2gc-xjqw-qp89",
  "modified": "2026-05-06T02:40:53Z",
  "published": "2026-04-09T17:32:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-q2gc-xjqw-qp89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42423"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/d7c3210cd6f5fdfdc1beff4c9541673e814354d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-strictinlineeval-approval-boundary-bypass-via-approval-timeout-fallback"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts"
}

GHSA-Q5JF-9VFQ-H4H7

Vulnerability from github – Published: 2026-04-10 15:33 – Updated: 2026-04-24 20:42
VLAI
Summary
Helm's plugin verification fails open when .prov is missing, allowing unsigned plugin install
Details

Helm is a package manager for Charts for Kubernetes. In Helm versions >=4.0.0 and <=4.1.3, Helm will install plugins missing provenance (.prov file) when signature verification is required.

Impact

The bug allows plugin authors to omit provenance (signing) data from plugins, bypassing plugin signature verification upon plugin install/update.

Notably, plugin hooks will be executed as designed on the installed plugin, enabling a malicious plugin to execute arbitrary code.

Patches

This issue has been patched in Helm v4.1.4

Installing/updating a plugin with missing provenance will error if signature verification is required.

Workarounds

Users may manually validate that a plugin archive is not missing provenance data (.prov file) before installation.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.4 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T15:33:03Z",
    "nvd_published_at": "2026-04-09T16:16:27Z",
    "severity": "HIGH"
  },
  "details": "Helm is a package manager for Charts for Kubernetes. In Helm versions \u003e=4.0.0 and \u003c=4.1.3, Helm will install plugins missing provenance (`.prov` file) when signature verification is required.\n\n### Impact\n\nThe bug allows plugin authors to omit provenance (signing) data from plugins, bypassing plugin signature verification upon plugin install/update.\n\nNotably, plugin hooks will be executed as designed on the installed plugin, enabling a malicious plugin to execute arbitrary code.\n\n### Patches\n\nThis issue has been patched in Helm v4.1.4\n\nInstalling/updating a plugin with missing provenance will error if signature verification is required.\n\n### Workarounds\n\nUsers may manually validate that a plugin archive is not missing provenance data (`.prov` file) before installation.",
  "id": "GHSA-q5jf-9vfq-h4h7",
  "modified": "2026-04-24T20:42:00Z",
  "published": "2026-04-10T15:33:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/security/advisories/GHSA-q5jf-9vfq-h4h7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/05fa37973dc9e42b76e1d2883494c87174b6074f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/helm/helm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/releases/tag/v4.1.4"
    },
    {
      "type": "WEB",
      "url": "https://helm.sh/docs/topics/provenance/#the-provenance-file"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Helm\u0027s plugin verification fails open when .prov is missing, allowing unsigned plugin install"
}

GHSA-QVR7-G57C-MRC7

Vulnerability from github – Published: 2026-03-13 15:48 – Updated: 2026-04-07 18:10
VLAI
Summary
OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode
Details

Summary

In affected versions of openclaw, local gateway helper credential resolution treated configured but unavailable gateway.auth.token and gateway.auth.password SecretRefs as if they were unset and could fall back to gateway.remote.* credentials in local mode.

Impact

This could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue.

Affected Packages and Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.3.8
  • Fixed in: 2026.3.11

Technical Details

The local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked "absent" to the helper layer.

Fix

OpenClaw now tracks whether the local auth input is configured separately from whether it resolves successfully. In local mode, remote fallback is allowed only when the matching local auth input is truly unset. The fix shipped in openclaw@2026.3.11.

Workarounds

Upgrade to 2026.3.11 or later.

Severity
2.5 (Low)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T15:48:21Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\nIn affected versions of `openclaw`, local gateway helper credential resolution treated configured but unavailable `gateway.auth.token` and `gateway.auth.password` SecretRefs as if they were unset and could fall back to `gateway.remote.*` credentials in local mode.\n\n## Impact\nThis could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue.\n\n## Affected Packages and Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.8`\n- Fixed in: `2026.3.11`\n\n## Technical Details\nThe local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked \"absent\" to the helper layer.\n\n## Fix\nOpenClaw now tracks whether the local auth input is configured separately from whether it resolves successfully. In local mode, remote fallback is allowed only when the matching local auth input is truly unset. The fix shipped in `openclaw@2026.3.11`.\n\n## Workarounds\nUpgrade to `2026.3.11` or later.",
  "id": "GHSA-qvr7-g57c-mrc7",
  "modified": "2026-04-07T18:10:22Z",
  "published": "2026-03-13T15:48:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qvr7-g57c-mrc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32970"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-credential-fallback-logic-bypass-via-unavailable-local-auth-secretrefs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode"
}
Mitigation
Architecture and Design

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.

← Back to the CWE list