Attack on Yandex Briefly Takes Down eXpress Messenger and Website; On-Premise Customers Unaffected

An attack on Yandex on October 12, 2026 briefly took down the corporate messenger eXpress and its website, TAdviser reports. The developer, Unlimited Production, stresses that the incident did not affect corporate customers, because their versions of eXpress run on the customers' own infrastructure.

The hit landed on the public part of the product. For the market of secure Russian messengers, this is a telling situation: the same product behaves differently depending on where it is deployed.

What is known about the incident

The available excerpt of the source material gives no technical details. It is unclear what kind of attack it was, how long the downtime lasted, or which Yandex components were affected. The TAdviser headline implies that the eXpress service and website depended on the infrastructure that was hit. There is nothing more to relay: any theories about the type or source of the attack remain guesswork.

The verified facts at this point are as follows:

• date of the incident: October 12, 2026;
• the corporate messenger eXpress and its website were affected, and the unavailability was temporary;
• according to Unlimited Production, corporate customers were not affected;
• the reason customers held up: their installations run on their own infrastructure;
• users of eXpress and of solutions built on it include Russian Railways (RZD) and Rosatom.

Why on-premise held up

The logic is simple. If a messenger sits inside the customer's perimeter, it does not matter what happens at a third-party provider. The servers, databases and communication channels belong to the customer, and availability is determined by its own IT department. An outage at an external cloud becomes a problem for the vendor and its public service, not for a large organization with a closed deployment.

This comes at a price. The customer is responsible for updates, redundancy, monitoring and protection against attacks. But for organizations such as RZD or Rosatom, that trade-off has long been familiar: critical communications are kept inside the perimeter.

The market and competitors

Rosatom itself, however, is taking a different path. Greenatom, the state corporation's IT company, told TAdviser that the nuclear industry has adopted the corporate messenger Atom Space. The rest of that quote is cut off in the available excerpt, so details about the developer and the scale of the rollout are not given here. The fact itself is what matters: even within one large group of companies, several solutions coexist, and eXpress is not the only option.

Practical takeaways for IT leaders

The incident is worth studying as a case in architecture. Here are a few questions to ask yourself and your vendor:

• Where are the messenger's servers physically located, and what happens to it when an external provider is unavailable?
• Does the service have a backup channel for notifying employees if the primary one is down?
• Do key functions, such as authentication, push notifications and updates, depend on the vendor's public cloud components?
• How often is the scenario of operating without access to external infrastructure tested?

For companies that use the cloud version of any corporate messenger, the lesson is harsher: a provider's SLA is no substitute for your own action plan. Even a downtime of a few hours hits approvals, on-call shifts and operational communications. For those choosing between the cloud and an installation of their own, this case becomes one more argument for the latter, if continuity requirements are high.

The full picture will emerge when Yandex or Unlimited Production disclose details of the attack and the length of the downtime. For now, one thing is confirmed: the closed perimeter worked as expected.