SmileCDR HAPI FHIR EUVD-2026-108276

Exploitation requires an authenticated SmileCDR/HAPI FHIR user account that holds the CREATE permission but lacks READ permission on the target data, and the use of the FHIR conditional create operation with a search predicate the attacker constructs to match an existing resource. The disclosure only occurs when that predicate matches an already-existing resource. Limiting factors: the attacker must already possess valid low-privilege credentials with CREATE rights (PR:L - not remote-unauthenticated), and must be able to formulate a predicate that matches the target resource, so blind data exfiltration is constrained by how guessable or enumerable the matching search criteria are.

This is a genuine but moderate-severity authorization flaw, not a drop-everything emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and is internally consistent with the description: network-reachable, low attack complexity, but requiring low privileges (PR:L) - specifically an authenticated account that already holds CREATE permission. Impact is confidentiality-only and rated Low (VC:L), reflecting that the leak is limited to the contents of a resource whose matching predicate the attacker can already construct, not a bulk database read. No EPSS score, CISA KEV listing, or PoC/exploit reference was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the moderate score and absence of exploitation signals. The clearest tension in the input is the 'Authentication Bypass' tag versus the actual mechanism: CWE-863 (Incorrect Authorization) and the description both describe an authorization/permission-model failure by an already-authenticated user, not an authentication bypass - verify categorization before routing. Overall: a real, patch-worthy authorization/data-exposure bug warranting scheduled remediation, not crisis response.

An attacker who holds a valid SmileCDR/HAPI FHIR account with CREATE but not READ permission issues a conditional create request whose search predicate is crafted to match an existing resource they are not authorized to read. Because the conditional-create authorization path does not enforce READ permission, the server returns the matched target resource's contents, disclosing data the user should not see. No public exploit code was identified in the provided sources.