CVE-2026-86262: Unauthenticated Order Modification and Disclosure in hosp_order

Astra Security

2026-09-07 (Updated: 2026-09-07)

CVE Reports

IDOR, access-control-bypass, horizontal-privilege-escalation, java

Summary

The Java application hosp_order, by sfturing, exposes an OrderUserCenter handler intended to list and update the signed-in user’s own orders. On the tested rolling-release build (commit 627f426) the handler trusts caller-supplied id and userID fields instead of a session-derived identity, so a remote, unauthenticated caller can overwrite another user’s order status and disease information and read that user’s appointment records in the response. The advisory range covers the tested commit and prior historical versions, but only the 627f426 build was exercised; no code execution or host takeover was observed and no upstream fix has been verified.

Vulnerability mechanism

Intended authorization

OrderUserCenter is meant to operate on the current user’s order list: render that user’s orders and, when an update is requested, change only orders belonging to them. The trust boundary should be the authenticated session, with the caller’s identity determining both the order id that may be touched and the userID used to scope the read.

Controlled inputs and flow

The handler accepts id, userID, and diseaseInfo directly from the request. In the reviewed source (OrderController.java), these flow into two update operations and one query: updateOrderSta1 and updateOrderdiseaseInfo are filtered by the request id, after which orders are selected by the request userID and rendered to the caller. The sequence runs update-then-read in a single handler invocation.

Missing check and effect

No step links the supplied id or userID to a session user. The underlying SQL predicates only on id or userID with no ownership constraint, so the request parameters themselves define both the write target and the read scope. Because no authentication gate precedes the updates or query, an unauthenticated caller who knows or guesses a victim order id and userID can change that order’s submission status, overwrite its disease fields, and receive the victim’s appointment records in the response. The flaw is an authorization omission, not a cryptographic or injection failure; the integrity-protected surface is simply never consulted.

Prerequisites and attack logic

The attack itself requires no account or session cookie; the prerequisites are network reachability of the OrderUserCenter endpoint and a deployment built from the vulnerable commit 627f426 or an equivalent earlier version. The upstream endpoint is POST-only — GET returned 405 during testing — and the GET-to-POST normalization used in the lab was a compatibility shim, not native application behavior, so only POST reachability should be inferred. Given a reachable POST handler, the caller supplies a victim order id and a userID; because no ownership validation ties those values to any session, the update and query execute against the victim’s data, producing the observed modification and disclosure. Equivalent configurations on untested historical commits are plausible but not demonstrated.

Core pseudocode

function handleOrderUserCenter(request):
  orderID     = request.input.id          # caller-supplied, no session bind
  userID      = request.input.userID      # caller-supplied, no session bind
  diseaseInfo = request.input.diseaseInfo
  updateOrderSta1(orderID)                # sink A: WHERE id = orderID
  updateOrderdiseaseInfo(orderID, diseaseInfo)  # sink B: overwrite disease WHERE id = orderID
  orders = queryOrdersByUserID(userID)    # sink C: WHERE userID = userID
  return render(orders)

The decisive gap is that the handler binds every update and query solely to caller-supplied id and userID and never compares either against an authenticated session user, so any reachable caller controls both the write target and the read scope. The model below traces that single connected flow: three sinks execute against request input with no ownership gate between input and effect.

Affected scope

Advisory affected range: rolling release at commit 627f426331da8086ce8fff2017d65b1ddef384f8 and prior historical versions. Tested release: the 627f426 build only. Verified fix: none; no fix commit was confirmed at the time of this report, and fixed versions remain unknown.

Runtime-observed impact (627f426, specific seed data): an unauthenticated request set victim order status 0 to 1, overwrote disease information fields, and disclosed victim appointment records in the response. No code execution or host takeover was observed; that negative result does not preclude other untested vectors.

Source comparison: OrderController.java SQL predicates only on id or userID with no ownership constraint to a session user, consistent with the runtime effect but not itself a runtime test.

Inferred or untested: prior historical versions are treated as affected by the advisory but were not per-version tested, so the single-build observation cannot establish that every release is exploitable. The GET-to-POST normalization was lab-only; native GET support is not claimed, and no CVSS score or severity rating is stated in the source report.

Remediation and detection

At the trust boundary, the handler should derive userID from the authenticated session rather than accepting it from the client, and should verify that the requested order id belongs to that session user before performing updateOrderSta1, updateOrderdiseaseInfo, or the userID-scoped query. Authoritative guidance should be sought from the upstream repository, because no verified fix commit is available; the preceding items are mechanism-based recommendations, not vendor-confirmed remediation. For detection, correlate unexpected order-status or disease-field changes and order-list disclosures against the originating session and caller identity; an update or read executed without a bound session user is an investigation lead, not proof, since legitimate administrative or batch flows could produce similar observations and would need to be ruled out. The source material provides no detection guidance beyond these observations.