CWE-202: Exposure of Sensitive Information Through Data Queries
BaseLikelihood of exploit: Medium
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user -- e.g., by specifying search terms that are known to be unique to that user.
Consequences
- Confidentiality: Read Files or Directories, Read Application Data
How to prevent it
- Architecture and Design: This is a complex topic. See the [REF-1492] for a good discussion of best practices.
Recent advisories
- GHSA-vwp5-f99x-x3rq — Backstage has improper input validation in scaffolder task list ordering
- GHSA-fr6g-7cq8-fg82 — Flowise: Information Disclosure in GET /api/v1/upsert-history returns the entire server-wide upsert history
- GHSA-54jq-c3m8-4m76 — AIOHTTP vulnerable to brute-force leak of internal static file path components
- GHSA-v64r-7wg9-23pr — Unauthenticated Craft CMS users can trigger a database backup
- GHSA-9cg9-4h4f-j6fg — phpMyFAQ has unauthenticated config backup download via /api/setup/backup
- GHSA-h27m-3qw8-3pw8 — Possible ORM Leak Vulnerability in the Harbor
- GHSA-2p89-5f22-8qvf — Exposure of Sensitive Information to an Unauthorized Actor
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor