SEC536: Adversarial AI - Penetration Testing AI Systems


Experience SANS training through course previews.
Learn MoreLet us help.
Contact usBecome a member for instant access to our free resources.
Sign UpWe're here to help.
Contact UsThe articles in this issue of NewsBites reflect a historic and bruising week in cybersecurity. Trends in AI-accelerated vulnerability discovery came to a head with Wednesday’s PHP emergency, while serious flaws and supply-chain attacks kept coming, and agentic cyberattacks are already underway. We’re all feeling it. Defenders are working around the clock. Rumors are flying, and mainstream journalists, neighbors, friends, and family members are asking what’s happening and whether they should worry. Seasoned professionals are exhausted and wondering whether this pace is the new normal. We must face these threats with clear eyes, without giving in to fear, uncertainty, and doubt.
Yet there is real reason for hope. Cybersecurity has weathered daunting challenges before because smart, committed people found ways through them together. Now those same human strengths, amplified by AI, are helping defenders protect people they’ll never meet. The thoughtful, practical commentary from our NewsBites editors throughout this issue is a reminder of just how much expertise and dedication this community brings to the fight. To boards and executive leaders: This is the time to listen to your security teams, strengthen the fundamentals, and give defenders the staffing, funding, tools, and authority to succeed, along with room to recover. Heroic effort cannot be our permanent operating model. To everyone on the front lines: THANK YOU. Your work matters. Support one another, share what you learn, and keep making the world safer and more secure. As SANS CEO James Lyne often reminds us: When attackers and defenders are both armed with AI, always bet on the ingenuity of skilled human defenders and the tools they wield.
For additional thoughtful commentary and analysis from James Lyne and Ciaran Martin wrapping up this noteworthy week, please listen to the latest episode of their Cyber Leaders Podcast, which will be published soon: https://www.sans.org/podcasts/cyber-leaders/a-patch-it-properly-week-hosts-special-39
—Ed Skoudis.
SANS NewsBites Editor
President, SANS Technology Institute
At 14:00 UTC on Wednesday, October 21, the PHP Foundation publicly released fixes for two vulnerabilities that allow unauthenticated remote code execution (RCE) in all versions of PHP, together dubbed "PHP2Shell." Both flaws carry CVSS score 9.2 and are known to be under attempted exploitation in the wild. CVE-2026-109618 allows RCE through out-of-memory corruption: An attacker can time a request to reach PHP's memory_limit such that "PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory." CVE-2026-109619 allows RCE via stale global state: watchTowr explains, "[The flaw] comes from internal state that outlives the request memory it points to, so the next request that the same PHP worker picks up can act on that leftover data."
Wiz estimates that PHP is present in 70% of all websites in the world, including prominent use in WordPress, Drupal, Joomla, and Magento. Ahead of the patch release, many organizations worldwide preemptively took sites and services offline to reduce risk of exploitation, including government sites in the UK, Germany, France, Belgium, Finland, the Netherlands, and Australia. At the time of this writing, the PHP foundation is not aware of any successful exploitation, but Amazon Threat Intelligence observed exploitation attempts against its honeypots as early as October 17, and Cloudflare has observed significant attack traffic attempting to target its customers before and after the public announcement.
Fixing these flaws has been "the top priority" for the PHP Foundation security team since their discovery in August with the help of Calif, Wiz, and OpenAI. However, leaked CVEs and release speculation began to circulate online on October 20, forcing an official release announcement about 18 hours before the patches would ultimately become available; the release itself also had to be shifted a day earlier than planned. A Calif video showing a proof-of-concept exploit and limited technical details was leaked around the same time. The PHP Foundation notes that at 07:41 UTC on October 21, about six hours before release, "Chainguard unilaterally broke the embargo and published built images containing the fix."
Users of any PHP installation serving web requests should update immediately to PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Minimal source backports for PHP 7.4, 8.0, and 8.1 are available due to the severity of the flaws, but versions 8.1 and older are unsupported, and users should look to upgrade. If immediate updating is not possible, users should follow temporary mitigation instructions in the advisory, which "reduce exposure to specific attack paths but do not make an installation safe." SANS instructors Rich Greene and Moses Frost hosted an emergency livestream discussing these vulnerabilities on October 21.

Like many of you, I've lived through weeks like this one, both as the person patching at 2 AM and as the person getting asked every hour whether we're "exposed." So, let me separate the multiple things that are getting blended together in the chaos of this week.
Pre-auth RCE in something that runs almost everywhere justifies an emergency change, full stop. It also justifies taking systems offline if you can't patch them quickly, because the only real fix is to patch. It's not worth taking chances on hardening or mitigations you think might work. We're often tempted by a less disruptive mitigation, but disabling session.upload_progress blocks only one path for one of the two CVEs. I rarely advise something quite so drastic, so when I do it should be taken seriously.
The panic and media hype is something else entirely. As I draft this, attempts are everywhere (Cloudflare counts millions), but there is no publicly confirmed successful compromise or victim, and neither CVE is in CISA KEV. Much of the PoC code circulating doesn't actually achieve RCE. That isn't a reason to slow down, but it is a small blessing and a reason to stop doomscrolling and get to work. I think we’ll need to do a retrospective on the good and bad of media hype during big vulns soon
So, skipping the FUD, here's what to focus on practically:
Start with what's internet-facing. Then go find the PHP you inherited, not just the PHP you know about: firewall and appliance management interfaces (PAN-OS and Panorama fixes are still pending), vendor products, stale container images.
Patch what you own, restrict access to what you can't, and get vendor dates in writing. Attempts started October 17, so scope any hunting from that date, not from the disclosure date.
Leaders, this part is for you. Your job today is to absorb the noise, not make more of it. Stop asking for hourly status updates. Make risk calls in writing so your team isn't guessing. Tell them out loud what's allowed to slip, and send people home in shifts. A team that burns out on Friday can't respond to the next one, and there will be a next one. At the rate we're going, it may be just a few weeks away, and that will keep happening until AI analysis of all these ancient codebases clears the vulnerability backlog (a little).
The embargo drama (who leaked, who broke it early, who gets credit) is a good conversation about how coordinated disclosure holds up when AI is speeding up discovery. I ask you, please, as an industry, can we have that conversation once we've all slept and recovered a bit?

I have noticed a common misconception in how broadly used PHP is. Many reports online treat PHP as if it is only used for websites. This is understandable, as nearly 70% of all public websites run on PHP, and I believe that these publicly accessible sites should be the focus for the first wave of emergency patching. However, PHP was the dominant language for building anything web-based in the 2000s, and many of the devices originally designed and built in this decade that had a web-based configuration UI are likely still using PHP today.
Some examples include D-Link routers; dozens of Cisco products shipped as virtual appliances; file transfer software; captive Wi-Fi portals used in coffee shops, airports, airplanes, and universities; on-prem webmail like Roundcube; IT monitoring tools like Cacti, Nagios, and Snipe-IT; hosting panels like phpMyAdmin, Plesk, WHMCS; even hobby projects like Pi-Hole.
A significant number of free/open source business platforms use PHP as well. Electronic medical records systems like OpenEMR; VoIP tools like FreePBX and other Asterisx distros; software used in education, like Moodle; customer management software like SugarCRM, SuiteCRM, vTiger.
I predict we will see a long, long tail of vulnerable systems running PHP that won't get identified and could be convenient to ransomware crews years from now. In fact, the last critical RCE discovered in PHP, CVE-2024-4577, is still regularly used by malware and cybercriminals, though it was published over two years ago.

The PHP2Shell results are extremely mixed. There is a lot of misleading information and misleading exploits. Some individuals are claiming full exploitation in specific scenarios, but new, novel, unrelated bugs may also have surfaced. This morning's post-patch guidance is still to turn off PHP's session_upload_progress feature. We have no concrete evidence of full exploitation yet; however, when exploits do happen, we also have limited telemetry and rely on post-compromise evidence such as defacement or shell access. Now is the time to enable more telemetry and logging if you are running PHP, or any application language for that matter.

We were having a conversation asking who knew what PHP stood for. Initially it was Personal Home Page, but rapidly became PHP Hypertext Preprocessor, and then we recalled it seemed like every couple of years someone had a new technology which would replace PHP. To be honest, it's here for the duration; we need to keep it updated. The hard part is that you need to get to PHP 8.2.35 or higher. If you've still got PHP 7 environments, you're going to have to bite the bullet and update or disable components (or plugins in your CMS) which aren't compatible, so you can get to a supported version of PHP. The good news is that the php.net site has compiled packages for most Linux distributions, including Docker, as well as Windows and macOS binaries, in case your current update process doesn't offer the fixed packages. Your service providers should be alerting you to their plans for deploying updated packages. If you've not heard from them, ask. Don't panic — use your system inventory and methodically make sure everything is covered. Don't overlook systems which simply have PHP installed. Lastly, while there are currently no IoCs to hunt for, you need to monitor for PHP spawning shells, interpreters, or download tools — your EDR is a partner here, so leverage it. Breathe, finish your coffee; your team should be telling you they've got this.

Incidents like PHP2Shell create a difficult choice for critical infrastructure operators. Applying an emergency patch without adequate testing can disrupt essential services, while waiting for normal maintenance windows leaves vulnerable systems exposed. The ability to patch quickly and safely depends on engineering decisions made long before the vulnerability is discovered, including system redundancy, representative test environments, rollback procedures, and the ability to isolate vulnerable components. An organization's patching capability is ultimately a measure of how well its systems were designed to accommodate change without disrupting operations.
Given the widespread use of this scripting language, malicious actors are likely analyzing the newly released patch to develop exploits. It is now a race against the clock to apply updates before attackers reverse-engineer the patch and target vulnerable systems. If you are running older versions of PHP, upgrade immediately or take your website offline until you can do so safely.

I cannot recall ever receiving warnings about a vulnerability from so many sources. We cannot say we were not warned. However, PHP is so pervasive that the presence of the vulnerabilities will be persistent.
PHP
PHP Foundation
YouTube
SANS ISC
Wiz
WatchTowr
NCSC
KrebsOnSecurity
Help Net Security
BleepingComputer
The Hacker News
SecurityWeek
The Register
The Guardian
WIRED
On October 21, GitLab issued an emergency patch release addressing 12 flaws in GitLab Community Edition (CE) and Enterprise Edition (EE), including one maximum-severity vulnerability; this is separate from the maximum-severity flaw addressed in the October 12 release (described in NewsBites 28.76). CVE-2026-110264, CVSS score 10.0, allows an unauthenticated attacker to execute arbitrary code on a self-managed GitLab server by exploiting an integer overflow that occurs when Onigmo is compiling a specially crafted regular expression. GitLab.com has been fixed, but every version of self-managed GitLab CE/EE since 7.0 is affected by this vulnerability; GitLab has released fixes in versions 19.5.1, 19.4.3, and 19.3.6 and has also backported fixes to versions that would not ordinarily still receive updates: 19.2.9, 19.1.9, 19.0.10, and 18.11.13. This flaw was reported by "joaxcar" through GitLab's HackerOne bug bounty program. The two high-severity flaws in the same advisory are an LDAP injection vulnerability allowing LDAP-backed account takeover (CVE-2026-15723, CVSS score 8.2), and HTTP request/response smuggling issue allowing redirection of "certain flows" to an externally controlled server (CVE-2026-112212, CVSS score 7.5). Users should upgrade to the latest version of GitLab CE/EE as soon as possible.

With all the news of PHP2Shell this week, many other bugs surfaced; this is highly critical to understand. GitLab (CE and Enterprise) announced a full remote code execution vulnerability that was pre-authentication. The vulnerability could impact companies that expose GitLab externally but also internally. This might be more impactful than PHP2Shell, since full weaponization is out there.

We just talked about CVSS 10.0 flaws in GitLab CE/EE back in NewsBites Volume 28, Number 76. Yes, this the same product, but no, it's a different flaw/update. There are a number of issues here — integer overflow, improper authentication, cache poising, improper access control, internal credential exposure, authorization bypass, and more — so this needs immediate attention. The flaws go back to version 7.0 of GitLab; don't mess around with which interim version to move to. Get yourself to 19.5.1 or later. Then ask: Are you really sure you don't want to use the hosted version?

That's two CVSS 10s in self-managed GitLab in one month. If you host it yourself, you've signed up for a rapid patch cadence whether you intended to or not. Modify your processes accordingly. GitLab holds your source code and your CI secrets, so RCE there is a supply chain foothold, not just a compromised server. Treat it as tier zero, staff it like tier zero, or take Lee's suggestion and seriously consider the hosted version.
GitLab
The Hacker News
BleepingComputer
The Register
India's largest licensed digital certifying authority, eMudhra, has announced that it will voluntarily exit the global SSL/TLS certificate business following the discovery that the company had issued eight intermediate certificate authority (CA) certificates whose P384 private key numbers were found to be one byte or less in size. On October 17, a researcher reported to eMudhra and major root programs that the certificates had been compromised, attesting this by using the private keys to sign the message, "We have a problem here - Wayne." Six of the certificates are TLS issuing CAs, and two are code-signing CAs, so a malicious compromise of these certificates could allow an attacker to impersonate legitimate websites and code. Firefox and Chrome blocked the certificates on the same day, and Apple and Microsoft did so within three days; eMudhra revoked the certificates on October 18, and cross-signer Sectigo completed revocation a day later. Dennis Jackson, a cryptography engineer at Mozilla, writes that "the 8 impacted keys originate on the 30th April 2025 as part of a batch of 24 intermediates. [...] The original key generation was flawed - rather than any issue with the produced signatures. [...] The private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys." One of the keys was the number '4'. Before announcing their departure from SSL/TLS, eMudhra stated that during the Key Generation Ceremony (KGC), "a flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. eMudhra is working to establish the root cause." A compromised emSign certificate from eMudhra has been removed from several Python packages including pip, and Seth Larson, Security Developer-in-Residence at the Python Software Foundation, urges Python users to update the specific affected packages immediately to fixed versions “and rebuild container images with layer caching disabled to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org.” For further action, Dennis Jackson directs trust store operators to Mozilla's dev-security-policy forum, and urges users to update their browsers and operating systems to the latest versions as soon as possible.

Browsers and the big operating systems blocked these within days, so the risk that lasts is in trust stores that don't update themselves: the CA bundles baked into container images, appliances, Java keystores, and the Python packages Seth Larson flagged. Find where your environment ships its own copy of "trusted" and refresh it. If you run internal PKI, take the bigger lesson too. A key ceremony proves the process happened, not that the output is any good, so test what you generate before anyone trusts it.

If you're setting up a certificate authority of any scope, the details matter. Verify that the choices made are consistent with best practices. Have a third party check your work well before any formal rollout or key signing ceremonies. And then, when you have it "right," verify you really want to be in that business; your CSP likely has a service which will be lower overhead. HSMs can be a pain in the rear, and the rigor needed to maintain the integrity of a CA is significant. For the rest of us, make sure that you're updating your Python and other ca-certificate bundles which may have included the eMudhra keys. Microsoft, Apple, Firefox and Chrome/Chromium already block these certificates, so this fix is manageable.

It is worth mentioning that eMudhra was forced to shut down their certificate business over this incident. There are less than 100 CAs in the world, and trust is truly their business. As we saw with DigiNotar years ago, you can't make serious security mistakes and survive as a root of trust for a foundational Internet security function.
Dennis Jackson
Bugzilla
eMudhra
eMudhra
Python
Scott Helme
The Register
Help Net Security
The Hacker News
Ars Technica
BleepingComputer
500 eligible utilities in North America will have the opportunity to seek free cybersecurity support in the first phase of the Community Cyber Resilience Foundation, a program launched on October 20, 2026 by Dragos, Accenture, and the SANS Institute. Citing the prevalence of recent cyberattacks on critical infrastructure, the foundation aims to offer five main types of free assistance to build resilience in utilities that lack adequate resources: 1. Access to the Dragos Platform; 2. Support from Accenture in deploying, configuring and integrating the platform; 3. ICS/OT security training and certification through SANS; 4. Funding for the hardware needed to run the Platform; and 5. Access to a community information sharing network. The foundation builds on the existing Community Defense Program operated by Dragos, which has previously helped a Massachusetts water and electric utility secure its systems after a nation-state intrusion, and has helped a three-person staff at the water and wastewater utility for Juneau, Alaska to raise critical system uptime from about 85% to 99.9% and improve visibility for about 50 remote nodes. Dragos's original program works with over 100 utilities, and the first phase of the Community Cyber Resilience Foundation will be open to another 500. Water, wastewater, electric, and natural gas utilities in the US or Canada qualify for the program if their annual revenue is less than US$100 million (CA$140 million); this threshold describes about 97% of utilities in the US, amounting to more than 50,000 organizations, according to the foundation.

This initiative recognizes that small utilities need more than cybersecurity guidance and threat intelligence. Providing the technology, engineering assistance, hardware, and training together is particularly important for organizations that lack dedicated cybersecurity staff. Partnering with sector ISACs (Electricity, Water, Multi-State, etc.) is important as they have established relationships with thousands of utilities and could help identify those most in need, coordinate assistance, and share lessons learned across the sectors. The opportunity extends beyond protecting the first 500 participants. Information gained from these deployments could help identify common vulnerabilities and improve cybersecurity practices at thousands of other utilities facing similar challenges.

If you're a small utility, this is for you. The way it works is you go to the Community Cyber Resilience Foundation website and join the interest list, and they will then notify you when program enrollment opens in your area — no spam, no newsletters — once you enroll, they confirm eligibility, and you get deployed and trained. You've got nothing to lose, and these are top-tier solutions offered for free.

I've worked security at a smaller critical infrastructure org where I was one of two people with "security" in my title. Free tools came across our desk regularly, and what we never had was the hours or skills to deploy them, tune them, and act on what they found. This program gets further than most because it covers deployment, hardware, and training, with no time limit. The question I'd want answered is who watches it on day 400. Visibility into problems that you lack the people or the change windows to fix is a hard place to be. If you run a small utility, apply, but plan to invest in the staffing before the hardware arrives: Who triages alerts, who owns remediation, and what happens if the person you train gets a better offer? The success metric is how many are still running and acting on what they find three years from now.
Hats off to the newly launched foundation! Scaling up and maintaining momentum after this initial rollout will certainly be a challenge, but it’s a strong step forward. Here’s hoping Congress steps up next to secure long-term funding for the non-profits backing our critical infrastructure.

The problem is not so much that the utilities do not know what to do as one of priorities. Utilities tend to prioritize their ability to operate controls over fear of misuse of those controls by others. The availability of resources may have limited impact.

This is great news from SANS and Dragos. If you are a utility in a small area, or at all, this is a great way to measure your system's safety and security.
SecurityWeek
The Record
Community Cyber Resilience Foundation
Dragos
Accenture
SANS
A malicious version of LiteLLM (1.107.0) containing an infostealer and remote access trojan (RAT) was distributed in PyPI wheels and Docker images on Wednesday, October 21, after the software's release pipeline was compromised. The malicious version was live in PyPI from 11:39 UTC to 13:23 UTC and in Docker from 11:46 UTC to 14:20 UTC; PyPI has now quarantined the package, and Docker has removed the affected images. The private enterprise release of LiteLLM was not affected by this compromise. LiteLLM notes that "the official v1.107.0 source tag in GitHub does not contain the malicious files. The compromised artifacts were built from an attacker-controlled repository." LiteLLM believes the attacker had access to three sets of developer GitHub CLI credentials, one of which could run GitHub workflows, and took advantage of temporary release permission changes to disable branch protections and force push the malicious package, using a lookalike repository to sign the poisoned artifacts when running the workflow. Users should assume credentials are compromised if they ran pip install on LiteLLM v1.107.0, used an unpinned version of LiteLLM, or used an affected Docker image during the attack time frames. The advisory provides instructions for checking indicators of compromise and for cleaning the affected environment, which include pinning version 1.106.2.

Read the advisory carefully to determine if you're impacted. Your threat hunters should be able to run that down for you. If you're affected, follow the cleanup instructions, and don't just use pip install — you've gotta cleanup first, which includes killing running processes. If you're dependent on LiteLLM, investigate moving to the enterprise distribution.

LiteLLM had a compromise with their platform where keys were being stolen through a supply chain attack. If you're a LiteLLM customer, this is a boon for attackers who will use your credits for “free” AI usage. Your tenant could be helping attackers attack you or others. Rotate your keys, consider them compromised, and patch (obviously). When you do, follow their guidance to protect yourself properly. Enterprise customers appear to be fine, but many enterprises are running the open-source product, specifically in dev environments.

This is LiteLLM's second supply chain compromise this year, and it won't be the last attack on AI tooling. An AI gateway is a lovely target because it concentrates every model provider key you have in one place. If you ran an unpinned version during that window, you installed the malware automatically. Pin your dependencies (you should be doing this anyway — why aren’t you?), rotate the keys, and treat your AI gateway like the credential vault it actually is.

Reuse of code is essential to the efficient use of computers. However, developers are responsible for the quality of all the code that they use, without regard to source.
LiteLLM
The Register
Help Net Security
The Hacker News
BleepingComputer
In a social media post, Octave Klaba, the CEO of French cloud provider OVHcloud, urged users to quickly update to the latest version of OVHcloud CLI or else remove it entirely, because existing versions 0.11.0 through 0.15.0 had been compromised and contained secret-stealing malware. The attacker used a GitHub account belonging to a developer and was able to directly modify existing releases without checks from the CI/CD because a "release immutability" option was disabled; the feature has since been enabled. The malicious releases were live between 12:47 and 14:21 UTC on October 19. Klaba credits a customer with noticing the problem and reporting it to OVHcloud, and states that CI/CD pipelines, unit tests, functional tests, and CVE detection were not compromised. Researchers at OpenSourceMalware note that a Solana wallet mentioned in the malware also appears on lists of indicators for the threat actors behind the GlassWorm malware. Klaba recommends that affected users change all secrets stored on the disk, and says that OVHcloud CLI versions 0.10.0 and 0.16.0 are both safe to use.

What's worse than a compromised AI Proxy system? How about your entire cloud infrastructure CLI tools being compromised for multiple releases? If you are in Europe, you might be an OVHCloud customer, and if you are, upgrade immediately to the latest version. Backdoor versions of OVHCloud’s CLI tool could have given attackers access to your tenant.

This is yet another story of stolen repository credentials being used to release a compromised package. We really need to double down on phishing-resistant credentials for our code repositories. If you're using OVHcloud, follow the remediation guidance, including replacing the package and any secrets stored on disk, then look for IoCs, particularly the ones associated with GlassWorm.
A textbook supply chain attack with significant ripple effects. Take the CEO's warning seriously, patch immediately or pull your systems offline.
X
OpenSourceMalware
Help Net Security
The Hacker News
Dark Reading
SecurityWeek
From April to July, 2026, attackers tampered with the supply chain for AOMEI Backupper software in short bursts of five to ten minutes at a time, adjusting configuration files to deliver backdoor malware. AOMEI is a provider of disk management software, and Backupper is the company's backup software for Windows systems. Google Threat Intelligence Group (GTIG) explains that "the threat actor modified the update settings file on the update server to redirect the software to download a malicious ZIP package from attacker-controlled servers instead of legitimate updates," abusing an automatic notification feature to force an immediate download and local execution of a trojanized update if the software checked for updates during a tampering window. The payload includes the CrossRoad downloader, which then stages and downloads the ShinyRoad backdoor. These windows were observed lasting 5, 6, and 10 minutes apiece, after which the attacker would restore the legitimate contents of the configuration files. GTIG characterizes this attack methodology as "anti-analysis by design," and encourages defenders to "focus on behavioral profiling of updater processes, specifically monitoring for unsigned child processes spawned by background update runners and unauthorized network redirection originating from trusted desktop software." ManageEngine Threat Analysis Lab (METAL) identifies five controls to address the attack pattern: Apply asymmetric signing to configuration files and binaries; deliver checksums independently of the URL being validated; separately from file-level checksums, confirm that the delivered content matches the vendor's published baseline; and isolate content display channels from an application's execution paths. METAL notified AOMEI of the tampering in June, and GTIG/Mandiant contacted the company in July as well as notifying potentially affected organizations; AOMEI said on July 29 that corrective actions had been taken. However, the company stated to Recorded Future that it has neither identified nor notified potentially affected customers.

I see two lessons here. First, if you've got an issue, notify affected users in a timely fashion. Second, if you get a vulnerability report and are having issues replicating it, reach out, don't discount it. Your users are overwhelmed with possible issues, so providing useful actionable information will help them sort through the noise and is appreciated.
ManageEngine
Help Net Security
The Record
SecurityWeek
The UK Information Commissioner's Office (ICO) has issued reprimands to Local Government Data Unit - Wales (Data Cymru) and to Data Cymru's IT provider, Ogi Networks Limited (ONL), for security failures under the General Data Protection Regulation (GDPR) that led to a 2024 ransomware attack in which a threat actor stole information belonging to 3,300 people, the majority of whom are children. The attacker carried out this attack using an account ONL had created in 2012, with the username "Test2" and the password "Password1". Once inside, the attacker exfiltrated 42 GB of data from a primary domain controller, a file server, and an SQL server, including "information related to two projects supporting children and families in Wales," and then encrypted 182.7 GB of stored data. ICO also notes that "The local administrator accounts on the three impacted systems all had the same password. This meant that once one system had been breached, the local account hashes could be collected and used by the threat actor to authenticate access to other systems on the Data Cymru network." ONL was reprimanded for creating the unacceptable password in the first place, for failing to audit accounts regularly, and for failing to review administrator accounts after deployment. The reprimand of Data Cymru states that the organization lacked a contract with ONL containing mandatory data protection terms, lacked documentation of responsibilities for ONL's Active Directory services, and failed in the same audit responsibilities regarding the dormant account and regular account reviews. ICO notes that ONL and Data Cymru have a legally compliant data processing contract as of April 30, 2025, and the organizations have introduced a periodic account review process and stronger access controls, including multifactor authentication.

If a provider has ever had admin access to your environment, ask them for a list of every account they created, with an owner and an expiry date for each one. If they can't produce that list, you've learned something important about the relationship.

Ouch. So the account was created in 2012, and while some of us were implementing 2FA back then, MFA wasn't common, but we were (supposed to be) checking for weak passwords, not to mention verifying accounts. While you're working on deploying or if you have already deployed MFA, you likely still have passwords tied to accounts; you need to make sure they are sufficiently robust. These days, there are services you can incorporate into your AD to check for weak or compromised passwords, as well as implementing password standards consistent with the latest NIST SP 800-63B guidelines. Make sure that you're auditing accounts and permissions, eliminating those that are unneeded, unused or unauthorized in a timely fashion.
It’s a bad look, but it highlights a persistent problem: Local governments lack the resources to maintain effective cybersecurity programs. A strong path forward would be establishing long-term funding to centralize security administration and properly resource these services.

Specific accountability and remediation. We need to see this kind of use of law.
ICO
BBC
Infosecurity Magazine
The Register
Chrome Holding Company, a name assumed by 23andMe in the wake of the company’s bankruptcy in March 2025, will pay $6 million to settle a lawsuit brought by the California Department of Justice, which contended "that 23andMe violated California law because its unreasonable data security practices led to the 2023 data breach and that the company made certain misrepresentations that misled its customers and the public." This latest settlement is separate from two other recent suits alleging cybersecurity failings, both of which the company formerly known as 23andMe also settled in 2026, paying $32.5 million to the class of victims whose data were exposed in the breach and $14 million to Kroll, and paying $18 million in a suit brought by 42 state attorneys. HIPAA journal notes that "when the [2023] credential stuffing campaign was discovered, 23andMe maintained that there had not been a breach, and that the compromised accounts were the result of customers’ poor security practices," but investigation revealed that the company had failed to compare passwords against blocklists, to require multifactor authentication, to implement rate limiting or intrusion prevention measures, to log and monitor adequately, to address unusual login patterns, to fix known vulnerabilities, and to properly review and test platform features, among other shortfalls. The October 19 settlement also resolves Attorney General Rob Bonta's objection and appeal alleging that the post-bankruptcy sale of 23andMe to the TTAM Research Institute violated Californians' right to not have their genetic information sold without separate affirmative consent. Bonta reminds Californians that state law empowers them to "control the use of their personal and sensitive data," including to request that 23andMe "delete their data, destroy their test sample, or revoke their permission for their genetic data to be used for research." Bonta's press release provides step-by-step instructions for all three of these requests.

Treat this as an interesting case study. If you find yourself in possession of privacy data that falls under current privacy laws (and there are an ever-increasing number of them), you really need to make sure that you're properly handling that data. Hopefully your legal team is watching these laws and can help you determine what applies. At a minimum, verify your consent processes, which need to include the right to update and delete data, and then go check how that data is secured, isolated, and retained. At this point there is no excuse to let users pick insecure authentication options. Unlike the days when we had to deploy hard tokens for MFA, soft options like passkeys are logistically simple and scale very well. If you've not used passkeys, Amazon, Meta, Google, Uber, PayPal, Ticketmaster, and many other services you already use offer them; your password manager is already set to handle them, and you may even find you're already using some.
SANS Internet Storm Center StormCast Friday, October 23rd, 2026:
PHP2Shell Exploitation Update; Signal Call Hang-Up Flaw (CVE-2026-113380); Cisco Snort 3 Critical Vulnerabilities; Linux KSMBD RCE Reports Leaked
https://isc.sans.edu/podcastdetail/10148
Today's episode covers an update on the PHP2Shell vulnerabilities, a Signal flaw that kept calls alive after hang-up, critical Cisco Snort 3 vulnerabilities, and Linux kernel KSMBD vulnerability reports that were accidentally posted to a public mailing list.
PHP Vulnerability Update
Patches for the PHP remote code execution (RCE) vulnerabilities are now available from many vendors, with notable exceptions such as QNAP. Cloudflare reports a lot of exploit activity, and Amazon saw exploit attempts before public disclosure, but no simple, reliable exploit has surfaced yet. Beware of fake exploits that may attack the person running them.
Signal: Flooded Call Event Queue Blocks Local Hang-Up (CVE-2026-113380)
During a call, the other side could flood a Signal client with events and prevent it from hanging up, leaving the connection active so an attacker could keep listening through the microphone. The flaw has been patched; keep Signal updated automatically.
https://github.com/Imahian/Notes/tree/main/docs/CVEs/CVE-2026-113380
Cisco Snort 3 Critical Vulnerabilities
Cisco patched critical Snort 3 vulnerabilities with a base CVSS (Common Vulnerability Scoring System) score of 9.0. The four CVEs group multiple AI-discovered vulnerabilities by shared CWE (Common Weakness Enumeration), making the individual flaws less transparent. Snort is also included in several Cisco appliances.
Linux Kernel KSMBD Vulnerability Reports Leaked
Trend Micro's Zero Day Initiative accidentally posted unpatched Linux kernel vulnerability reports to a public kernel mailing list, including CVSS 9 remote code execution flaws in the kernel's built-in SMB file sharing server (KSMBD). No patches are available yet, and proof-of-concept exploit code was included in some reports.
SANS Internet Storm Center Stormcast Thursday, October 22nd, 2026:
Critical PHP RCE Vulnerabilities Exploited (CVE-2026-109618, CVE-2026-109619); Fortinet AI-Driven Security Hardening Release for FortiOS and More
https://isc.sans.edu/podcastdetail/10146
This episode covers the critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, which are already being exploited and moved the Internet Storm Center to Infocon yellow, and a Fortinet security hardening release for multiple products based on an AI-assisted security review.
Critical PHP Vulnerabilities (CVE-2026-109618, CVE-2026-109619) Exploited; Infocon Yellow
Two vulnerabilities in the PHP core, an out-of-memory issue triggered by multipart MIME uploads and a memory-clearing flaw exploited with a second request, can lead to remote code execution and can be chained; exploitation is already underway, and your application code, authentication, and configuration will not protect you. Updates are available for PHP 8 but not for PHP 7 or PHP 5, and vendors such as Cisco, Palo Alto Networks, OPNsense, and pfSense have published advisories or updates for their appliances. If you cannot patch, consider web application firewall (WAF) rules that block multipart MIME uploads or temporarily taking the site offline, and assume compromise for public sites without mitigations.
Fortinet Security Hardening Release for Multiple Products
Fortinet announced updates across several products after a security review using AI tools, crediting a number of AI vendors but naming no CVEs and providing few details. The release covers FortiOS, FortiManager, FortiAnalyzer, FortiMail, and FortiAuthenticator, and Fortinet customers should review it and update.
SANS Internet Storm Center Stormcast Wednesday, October 21st, 2026:
eMudhra Intermediate CA Certificates Revoked; Critical PHP Security Release; Oracle CPU E-Business Suite SQLi (CVE-2026-101767); FortiSIEM gRPC RCE PoC
https://isc.sans.edu/podcastdetail/10144
Today's episode covers eight eMudhra intermediate CA certificates revoked after a key generation error, an accelerated critical PHP security release fixing two core vulnerabilities, Oracle's October 2026 Critical Patch Update with 1,295 fixes including an Oracle E-Business Suite SQL injection, and a proof-of-concept exploit for a FortiSIEM gRPC path traversal leading to remote code execution.
eMudhra Intermediate CA Compromise
Eight intermediate CA certificates from Indian certificate authority eMudhra were revoked after a scripting error during the HSM key ceremony left their private keys one byte long. Browsers now reject them, but software with its own CA bundle, like curl on macOS, may need updating. The post includes a browser test page.
https://emudhra.we-have-a-problem.com/
Upcoming Critical PHP Security Release
PHP fixes two critical vulnerabilities in PHP core, rated CVSS 9.2, affecting versions back to PHP 5. The release was moved up to Wednesday, October 21st at 14:00 UTC (10 a.m. Eastern) after details leaked. Expect exploits soon after the patch.
https://www.php.net/archive/2026.php#2026-10-20-1
Oracle Critical Patch Update Advisory - October 2026
Oracle's quarterly update fixes 1,295 new vulnerabilities. Horizon3 is teasing details of an Oracle E-Business Suite SQL injection, CVE-2026-101767.
https://www.oracle.com/security-alerts/cpuoct2026.html
https://x.com/Horizon3Attack/status/2112651247362658611
FortiSIEM gRPC Path Traversal File Write RCE (CVE-2026-106173)
A proof of concept is out for the FortiSIEM flaw patched October 13th. It requires access to port 27918, so block it at the firewall until you patch.
My Upcoming Classes
Catch up on recent editions of NewsBites or browse our full archive of expert-curated cybersecurity news.
Where are your AI agents, and what can they reach? They run on employee machines with real credentials, inside files and production systems. Origin finds every agent and MCP server, including local-only installs, and shows who owns each one. See how it works.
Webinar | AI Summit Fall Solutions Track 2026 | Tuesday, November 3 | Explore real-world approaches to applying AI in cybersecurity programs, focusing on how to move from theory to measurable impact.
Webinar | AI Summit Fall Solutions Track 2026 | Tuesday, November 3 | Explore real-world approaches to applying AI in cybersecurity programs, focusing on how to move from theory to measurable impact.
Webinar | How Predictive AI Is Rewriting the Attacker Timeline | Monday, November 9 | What if your SOC could see the next move before the attacker makes it?