There was some concern raised a few years ago about denial of service attacks with GSM-R. In ETCS2, where the radio system is used to issue and maintain movement authorities for the on-board ATP functionality, that could result in train equipment becoming swamped and being unable to process the legitimate messages from the trackside properly. The on-board systems would fail safely in that scenario, cutting traction and applying brakes to stop trains that had lost communications, so such an attack could result in widespread disruption, and there is a safety concern there if during such an occurance train movements were then made under verbal authority, which is always riskier than running under the full protection of the signalling.
Spoofing movement authority messages continuously to fool a particular train into taking a dangerous course of action would be extraordinarily difficult with all the continuously varying positional data and the encryption provided. The system has been designed and certified to SIL4, the highest safety integrity level under European regulations and such risks are definitely analysed as part of this process.
Perhaps the riskiest area remaining is the fixed data about the railway infastructure itself and how that is stored and updated. In order to calculate its safe speed at any time, a train computer needs a detailed digital map of the infrastructure ahead in addition to an accurate positional fix and a valid recently refreshed movement authority. The static data about the railway (speed restrictions, gradients, electrification etc) can be obtained from an on-board database covering a wide area (as used for the legacy GW pilot scheme ATP), or alternatively in ETCS more local chunks of track characteristic data might be encoded in the passive balises along the route, otherwise used for positional updates in conjunction with odometry. Either system has its challenges. For the wide area database carried on board, the latest map including temporary and emergency speed restrictions etc must be distributed and updated to all traction units before they go into service, perhaps using removable media (!). In the case of balises, the data in those specific transponders must be updated locally. Unless managed properly there is a danger that a mis-typed emergency speed restriction entry in a daily data update or a missed balise update, whether carried out malicious or not, could result in a train not being given sufficient advanced warning of an upcoming restriction. This, to some extent, mirrors the risk of TSR and ESR advance warning boards and their AWS inductors being positioned incorrectly or not at all today.
Rest assured that computer based failsafe (SIL4) interlockings such as SSI and its successors continue to act as the 'safety brokers' in ETCS based installations for route settting, junction conflict and point movement, just as they do today in traditional color light areas. Their operation is governed by a fixed generic programme and bespoke local geographic configuration data constructs encoding the track layout and permitted routes. Neither programme nor geograhical data can be changed remotely during normal operations via ANY means, and the initial commissioning of a site is governed by many many stages of independant checking, testing and audit. Whilst some quite serious mistakes have occurred depite all this, the risk of a deliberate malicious act slipping through is in reality vanishingly small.