CWE-213, Exposure of Sensitive Information Due to Incompatible Policies, describes a product that exposes information exactly as its developer intended, while that information is sensitive under the policies of other stakeholders such as administrators, users or the people whose data is processed.
So nothing is broken in the usual sense. The code does what it was written to do. The problem is that the developer's policy and the stakeholders' policies do not match.
How it happens
MITRE notes that when handling information, a developer must consider whether different stakeholders regard it as sensitive. Each stakeholder has an intended security policy the product is expected to uphold. If the developer treats data as harmless, the product can break users' expectations.
The observed examples all involve a script that calls phpinfo(): CVE-2002-1725, CVE-2004-0033, CVE-2003-1181 and CVE-2004-1422. To a developer, a diagnostic page is useful. To an administrator, it exposes configuration they never meant to publish.
What an attacker gains
MITRE lists confidentiality: reading application data. The attacker gets whatever the feature was designed to show.
How to find it
MITRE lists no detection methods. A useful review asks, for each feature that shows data: who sees it, and would the owner of that data agree? Ask administrators and users, not only the team that built it. Look for leftover diagnostic pages in deployed environments.
How to fix it
MITRE gives no mitigations. Practical steps are to list stakeholders early, record what each considers sensitive, remove or restrict diagnostic and informational pages in production, and re-check when features change who can see what.
Quick check
If the code works as designed, why is it a weakness?
Because the design assumed one policy about the data, and other stakeholders hold a stricter one.
