Tabung Haji Restores Core Services; Three THiJARI Functions Remain Unavailable

Illustrative photograph representing digital access; this is not a Tabung Haji workstation. Photo: Clay Banks / Unsplash, used under the Unsplash License.

Service recovery news and analysis · October 12, 2026. Malaysia's Tabung Haji announced that its core systems and services had resumed after last week's cyber incident. Three THiJARI functions remain unavailable: password resets, new user registration and online account opening. The restoration announcement is today's development; the original disruption began earlier.

What the October 12 announcement establishes

RTM's report at 11:47 a.m. Malaysian time and Bernama's 12:51 p.m. report attribute the update to a Tabung Haji statement. It described security checks, strengthened controls and system recovery before reopening.

Branches in Kedah, Terengganu and Kelantan reopened on October 11; those in other states reopened on October 12. Tabung Haji also said services through strategic banking partners had resumed, that it was working with external experts and that it had reported the incident to police, NACSA and the personal data protection department. Its assurance that depositors' savings are safe is a company statement, not an independent audit by Makezaa.

FMT's October 12 coverage dates detection of suspicious activity to October 7 and the precautionary service suspension to October 8. This chronology distinguishes detection, containment and recovery rather than assigning them one date.

Restoration should be described by function

The public update supports a more precise description than either “everything is down” or “everything is fixed.” People who already have access and people who need to establish or recover access can face different experiences. A service may be useful to the first group while an unavailable onboarding or recovery function still blocks the second.

That is why a recovery notice should list functions, not just an overall status label. It should tell readers which action is available, which remains restricted and where the next update will appear. An unavailable password-reset flow, for example, matters directly to someone who cannot sign in even if the surrounding application loads.

Makezaa has not tested private accounts or every banking integration. The reported reopening does not establish successful operation for every user or channel at every moment. Service status can change after publication; readers should check the institution's official channels for their current situation.

Why staged reopening can be reasonable

The following is operational analysis, not a description of Tabung Haji's undisclosed architecture. Organisations recovering from a cyber incident may separate read access, account changes and higher-impact actions because each requires different checks. A cautious sequence allows a team to observe behaviour before enabling the next function.

Identity-related workflows deserve their own verification. Password recovery, registration and account creation can change who is allowed to act in a system. In a generic recovery exercise, useful tests would check whether authorisation still applies consistently, whether old sessions behave as intended and whether attempted misuse produces an actionable alert.

Those tests should include failures. If a dependent service times out halfway through a request, the application needs a defined outcome rather than an ambiguous success message. A page being reachable is evidence of availability at that layer; it does not establish the correctness of a complete transaction.

Recovery and investigation answer different questions

Reopening a service answers an operational question: what can customers use now? Investigation answers questions about entry, access and consequences. Progress on one track does not automatically complete the other.

The reviewed statements and reports do not supply a final root-cause report, a verified attacker identity or evidence establishing the full data-access scope. They should not be used to infer a particular ransomware family or to certify that every security question has been resolved.

A useful next disclosure would explain the remaining restrictions, any revised affected scope and the evidence supporting closure of the incident. That does not require publishing exploitable technical details. Clear status changes and an account of completed corrective work can help readers understand progress without exposing sensitive systems.

Practical lessons for service operators

Maintain a recovery checklist around user journeys: sign in, recover access, view information and complete an authorised action. Give each journey an owner and a measurable acceptance check. Communicate partial availability in the same terms customers use to describe their tasks.

Makezaa's cloud recovery analysis offers related context on checking dependencies and recovery assumptions. For this incident, the central lesson is narrower: a credible reopening notice should preserve the limits of restoration.

Tabung Haji's official contact page is the appropriate reference for assistance. The next status announcement will determine when the remaining THiJARI functions can be described as restored.

Sources and reporting dates

• RTM: report of Tabung Haji's recovery statement — October 12, 2026.
• Bernama: core-service restoration — October 12, 2026.
• FMT: detection timeline and remaining restrictions — October 12, 2026.
• Lowyat.NET: technical-news coverage with the company's social statement embedded — October 12, 2026.