Fire Arrow Server 1.10.0

Fire Arrow Server 1.10.0 has been released.

• (feature) $generate-durable-token and $generate-one-time-token are now governed by all validators, not just Allowed
• (breaking) Token-generation rules using the wildcard resource: "*" are rejected at startup
• (security) Update Next.js to 16.2.6 (CVE-2026-23870, CVE-2026-44573, CVE-2026-44575, CVE-2026-44579, CVE-2026-44580, CVE-2026-44581, CVE-2026-44576, CVE-2026-44582, CVE-2026-45109)
• (feature) New _synchronous mode for CarePlan/$subscribe-due-events returns materialized Task IDs in the response
• (bugfix) Questionnaire media viewer recovers automatically when pre-signed URLs expire

Validator Support for Token-Generation Operations

The $generate-durable-token and $generate-one-time-token operations issue API tokens that act on behalf of an identity resource (Patient, Practitioner, Device, RelatedPerson). Until now, token-generation rules only worked under the Allowed validator. Operators who wanted to mint tokens under a narrower scope — for example, only for patients in a practitioner's compartment, or only for the patients a care team is responsible for — could not express that with a single rule. The common workaround was to keep the generate-*-token rule under Allowed and pair it with a separate operation: update rule under the appropriate validator, because the underlying authorization framework only considered the update rule's scope when checking who a token could be issued for.

Starting with 1.10.0, every validator that the server supports can be used on a token-generation rule. Tokens can now be issued under any available scope directly from the generate-*-token rule. For example, restricting practitioners to mint durable tokens only for patients in their compartment is now a single rule:

fire-arrow:
  authorization:
    validation-rules:
      - client-role: Practitioner
        resource: Patient
        operation: generate-durable-token
        validator: PractitionerCompartment

Token-generation rules are now self-contained: the chosen validator decides both whether the operation may be invoked and which target instance the caller is allowed to issue a token for. A separate update rule is no longer required for token generation to work.

Action Required: Remove Redundant update Rules

If your authorization configuration carries an operation: update rule that was added solely to enable token generation under a non-Allowed validator, you should remove it after upgrading. That rule grants the client full write access to every instance the validator's scope reaches — far more permission than token generation needs. Removing it tightens the client's permissions to exactly what the new model requires, with no loss of functionality.

Keep the update rule if the client also performs regular PUT requests for reasons unrelated to token generation. In that case it continues to authorize those updates independently.

The full migration note is documented at the top of the API Tokens authorization section.

Breaking Change

As part of this work, the wildcard form resource: "*" is no longer accepted on token-generation rules. Token-generation only ever applies to the four identity resource types, and the wildcard previously expanded to a server-wide write grant covering every resource type — far broader than what the operation requires.

Deployments that currently have a rule of this shape:

- operation: generate-durable-token
  resource: "*"
  validator: Allowed

must update their configuration before upgrading. Replace the wildcard with explicit per-resource-type rules for the identity types tokens should be issuable for:

- operation: generate-durable-token
  resource: Patient
  validator: Allowed
- operation: generate-durable-token
  resource: Practitioner
  validator: Allowed
- operation: generate-durable-token
  resource: Device
  validator: Allowed
- operation: generate-durable-token
  resource: RelatedPerson
  validator: Allowed

The server logs the offending rule and refuses to start when a wildcard is encountered. Deployments that already enumerate resource types are unaffected.

Security

Next.js updated to 16.2.6

The administration web UI's Next.js dependency has been updated from 16.2.3 to 16.2.6 to address a cluster of advisories disclosed across the 16.2.4, 16.2.5, and 16.2.6 patch releases. The most operationally relevant ones for Fire Arrow Server deployments are:

CVE	Severity	Summary
CVE-2026-23870	High (7.5)	Specially crafted requests to App Router Server Function endpoints can trigger excessive CPU usage and denial of service.
CVE-2026-44573	High (7.5)	Middleware/proxy authorization bypass on Pages Router applications using i18n, via locale-less /_next/data/<buildId>/<page>.json requests.
CVE-2026-44575 / CVE-2026-45109	High (7.5)	Middleware/proxy authorization bypass on App Router applications via segment-prefetch (.rsc) routes; the follow-up CVE addresses the case of middleware.ts running under Turbopack.
CVE-2026-44579	High (7.5)	Connection-exhaustion denial of service on applications using Cache Components / Partial Prerendering, via crafted Next-Resume headers.
CVE-2026-44580	Medium (6.1)	Cross-site scripting in beforeInteractive scripts when untrusted input is embedded.
CVE-2026-44581	Medium (4.7)	Stored cross-site scripting via malformed CSP nonce values reflected into rendered HTML.
CVE-2026-44576 / CVE-2026-44582	Medium / Low	Cache-poisoning of React Server Component responses behind shared caches that do not partition response variants correctly.

No application-side configuration change is required to pick up the fixes; the upgraded admin UI is bundled with the server image.

Synchronous Mode for $subscribe-due-events

The CarePlan/$subscribe-due-events operation activates a Subscription that triggers Task materialization for due CarePlan activities. Until now, the operation returned as soon as the Subscription was committed — Task materialization itself ran asynchronously and the materialized Tasks only became queryable a few seconds later. Orchestrators that wanted to act on the first due Task immediately (for example, dispatching it to a downstream system) had to poll the FHIR API until the Tasks appeared, which added wall-clock latency and wasted FHIR searches on each cold call.

Starting with 1.10.0, $subscribe-due-events accepts a new optional _synchronous parameter. When set to true, the operation blocks the HTTP response until immediate Task materialization has completed and returns the materialized Task IDs in the response Parameters:

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "subscriptionId", "valueId": "Subscription/123" },
    { "name": "effectiveEnd", "valueInstant": "2026-06-01T00:00:00Z" },
    { "name": "action", "valueString": "created" },
    {
      "name": "task",
      "part": [
        { "name": "taskId", "valueId": "Task/456" },
        { "name": "status", "valueString": "ready" }
      ]
    }
  ]
}

The synchronous wait is bounded at 10 seconds. If materialization does not complete inside that window, the operation still returns 200 OK with synchronousTimedOut=true in the response and the caller can fall back to the usual notification path — the asynchronous materialization continues to run regardless of the synchronous outcome.

Default behaviour is unchanged. With _synchronous absent or false, the response shape is identical to previous releases and no extra processing runs.

The new parameter is documented in CarePlan Events › Waiting for Initial Materialization and in the $subscribe-due-events reference.

Bug Fixes

Questionnaire media viewer breaking after SAS URL expiry

Questionnaire items can carry inline media (images and videos) as Attachment references. The server returns those attachments with a freshly pre-signed download URL on every Questionnaire READ — the URL is short-lived by design (around two minutes in default configurations), and clients are expected to re-read the parent Questionnaire if the URL goes stale.

In the administration UI's questionnaire-builder preview pane, and in the patient-dashboard's QuestionnaireResponse viewer, that recovery did not run. As soon as the pre-signed URL expired the embedded image or video silently broke and showed only a generic load-error indicator, requiring the operator to manually refresh the page. The QuestionnaireResponse viewer additionally had no error handling at all, so an expired URL produced a broken media element with no visible error message.

In 1.10.0 both viewers correctly detect the expired URL, re-read the parent Questionnaire to obtain a freshly signed URL, and recover the media in place. The pre-signed URL lifetime configured on the server (presigned-url.expiration-seconds) is unchanged.