Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1310 CNY

100%
Buy Us a Coffee

CWE-472 (对假设不可变Web参数的外部可控制) — Vulnerability Class 99

99 vulnerabilities classified as CWE-472 (对假设不可变Web参数的外部可控制). AI Chinese analysis included.

CWE-472 represents a logic flaw where web applications incorrectly assume certain input parameters are immutable, such as hidden form fields, cookies, or URL arguments, despite being fully controllable by external users. Attackers typically exploit this weakness by manipulating these trusted values to bypass authorization checks, alter business logic, or escalate privileges, effectively tricking the server into processing unauthorized actions. To mitigate this risk, developers must avoid relying on client-side data for security-critical decisions. Instead, they should enforce server-side validation for all inputs, ensuring that any parameter influencing application state is rigorously verified against expected values. By treating all user-supplied data as untrusted, regardless of its origin or apparent immutability, developers can prevent attackers from subverting application logic through simple parameter tampering.

MITRE CWE Description
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields. If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input. For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application.
Common Consequences (1)
IntegrityModify Application Data
Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cook…
Mitigations (2)
ImplementationAssume 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…
ImplementationInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
Examples (2)
In this example, a web application uses the value of a hidden form field (accountID) without having done any input validation because it was assumed to be immutable.
String accountID = request.getParameter("accountID"); User user = getUserFromID(Long.parseLong(accountID));
Bad · Java
Hidden fields should not be trusted as secure parameters.
<input type="hidden"
Bad · HTML
CVE IDTitleCVSSSeverityPublished
CVE-2026-10018 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-10019 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-10015 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-10009 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9998 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9968 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9966 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9960 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9911 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9909 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-9882 Google Chrome 安全漏洞 — Chrome--2026-05-28
CVE-2026-7571 Keycloak: keycloak: access token disclosure and implicit flow bypass via forged client data — Red Hat build of Keycloak 26.4 7.1 High2026-05-19
CVE-2026-8577 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8573 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8567 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8559 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8534 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8532 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8519 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-8510 Google Chrome 安全漏洞 — Chrome--2026-05-14
CVE-2026-7973 Google Chrome 安全漏洞 — Chrome 9.6AICriticalAI2026-05-06
CVE-2026-7969 Google Chrome 安全漏洞 — Chrome 8.8 -2026-05-06
CVE-2026-7942 Google Chrome 安全漏洞 — Chrome 6.5 -2026-05-06
CVE-2026-7912 Google Chrome 安全漏洞 — Chrome 8.8AIHighAI2026-05-06
CVE-2026-7903 Google Chrome 安全漏洞 — Chrome 8.8AIHighAI2026-05-06
CVE-2026-7896 Google Chrome 安全漏洞 — Chrome 8.8AIHighAI2026-05-06
CVE-2026-32699 FacturaScripts unauthorized modification of immutable nick field via EditUser controller — facturascripts 4.3 -2026-05-05
CVE-2026-7340 Google Chrome 安全漏洞 — Chrome 8.8AIHighAI2026-04-28
CVE-2026-4911 Booking Package <= 1.7.06 - Unauthenticated Price Manipulation via 'amount' Parameter — Booking Package 5.3 Medium2026-04-28
CVE-2026-41353 OpenClaw < 2026.3.22 - allowProfiles Bypass via Profile Mutation and Runtime Selection — OpenClaw 8.1 High2026-04-23

Vulnerabilities classified as CWE-472 (对假设不可变Web参数的外部可控制) represent 99 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.