CWE-1288
AllowedImproper Validation of Consistency within Input
Abstraction: Base · Status: Incomplete
The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.
44 vulnerabilities reference this CWE, most recent first.
GHSA-JH3J-GC93-659H
Vulnerability from github – Published: 2026-02-02 15:30 – Updated: 2026-02-02 15:30A local attacker could cause a full device reset by resetting the device passwords using an invalid reset file via USB.
{
"affected": [],
"aliases": [
"CVE-2022-50976"
],
"database_specific": {
"cwe_ids": [
"CWE-1288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-02T15:16:28Z",
"severity": "HIGH"
},
"details": "A local attacker could cause a full device reset by resetting the device passwords using an invalid reset file via USB.",
"id": "GHSA-jh3j-gc93-659h",
"modified": "2026-02-02T15:30:34Z",
"published": "2026-02-02T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50976"
},
{
"type": "WEB",
"url": "https://www.innomic.com/.well-known/csaf/white/2026/ids-2026-0001.html"
},
{
"type": "WEB",
"url": "https://www.innomic.com/.well-known/csaf/white/2026/ids-2026-0001.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VHFW-J3C3-CMGG
Vulnerability from github – Published: 2023-06-26 09:30 – Updated: 2024-04-04 05:09Multiple WAGO devices in multiple versions may allow an authenticated remote attacker with high privileges to DoS the device by sending a specifically crafted packet to the CODESYS V2 runtime.
{
"affected": [],
"aliases": [
"CVE-2023-1620"
],
"database_specific": {
"cwe_ids": [
"CWE-1288",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-26T07:15:09Z",
"severity": "MODERATE"
},
"details": "Multiple WAGO devices in multiple versions may allow an authenticated remote attacker with high privileges to DoS the device by sending a specifically crafted packet to the CODESYS V2 runtime.",
"id": "GHSA-vhfw-j3c3-cmgg",
"modified": "2024-04-04T05:09:45Z",
"published": "2023-06-26T09:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1620"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2023-006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WCVJ-VPVW-9RR5
Vulnerability from github – Published: 2026-05-27 12:31 – Updated: 2026-07-01 18:54A flaw was found in Keycloak, an open-source identity and access management solution. When a client application is configured to accept broad redirect Uniform Resource Identifiers (URIs), a remote attacker can manipulate the authentication process by crafting a special web address. If a user clicks this link, the client application might incorrectly prioritize attacker-controlled information over legitimate data. This vulnerability, known as HTTP parameter pollution, could allow an attacker to bypass security measures or gain unauthorized access to resources.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.5.0"
},
{
"last_affected": "26.6.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.4.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9689"
],
"database_specific": {
"cwe_ids": [
"CWE-1288"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T18:54:49Z",
"nvd_published_at": "2026-05-27T12:17:15Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak, an open-source identity and access management solution. When a client application is configured to accept broad redirect Uniform Resource Identifiers (URIs), a remote attacker can manipulate the authentication process by crafting a special web address. If a user clicks this link, the client application might incorrectly prioritize attacker-controlled information over legitimate data. This vulnerability, known as HTTP parameter pollution, could allow an attacker to bypass security measures or gain unauthorized access to resources.",
"id": "GHSA-wcvj-vpvw-9rr5",
"modified": "2026-07-01T18:54:49Z",
"published": "2026-05-27T12:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9689"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/issues/49430"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/49959"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/18832bcae5bebd5a1d66c2ec5fcd640e576fa625"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/1f58a4b79a258bcf2ef86b58fbf0016cdb91291f"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/267a1a33d4dc1eac7622614ba9772b4e1e35726f"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-9689"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2481845"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak Services has Improper Validation of Consistency within Input"
}
GHSA-WG67-7CXP-7WP8
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-06-30 03:36In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Do not skip unrelated mode changes in DSC validation
Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream.
However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc().
At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on:
BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977
Workqueue: events drm_mode_rmfb_work_fn Call Trace: dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980
Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc().
(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
{
"affected": [],
"aliases": [
"CVE-2026-31488"
],
"database_specific": {
"cwe_ids": [
"CWE-1288",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Do not skip unrelated mode changes in DSC validation\n\nStarting with commit 17ce8a6907f7 (\"drm/amd/display: Add dsc pre-validation in\natomic check\"), amdgpu resets the CRTC state mode_changed flag to false when\nrecomputing the DSC configuration results in no timing change for a particular\nstream.\n\nHowever, this is incorrect in scenarios where a change in MST/DSC configuration\nhappens in the same KMS commit as another (unrelated) mode change. For example,\nthe integrated panel of a laptop may be configured differently (e.g., HDR\nenabled/disabled) depending on whether external screens are attached. In this\ncase, plugging in external DP-MST screens may result in the mode_changed flag\nbeing dropped incorrectly for the integrated panel if its DSC configuration\ndid not change during precomputation in pre_validate_dsc().\n\nAt this point, however, dm_update_crtc_state() has already created new streams\nfor CRTCs with DSC-independent mode changes. In turn,\namdgpu_dm_commit_streams() will never release the old stream, resulting in a\nmemory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to\nthe new stream either, which manifests as a use-after-free when the stream gets\ndisabled later on:\n\nBUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu]\nWrite of size 4 at addr ffff88813d836524 by task kworker/9:9/29977\n\nWorkqueue: events drm_mode_rmfb_work_fn\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6e/0xa0\n print_address_description.constprop.0+0x88/0x320\n ? dc_stream_release+0x25/0x90 [amdgpu]\n print_report+0xfc/0x1ff\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x225/0x4e0\n ? dc_stream_release+0x25/0x90 [amdgpu]\n kasan_report+0xe1/0x180\n ? dc_stream_release+0x25/0x90 [amdgpu]\n kasan_check_range+0x125/0x200\n dc_stream_release+0x25/0x90 [amdgpu]\n dc_state_destruct+0x14d/0x5c0 [amdgpu]\n dc_state_release.part.0+0x4e/0x130 [amdgpu]\n dm_atomic_destroy_state+0x3f/0x70 [amdgpu]\n drm_atomic_state_default_clear+0x8ee/0xf30\n ? drm_mode_object_put.part.0+0xb1/0x130\n __drm_atomic_state_free+0x15c/0x2d0\n atomic_remove_fb+0x67e/0x980\n\nSince there is no reliable way of figuring out whether a CRTC has unrelated\nmode changes pending at the time of DSC validation, remember the value of the\nmode_changed flag from before the point where a CRTC was marked as potentially\naffected by a change in DSC configuration. Reset the mode_changed flag to this\nearlier value instead in pre_validate_dsc().\n\n(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)",
"id": "GHSA-wg67-7cxp-7wp8",
"modified": "2026-06-30T03:36:22Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31488"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27353"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27354"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30848"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-31488"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2460619"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10862e344b4d6434642a48c87d765813fc0b0ba7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/111208b5b7ebcdadb3f922cc52d8425f0fa91b33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21159d8b335a6b9f44cbb506733013a902ae2da4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a5edc97fd9c6415ff2eff872748439a97e3c3d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed3d041ab061ec8a64f50a3edda0f4db7280025"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da1d0ed31e9802fd99384f43cc63678a5a11cb41"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31488.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
No CAPEC attack patterns related to this CWE.