Repofyr is a FHIR data repository. A deployment holds protected health information, so a defect in authorization, auditing, or query handling is a patient-privacy defect. We take vulnerability reports seriously and prefer coordinated disclosure.
Please do NOT open a public GitHub issue for a suspected vulnerability.
- Preferred: use GitHub private vulnerability reporting on
srdc/repofyr(Security tab, "Report a vulnerability"). - Alternatively, email
onfhir@srdc.com.tr.
Include the affected artifact and version, the FHIR release involved (R4, R5, or STU3), a description, and reproduction steps or a proof of concept if available. We aim to acknowledge reports within five business days.
| Version | Supported |
|---|---|
| 4.0.x | yes |
3.x and earlier (io.onfhir monorepo server line) |
no |
The io.onfhir:onfhir-server-* artifacts ended at 3.x and receive no
security fixes. Moving to io.repofyr:repofyr-server-* 4.0.x is the
supported path; the upgrade needs no configuration or data migration. See
the migration guide.
Repofyr stores and serves PHI, so the following are in scope:
- Authorization. Any way to read or write a resource that the presented access token does not grant: SMART scope evaluation, compartment constraints, token resolution and introspection, and the content constraints applied to submitted resources.
- Auditing. An interaction that should produce an AuditEvent and does not, or an AuditEvent that misattributes the actor or the target.
- Search parameter handling. Query construction is where caller input
reaches the database. Injection into a MongoDB query, a search parameter
that returns resources outside the caller's authorized set, and a
_include,_revinclude, or chained parameter that discloses a resource the caller could not read directly are all vulnerabilities. - Content is not trusted code. FHIRPath expressions, profiles, search parameter definitions, and mapping templates are data. Server behavior that lets such content read process state, the environment, or the filesystem is a vulnerability.
Two properties of the design are intended, and a deployment that ignores them is misconfigured rather than exploiting a defect:
OperationDefinition.nameholds a fully qualified handler class name that Repofyr instantiates reflectively. Write access to OperationDefinition resources, and to the configured operation definitions folder, is therefore an administrative privilege and must not be granted to ordinary API clients.- Running with
server.ssl.keystoreunset, or withfhir.authorization.methodset tonone, disables transport security or authorization by request. Neither is a vulnerability on its own.
Known, deliberately documented gaps are listed in
docs/release/known-limitations.md.
Those are not vulnerabilities in themselves, but a report showing that one
is exploitable beyond what is documented there is, and is welcome.
Repofyr depends on the io.onfhir reusable libraries, released separately
under Apache-2.0. A vulnerability in FHIRPath evaluation, profile or
terminology validation, the FHIR client, the query engine, or the neutral
HTTP models belongs to
srdc/onfhir-libs and should be
reported through that repository's security policy. If you are not sure
which side a defect is on, report it here and we will route it - the
dividing line is the coordinate: io.repofyr here, io.onfhir there.