Patch Fast. Think Faster.

Episode transcript

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

SPEAKER_00 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.

SPEAKER_01 0:21

Hello and welcome to What Matters in Cyber. I'm Steve. This week, the internet has given technology teams a fairly unpleasant combination: emergency software updates, compromised certificate authority keys, a ransomware warning, and a reminder that sometimes the update itself is the problem. If your patching process requires three committees and a meeting next Thursday, this might be an uncomfortable episode. Our lead story is PHP 2 Shell. Two critical vulnerabilities in technology used beneath a huge number of websites. We will separate what researchers have demonstrated from some of the more dramatic claims about the entire internet collapsing before lunch. Then, the eMudra certificate incident. That one has a particularly immediate deadline for some website operators, with a chrome trust change expected on Tuesday, October 27th. We'll look at the latest SafePay ransomware warning, a new AWS service that aims to turn vulnerability findings into proposed fixes, and the compromised Rank Math Pro update affecting some WordPress sites. Finally, a short Monday action list, and my take on why faster vulnerability discovery is only half the answer. The other half is whether your organization can actually do something about what it finds. This is the weekly roundup for Monday, October 26th, based on information available as we recorded over the weekend. Technical guidance can change, so check the current vendor advisories before making changes. Let's start with PHP2 Shell. If you are not a developer, PHP is a programming language used to run websites and web applications. You may never have installed it yourself, but your hosting provider or application supplier could be using it underneath a service you depend on. WordPress, Drupal, and many other applications use PHP. That makes a problem in the language's underlying engine more significant than a bug in one optional plugin. On October 21st, the PHP project released emergency security updates addressing two critical vulnerabilities. Researchers demonstrated ways the floors could expose sensitive information from server memory or allow an attacker without a login to execute code under the right conditions. The research involved AI assistants. Wiz described using frontier models to help develop complex exploit chains and adapt them to different applications. The important point is not that AI invented a new weakness, it helped researchers turn existing weaknesses into practical demonstrations of exploitation. There is a difference between saying a floor looks difficult to exploit and knowing that it cannot be exploited. That difference is becoming rather important. But let's be careful with the headlines. The fact that PHP is widely deployed does not mean every PHP website can be taken over with one universal request. Sansec updated its assessment after release, saying exploitation required specific knowledge and conditions, and that public demonstrations did not work against a default installation. That does not make the bugs harmless, it means exposure and exploitability are not interchangeable. For me, the useful message is urgency without theatre. Confirm where PHP is running. Check whether it is affected, get the appropriate fix deployed, and do not confuse an impressive internet percentage with a verified count of compromised websites. The PHP story also exposes a management problem. Who actually owns the response? The security team may identify the vulnerability. The web team may own the application. Infrastructure may manage the server. A hosting company may control PHP, and the business may be the only group authorized to accept downtime. Five perfectly reasonable responsibilities. Potentially one very slow decision. Updating WordPress alone does not patch a flaw inside PHP. You need confirmation that the underlying runtime has been updated, whether that happens through your operating system packages, hosting platform, or application supplier. If you run an older release, check the support position and your distributor's guidance carefully. Some suppliers provide backported fixes. That means the visible version number alone may not tell you whether a package is safe. You need the package release and the supplier's security notice. Then verify what is actually running after the change. A downloaded update is not a deployed fix, and a deployed fix is not necessarily the version every live application worker is using. What about taking a website offline? I would not turn that into a blanket recommendation. The decision depends on exposure, the service's importance, available controls, and how quickly you can patch. Follow the relevant advisory and document who makes that decision. My wider point is that you should decide the emergency process before the emergency. Know who can approve an urgent change. Know the rollback route. Know how to contact the hosting provider outside office hours. And know how to communicate a service interruption without pretending it is scheduled maintenance that everybody somehow forgot to schedule. The PHP team also brought its release forward after vulnerability identifiers began circulating publicly. That is another reminder that the time you think you have may not be the time you actually get. Next, eMudra, and a problem in the trust system behind secure web connections. A certificate authority helps your browser establish that it is talking to the right website. Its signing keys are therefore extremely sensitive. Google says private keys associated with eight e-Mudra subordinate certificate authorities were generated with insufficient randomness. In practical terms, those keys were weak enough that someone could recover them and potentially create forged certificates accepted by clients that still trusted the affected authorities. This is not the same as proving that everybody's web traffic was intercepted. It is a serious weakness in something that clients relied on to decide who to trust. Google blocked the affected keys in Chrome and coordinated protections across its ecosystem. Cloudflare also described taking action to remove trust in the compromised authorities. Here is the immediate issue for Monday listeners. Google says removal of the related MSign ECC root CAG3 from the Chrome root store is expected on Tuesday, October 27th. Legitimate websites with certificate chains depending on that route could stop working for affected clients unless the operators move to another trusted certificate hierarchy. So, check your certificate chain, not just the expiry date. Ask the team or provider managing your public certificates whether anything relies on that route, and resist the tempting workaround of telling users to bypass certificate warnings. That would be an impressively unhelpful response to a certificate trust incident. The broader lesson is that certificates are an operational dependency. Someone needs to own inventory, renewal, replacement, and emergency changes, not just the purchase order. This is also why a browser being current does not answer every enterprise question. Applications and services can maintain their own trust settings. Your technical teams need to establish which vendor updates and trust changes apply to the software you actually use. Now, ransomware. A joint advisory released this week by American and international authorities identifies SafePay as one of the most active ransomware operations of 2026, with at least 600 victims. The activity described includes compromised credentials and exploitation of known vulnerabilities, followed by data theft and encryption. That makes a useful contrast with the PHP story. Some attackers are working on complicated exploit chains. Others are still getting excellent results from weaknesses organizations already know about. Both deserve attention. A new vulnerability should not distract us from an old remote access appliance that has been waiting for a maintenance window since spring? Here is where I would focus the discussion inside a business. Can you identify every externally reachable remote access service? Do you know whether each one is patched, monitored, and protected appropriately? Are privileged accounts separate from ordinary user accounts? And would suspicious administrative activity generate an alert somebody is actually responsible for investigating? Then ask about recovery. Not do we have backups? Ask, when did we last restore an important business service? And how long did it take? Can the same administrator identity that manages production also delete the recovery copies? Are the backup management systems protected separately? Can you recover the identity infrastructure you need before recovering everything else? Those are general resilience questions, not claims that every safe pay incident follows an identical playbook. And remember that restoring encrypted systems does not undo stolen data. Recovery planning and data protection address different parts of the problem. You need both. Otherwise, you can get the systems back and still have a rather difficult conversation with customers. There is a more constructive technology story this week too. On October 22nd, AWS announced general availability of continuum for code vulnerabilities. According to AWS, the service combines source code and infrastructure context to assess which findings are exploitable, prioritize their business impact, and propose fixes through repository pull requests. It can attach evidence and reproduction steps where it validates an issue. Fixes currently require human approval. Broader automatic remediation is described as a future capability, not something we should pretend is already universally available. I like the direction. We have spent years getting better at generating findings. Many teams now have more findings than they could investigate if they cancelled every meeting until retirement. The useful next step is evidence. Can an attacker reach this? What could they access? What would fixing it change? And can we test the proposed change before deployment? However, a product announcement is not an independent performance assessment. These are AWS's claims, and customers need to test them against their own applications. I would evaluate any tool in this category on three things. Does it remove noise without overlooking real risk? Does its proposed fix survive meaningful testing? And does it reduce the time until a verified remediation reaches production? That last point matters. A pull request sitting untouched in a repository is not a closed vulnerability. Also, an AI system proposing changes needs carefully scoped permissions. Faster analysis should not automatically become unrestricted authority to modify critical applications. The goal is not to remove people from every decision. It is to give people better evidence and less repetitive work, with appropriate controls over what actually ships. This incident began before our main reporting week, but it is worth checking if you manage WordPress sites. RankMath says some copies of its Paid Pro plugin, version 3.0.123, distributed during a specific window on October 15th and 16th, contained malware. The vendor says sites that activated an affected package should be treated as compromised. The free edition, distributed through WordPress.org, was not affected by this incident. Check the vendor's exact affected window and recovery instructions. Do not assume installing a clean update removes everything an attacker may already have changed. Investigation, credential handling, and recovery need to follow the actual incident guidance. This does not mean automatic updates are generally a bad idea. It means an update channel can itself become part of a security incident. Now, your Monday priorities. First, confirm PHP exposure and remediation with the actual system owner or hosting provider. Ask for evidence, not just reassurance. Second, check whether any public certificate chains depend on the MSign route affected by Google's planned October 27th change. Third, review externally reachable access services and their patch status. Give known exploitation and business impact more weight than a list sorted only by severity score. Fourth, check the rank math notice if you use the paid plugin. And finally, pick one important service and ask somebody to show you its last successful recovery test. That is a more useful exercise than watching another dashboard turn green while everybody quietly hopes it means the same thing. And now, my take. This week's stories are not really about the number of vulnerabilities. They are about the distance between knowing something is wrong and doing something useful about it. PHP researchers demonstrated that difficult weaknesses can become practical attack paths. The certificate incident required coordinated changes to trust. Safepay reminds us that established weaknesses remain profitable. And AWS is offering technology intended to move from findings towards fixes. Different stories, the same question. How quickly can your organization turn evidence into a safe decision and a verified result? I think that is where security leadership needs to put more attention. Who owns the service? Who can approve the emergency change? What testing is enough? What happens if the fix breaks something? And who checks that the vulnerable version is no longer running? Those sound like management questions because they are. Buying better detection does not make them disappear. Neither does adding AI. If an automated system discovers problems in minutes, but your approval process still takes three weeks, you have accelerated the queue, not solved the problem. So yes, patch fast. But think faster about the decisions, ownership and recovery plans that make patching possible. Urgency does not require panic, it requires preparation. That's it for this week's What Matters in Cyber. Which part slows your response most? Finding the affected systems, getting approval, testing the fix, or arranging downtime. I'd be interested to hear your experience. Subscribe, share the episode with somebody who would find it useful, and join me again next Monday. I'm Steve. Thanks for listening.