| Titolo | Azuriom Azuriom CMS 1.2.12 Time-of-check Time-of-use |
|---|
| Descrizione | Title / Summary:
Azuriom CMS ≤ 1.2.12 — Race Condition (TOCTOU) in Money Transfer Function leading to duplication of in-game currency
Fixed in: commit ae5596a on master (unreleased as of 1.2.12; expected in the next release)
Authentication required: Yes — any authenticated, low-privilege user (regular "member")
Precondition: Administrator has enabled "Enable money transfer between users" in Global settings
Disclosure-timing request:
Because the fix is committed on GitHub but not yet in any released version (latest release 1.2.12 remains vulnerable), the Proof of Concept(PoC) provided to Azuriom is not hosted on any accessible linked disclosure and is available on request. I request that the CVE be reserved now and that public disclosure of the detailed PoC be aligned with the next Azuriom release.
Coordination note:
The vendor was notified on 29 June 2026 (15:09 UTC). They initially declined, citing rate limiting and requesting demonstration on a realistic non-local deployment; I supplied a cloud-based PoC reproducing the issue (18:23 UTC, 29 June). The vendor then reversed their assessment, acknowledged the vulnerability, and patched it in commit ae5596a (19:19 UTC, 29 June). They subsequently closed the report as a duplicate of prior researcher submissions (22:15 UTC, 29 June). No CVE was assigned by the vendor or any other CNA as a result; to my knowledge no CVE currently exists for this issue. I have not approached any other CNA. Full email thread available on request.
Technical description:
The money-transfer handler performs the balance check and the balance deduction as two separate, non-atomic operations. A sender's "sufficient funds" check and the subsequent deduction are not wrapped in a single transaction, nor is the sender's balance row locked for the duration. This opens a TOCTOU window: an authenticated user who issues multiple concurrent transfer requests has every request read the same pre-deduction balance and pass the sufficient-funds check before any deduction commits. Each request then deducts and credits the recipient independently, allowing the sender to transfer more than they hold. The sender's balance goes negative while the recipient receives the full amount per request — a net duplication of currency. The fix in commit ae5596a wraps the operation in a database transaction and acquires a row-level lock (lockForUpdate) on the sender before re-reading and checking the balance, which serializes concurrent requests and closes the window.
Reproduction (local instance, confirmed on 1.2.12):
Two accounts: an attacker-controlled "member" with balance 1000, a recipient with balance 0.
As the member, submit a transfer of 1000 to the recipient and intercept the POST to the transfer endpoint.
Using parallel/grouped sending (e.g. Burp's parallel send), issue ~20 concurrent copies of the request.
Result: the member's balance reads -4000 (i.e. 5000 total transferred from a 1000 balance) and the recipient receives the full 5000. Demonstrated, not theoretical.
A second PoC reproduces the same result against a non-local cloud deployment, confirming the race is exploitable under real network conditions rather than only on localhost.
Impact:
Demonstrated duplication of in-game currency by an authenticated low-privilege user.
Credit: Teo Zhao Rong Javier |
|---|
| Utente | javiertzr01 (UID 99390) |
|---|
| Sottomissione | 30/06/2026 03:33 (2 mesi fa) |
|---|
| Moderazione | 16/08/2026 10:56 (2 months later) |
|---|
| Stato | Accettato |
|---|
| Voce VulDB | 391154 [Azuriom CMS fino a 1.2.12 Money Transfer ProfileController.php transferMoney race condition] |
|---|
| Punti | 17 |
|---|