What Matters in Cyber podcast artwork
EPISODE 3 September 28, 2026 934

The Cost of Waiting

EPISODE NOTES

About this episode

What happens when waiting becomes the biggest cybersecurity risk?

In this week’s episode of What Matters in Cyber, Steve examines the decisions organizations make when threats are developing, information is incomplete and the consequences of getting it wrong can be significant.

We look at Kiteworks’ unusual decision to recommend a precautionary shutdown following intelligence about a possible imminent attack, and why acting before a breach is confirmed may sometimes be the responsible choice.

Also in this episode:

• ShinyHunters returns with renewed attacks against Oracle PeopleSoft
• How attackers bypassed temporary firewall protections with one encoded character
• The actively exploited vulnerabilities that deserve attention this Monday
• Why aircraft communication systems remain vulnerable to interception, spoofing and jamming
• A new proposal for strengthening US telecommunications security
• Whether voluntary cybersecurity standards are enough for critical infrastructure

Steve also shares his take on the common thread connecting these stories: the cost of waiting.

What security risk is your organization currently containing, postponing or accepting that it should actually be fixing?

Subscribe to What Matters in Cyber and join the conversation.

Send us Fan Mail

TRANSCRIPT

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

Opening Announcer

SPEAKER_01 0:01

Each week we break down the biggest cybersecurity stories: emerging threats, new technologies, and the changes that matter to you. What happened, why it matters, and what to do next. This is What Matters in Cyber with your host Steve.

This Week in Cyber

SPEAKER_00 0:23

Hi, I'm Steve, and welcome to What Matters in Cyber. It's Monday, September 28th, and this is your weekly look at the cybersecurity stories worth paying attention to. This week, we're talking about an unusual warning that led organizations to deliberately shut down critical systems, attackers finding an almost embarrassingly simple way around security controls, vulnerabilities that need attention right now, and some worrying findings about the technology used to communicate with aircraft. We'll also look at a new proposal for improving the security of America's telecommunications networks and ask whether voluntary standards are really enough. There's a common theme running through these stories. It's the cost of waiting, waiting for confirmation before acting, waiting to install the real patch, waiting to modernize old infrastructure, and sometimes waiting for somebody else to decide what an acceptable level of security should be. Let's begin with

Kiteworks and the Decision to Shut Down

SPEAKER_00 1:19

Kiteworks. Kiteworks provides secure file transfer and data exchange systems. These are used by organizations in healthcare, government, education, technology, and other sectors to move sensitive information. On Friday, Kiteworks warned customers that it had received credible intelligence suggesting a threat actor might attempt to target some customer systems. The warning was unusual because there was no confirmed breach. Kiteworks said it was not aware of any compromise of its systems. Nevertheless, it advised customers to temporarily shut down affected servers over the weekend while the company worked with law enforcement. The concern appeared to be that attackers might possess information about a previously unknown vulnerability, in other words, a possible zero day. Kitework said that all known vulnerabilities had been addressed in its latest release, version 9.5.1. But when you are dealing with a potentially unknown vulnerability, installing every available patch does not necessarily remove the risk. For customers, particularly those in healthcare, taking systems offline was not a trivial decision. One healthcare customer told TechCrunch that the shutdown caused delays and affected doctors' ability to contact patients. That illustrates the uncomfortable reality of operational cybersecurity. Shutting down a system has consequences. Leaving it running may have even greater consequences. My initial reaction is that Kiteworks made the responsible call. If credible intelligence indicates that an attack may be imminent, waiting for someone to become the first confirmed victim is not necessarily good risk management. We often criticize organizations for failing to act on warnings. We should therefore be careful about criticizing one for acting, before it has absolute proof. But precaution must be followed by transparency. Customers will need to know what the threat was, whether any exploitation was discovered, what kite works learned during the shutdown window, and what protections should remain in place. The lesson for the rest of us is not that every unconfirmed threat requires shutting down production. The lesson is that organizations should know who has the authority to make that decision. If one of your critical technology suppliers called a day and recommended taking its platform offline, who would make the final decision? How quickly could it happen? What services would be affected? And what alternatives would the business have? A second

ShinyHunters Returns to Oracle PeopleSoft

SPEAKER_00 3:52

story provides an example of what can happen when organizations use a temporary defence as though it were a permanent fix. Google's Mandi Team has reported renewed mass exploitation of an Oracle PeopleSoft vulnerability by a group it tracks as U, NC6240, commonly associated with Shiny Hunters. PeopleSoft is used by many large organizations to manage functions such as human resources, payroll, finance, and student records. The vulnerability was originally exploited as a zero day earlier this year, particularly against universities. Oracle released an emergency security update in June. For organizations that could not immediately install the update, one temporary defense was to use web application firewall rules to block requests to the vulnerable component. The attackers have now adapted. They discovered that by encoding a single character in the requested web address, they could bypass some of those firewall rules. The security control looked for one exact piece of text. The application translated the encoded character and still processed the request. That tiny change allowed the attackers to reach systems that their operators may have believed were protected. Mandiant says web shells were installed on dozens of systems around the world. The targeting has expanded beyond education into healthcare, technology, government, transportation, agriculture, and IT services. Once inside, the attackers could gain access to application data, configuration files, and credentials. In some cases, commands reportedly ran with the highest level of system privileges. This is where the story becomes bigger than one vulnerability. A web application firewall can be valuable, but it is usually a compensating control. It reduces exposure while the underlying problem is fixed. It is not the same as removing the vulnerability. My take is that temporary security measures have a habit of becoming permanent through inertia. A firewall rule is installed. The immediate alert disappears and everyone moves on to the next priority, but the vulnerable code is still there, and the attacker only needs to find a variation the rule does not recognize. If your organization uses PeopleSoft, the recommendation is straightforward. Install Oracle's security update for CVE-2026-35273. Do not rely solely on path-based firewall rules. Organizations should also look for encoded variations of the vulnerable path, unexpected JSP files, web shells, unfamiliar remote management software, and unusual data transfers. And if evidence of a web shell is found, do not assume that deleting the file ends the incident. Treat the server as compromised, preserve evidence, and rotate any credentials that the PeopleSoft service could access. The real lesson is simple: containment buys time. Remediation removes the problem. Do not confuse the two. Let's

Monday Morning Patch List

SPEAKER_00 7:02

move to a quick Monday morning patch list. CISA added four more actively exploited vulnerabilities to its known exploited vulnerabilities catalog. The two most urgent involve WSO2 products and Adobe Commerce, including Magento. The WSO2 vulnerability can allow an attacker to bypass authentication and potentially compromise administrative accounts. WSO2 technology is used in API management environments, including within banking, government, telecommunications, and logistics. The Adobe Commerce vulnerability is an authorization issue that researchers say can be exploited without an existing account, administrator access, or user interaction. CISA also warned about actively exploited vulnerabilities affecting Microsoft SharePoint and MicroTix Ruder OS. I am deliberately not turning this into CVE bingo. Most listeners do not need four strings of numbers read aloud to them. What matters is whether your organization operates these products, whether they are accessible from the internet, and whether the appropriate teams have confirmed remediation. If you use WSO2, Adobe Commerce, Magento, SharePoint, or MicroTick Router OS, put confirmation on the agenda this morning, do not ask, do we normally patch those systems? Ask, have these specific vulnerabilities been addressed, and how do we know? That last part matters. A ticket marked complete is administrative evidence. A version check, configuration validation, or vulnerability scan is technical evidence. Whenever possible, get both. Our

The Cybersecurity of Aircraft Communications

SPEAKER_00 8:50

next story moves from enterprise software to aviation. A new report from the Government Accountability Office found that important aircraft communication systems remain vulnerable to interception, spoofing, jamming, and denial of service attacks. Two of the systems discussed in the report are our cars and CPDLC. Without getting too deep into aviation terminology, these systems allow pilots, airlines, and air traffic controllers to exchange text-based operational messages. The problem is that parts of this technology were designed before modern cybersecurity protections became standard. According to the GAO, these communications can lack strong authentication and encryption. The FAA also lacks comprehensive real-time monitoring for some spectrum-related threats. That means a malicious actor could potentially intercept messages, transmit fraudulent messages that appear legitimate, or interfere with communications. There are important technical and procedural barriers to successfully deceiving a pilot or air traffic controller. So, this is not a reason to panic the next time you board an aircraft, but it is a serious infrastructure issue. The report also arrived during the same week that thousands of flights in the northeastern United States were delayed or cancelled following an FAA telecommunications failure. To be clear, that outage was not reported as a cyber attack. A primary communication path failed, and a backup fiber line had been accidentally severed during construction work. But the timing demonstrates something important. Cybersecurity and operational resilience cannot be separated. Whether a service fails because of ransomware, radio interference, a software defect, or a construction crew cutting a cable, the passenger experiences the same initial result. The system is unavailable. My take is that we sometimes define cybersecurity too narrowly. We focus on malware and unauthorized access, while forgetting that resilience, redundancy, authentication, and the ability to detect interference are also security issues. The GAO made nine recommendations, including formal risk assessments, continuous monitoring and stronger authentication, and data protection for aircraft communications. The Department of Transportation agreed with all nine. The question now is not whether everyone agrees there is a problem. It is how quickly a complex safety-critical ecosystem can actually fix it. Finally,

Are Voluntary Telecom Standards Enough?

SPEAKER_00 11:32

Senators Mark Warner and Ted Cruz have introduced the Telecommunications Cybersecurity and Resilience Act. The proposal follows the Salt Typhoon campaign, which compromised major telecommunications providers and gave Chinese-linked attackers extensive access to communications networks. The bill would create a working group within the National Telecommunications and Information Administration. Telecommunications companies, suppliers, government agencies, and security experts would work together to develop industry-specific cybersecurity practices. Those practices would be voluntary. The legislation would also establish an optional certification program using independent assessors. The standards would be developed within 18 months and reviewed every two years, or following a major incident. There is quite a lot to like in the proposal. Telecommunications networks are complex. Government and industry need to work together. Security requirements must evolve as technology and threats change. An independent certification process could also give customers, boards, and regulators more meaningful information than another internal declaration that security is taken seriously. But voluntary standards have an obvious limitation. The organizations most willing to participate may already be investing in cybersecurity. The companies that most need improvement may decide that participation is too expensive, too disruptive, or simply unnecessary. My view is that critical infrastructure needs an enforceable minimum security baseline. That does not mean government should prescribe every product, firewall rule, or technical configuration. Overly specific regulations can become obsolete, but there should be clear outcomes around identity security, network visibility, incident reporting, supplier risk, secure administration, and recovery capabilities. Organizations should have flexibility in how they meet those outcomes, but not whether they meet them. Salt Typhoon was not a theoretical exercise. It demonstrated how deeply an adversary could penetrate systems that underpin everyday communications. Voluntary collaboration is a good start. For infrastructure this important, I do not believe it should be the finish line.

My Take: The Cost of Waiting

SPEAKER_00 13:50

So, what matters in cyber this week? For me, it comes down to the cost of waiting. Kiteworks decided that the potential cost of an attack justified temporary disruption, even without a confirmed breach. Some PeopleSoft operators appear to have relied on a temporary firewall rule rather than removing the underlying vulnerability. The attack has adapted. Aviation communication risks have been understood for some time, but important assessments and monitoring capabilities are still incomplete. And nearly two years after Salt Typhoon became public, we are still debating whether essential telecommunication security should be voluntary. Not every cyber warning requires an emergency shutdown. Not every security control needs to be mandated by government. But when the possible impact is severe, waiting for absolute certainty can become a decision in itself. This week, I would encourage you to ask one question inside your own organization. What security risk are we currently containing? Postponing or accepting that we should actually be fixing? If you have a view on any of today's stories, especially the kite work shutdown or voluntary telecom standards, I would like to hear it. Cybersecurity improves when we move beyond headlines and talk honestly about.