Security teams got a rude reminder this month where older, unpatched Cisco switches are being actively targeted and backdoored with a Linux rootkit in a campaign Trend Micro has named Operation ZeroDisco. If you manage campus or branch network gear, especially older 9400/9300/3750G-series hardware, read this now — the attackers are using a recent SNMP zero‑day plus a reused Telnet exploit to get persistent, stealthy access.
What the attackers are exploiting
Vulnerability: CVE‑2025‑20352 (CVSS 7.7), a stack‑overflow bug in SNMP on Cisco IOS / IOS XE. Cisco released a patch in late September after confirming in‑the‑wild exploitation.
Secondary exploit: A modified exploit for CVE‑2017‑3881 (a Telnet RCE) that the adversary uses to read/write memory on affected devices.
Campaign name: Operation ZeroDisco, the malware sets a universal password containing the text “disco” (one-letter change from “Cisco”), hence the name.
How the attack works (high level)
On 32‑bit devices the attackers send malicious SNMP packets to execute commands and use the Telnet exploit to obtain arbitrary memory read/write.
On 64‑bit devices they deploy a rootkit via the SNMP bug, set the universal “disco” password in memory, then log in and install a fileless backdoor. They can also connect different VLANs to move laterally.
The rootkit monitors UDP packets (even to closed ports) so specific packets can trigger backdoor functionality. It also tampers with IOSd memory to:
install the universal password across many auth methods,
hide running‑config items in memory,
bypass ACLs applied to VTY,
disable or tamper with log history,
reset running‑config timestamps to conceal changes.
Why this is bad
This isn’t just a noisy DoS exploit it’s a stealthy, persistent compromise that actively hides from blue teams. Because the malware modifies device memory and running config in ways that don’t always show in persistent storage, standard checks can miss it. Trend Micro warns there’s currently no reliable universal automated tool to detect ZeroDisco infections across switches.
On October 6, 2025, OpenAI released Guardrails, a new safety framework designed to detect and prevent harmful behaviors in AI systems by leveraging large language models (LLMs) to judge inputs and outputs for risks like jailbreaks, prompt injections, and more. While the framework represents a step forward in modular AI safety, recent research from cybersecurity firm HiddenLayer has revealed significant vulnerabilities showing how basic prompt injection techniques can completely bypass these safeguards.
What is OpenAI’s Guardrails Framework?
Guardrails aims to empower developers with customizable pipelines that filter malicious or harmful interactions in AI agents. Key capabilities include:
Masking personally identifiable information (PII)
Content moderation
LLM-based checks for complex threats like jailbreak attempts, off-topic prompts, hallucinations, and agentic prompt injections (where tools’ outputs misalign with user intent)
Non-LLM tools for filtering URLs and detecting PII
At its core, the framework uses an LLM “judge” to evaluate the safety of outputs generated by the same or similar LLMs powering the AI agent.
“Same Model, Different Hat”
HiddenLayer’s research highlights a fundamental flaw in this design. When the same or a similar LLM is used both to generate content and to judge its safety, attackers can exploit prompt injection vulnerabilities to manipulate both simultaneously. This “same model, different hat” problem means that if the base model is tricked into generating malicious content, the judge model can also be tricked into approving it essentially nullifying the safety layer.
This stands in contrast to traditional non-LLM detectors, which avoid such weaknesses but lack the flexibility to handle nuanced threats like obfuscated jailbreak prompts.
Jailbreak Prompt Manipulation: Using OpenAI’s default gpt-4.1-mini with a 0.7 confidence threshold, the system correctly flagged a malicious prompt requesting harmful instructions (e.g., anthrax sporulation) with 95% confidence. However, attackers crafted injection templates that spoofed the judge’s metadata, reporting a false lower confidence score (e.g., 0.675) below the threshold (e.g., 0.6), allowing the dangerous content to slip through unnoticed.
Agentic Prompt Injection Attacks: The system’s mechanism to block tool misuse, such as unauthorized “fetch” calls that leak sensitive data, can also be circumvented. By embedding fabricated judge override data within web content, attackers convinced the judge LLM to approve malicious tool calls, enabling indirect data exfiltration and command injection.
These exploits underscore the fragility of relying on LLM-based self-judgment for safety-critical decisions.
Why This Matters
As AI systems increasingly integrate into sensitive enterprise workflows, the stakes for robust safety measures have never been higher. Guardrails’ modular design and use of LLM judges are promising — but as HiddenLayer’s findings show, over-reliance on the same model family for both generation and evaluation invites sophisticated adversarial tactics that can evade detection.
Moreover, this research builds on earlier work like HiddenLayer’s Policy Puppetry (April 2025), which demonstrated universal prompt injection bypasses across major models.
Recommendations for AI Safety
To mitigate risks highlighted by this research, organizations and AI developers should consider:
Independent validation layers outside the generating LLM family
Red teaming and adversarial testing focused on prompt injection and judge manipulation
External monitoring and anomaly detection for AI outputs and tool interactions
Careful evaluation of confidence thresholds and metadata integrity
Avoiding sole reliance on self-judgment mechanisms
OpenAI’s Guardrails framework marks meaningful progress in modular AI safety but to avoid false security, it must evolve beyond vulnerable self-policing and incorporate diverse, independent safeguards.
A new and highly polished campaign is targeting macOS users by cloning the Homebrew installation experience and quietly slipping malicious commands into victims’ clipboards. Instead of attacking Homebrew’s package repositories, attackers are impersonating the trusted installation page itself and hijacking the moment users paste the install command.
What’s happening
Researchers uncovered several pixel-perfect replicas of the official Homebrew installer page. Fraudulent domains identified include:
homebrewfaq[.]org
homebrewclubs[.]org
homebrewupdate[.]org
These sites look and behave like the genuine Homebrew install page, but they include hidden JavaScript that interferes with normal copy-and-paste behavior. Rather than allowing users to select the install command manually, the spoofed pages disable normal text selection and force visitors to click a site-provided Copy button. That button runs code which injects extra, malicious commands into the clipboard along with the legitimate Homebrew installer command.
How the attack works
The attacker creates a convincing replica of the Homebrew install page so users won’t suspect anything is wrong.
The page blocks standard selection and clipboard events (contextmenu, selectstart, copy, cut, dragstart), preventing manual copying of the installation text.
A visible Copy button triggers a copyInstallCommand() routine in JavaScript. That routine writes a command string to the clipboard using the Clipboard API or a textarea fallback for compatibility across browsers.
When the victim pastes that clipboard content into Terminal and runs it, the legitimate Homebrew install command executes but it’s accompanied by the attacker’s injected command(s), which download and run additional payloads in the background.
Because the real Homebrew installer runs normally, the infection can be stealthy and persistent while appearing innocuous to the user.
Security analysts also noted Russian-language comments in the code showing where malicious commands are inserted — a sign this may be a commoditized service or a repeatable toolkit attackers can reuse.
Why this is notable
This campaign represents a significant shift in supply-chain style tactics. Instead of compromising package repositories or tampering with software packages directly, attackers have built a parallel interception point: the initial installation experience. That bypasses many defenses that focus on repository integrity and package signing, and it relies instead on social engineering and subtle client-side manipulation of the clipboard.
Homebrew itself has no recent compromise reports, but the attack exploits the strong user trust placed in Homebrew’s installation instructions.
For safety reasons I’ve redacted the exact malicious command observed in the wild. Publishing exact live payload commands or download URLs could enable abuse. If you need to analyze the specific artifacts for incident response, work with a trusted security team and obtain samples through secure channels.
Indicators and detection
Researchers identified the suspicious domains listed above and monitored infrastructure linked to known malware distribution networks. The telltale signs of this campaign include:
Pixel-perfect replicas of the Homebrew installer page hosted on non-official domains.
Disabled text selection and clipboard-related event handlers.
A required on-page Copy button (rather than allowing manual selection).
JavaScript routines that overwrite clipboard contents to append or prepend extra commands.
The cybersecurity world has been rocked by the rise of the Trinity of Chaos, a highly sophisticated ransomware collective that has launched a new data leak site featuring sensitive information from 39 major corporations. This group, possibly a merger of notorious hacker groups like Lapsus$, Scattered Spider, and ShinyHunters, represents a significant evolution in the scale and complexity of cybercrime.
The Trinity of Chaos collective is not just another ransomware gang, it is a hybrid threat actor that merges traditional ransomware tactics with data extortion strategies, creating a new and highly effective form of attack. By combining these methods, they maximize their operational impact and financial return, leaving organizations exposed to both financial losses and reputational damage.
Data Leak Sites on the TOR Network
The group’s primary method of operation revolves around their Data Leak Site, hosted on the TOR network. This is a familiar tactic among modern ransomware groups, and Trinity of Chaos has refined it to a level of operational sophistication that sets them apart.
Rather than announcing new attacks or publicizing their ransom demands upfront, the group opts to share samples of stolen data, including sensitive records, to prove the success of their breaches. This approach not only validates their claims but also increases the pressure on their victims by threatening public exposure. This calculated strategy ensures the group maintains operational security while leveraging the threat of reputational harm to manipulate their targets into compliance.
Previous Salesforce Exploit and Data-Exfiltration Tactics
Trinity of Chaos has already demonstrated their ability to exploit Salesforce environments, a method they refined by exploiting compromised Salesloft Drift AI chat integrations. By using social engineering techniques, the group gains unauthorized access to OAuth tokens, which they then use to infiltrate corporate Salesforce environments. This precise and targeted approach has proven to be highly effective, leading to substantial data breaches and stolen records.
The leaked data from these campaigns primarily includes personally identifiable information, but also reveals internal communications, loyalty program data, and full activity histories. In addition to using this data for extortion, Trinity of Chaos has proven adept at using it for further social engineering campaigns, gaining additional leverage over both companies and individuals.
This particular method of attack prompted the FBI to issue a flash warning, cautioning organizations to monitor their Salesforce instances for signs of intrusion.
Major Corporations Hit
The scale of the breach is unprecedented. Among the compromised organizations are some of the world’s most recognizable names, including:
Google
Cisco
Toyota Motor Corporation
FedEx
Disney/Hulu
Home Depot
Marriott
McDonald’s
These companies, spanning a range of industries including technology, automotive, finance, and telecommunications, are now facing the prospect of massive data leaks unless negotiations with the hackers are met.
Pressure Tactics and Ultimatums
Trinity of Chaos has set October 10th as a hard deadline for negotiations. Like many traditional ransomware operations, the group employs psychological pressure tactics, leveraging the threat of public data exposure and even regulatory reporting that could lead to criminal negligence charges for non-compliant companies.
This combination of tactics heightens the stakes for organizations and forces them to make quick decisions under intense pressure.
A Treasure Trove for Cybercriminals
The Trinity of Chaos collective claims to have amassed an incredible 1.5 billion records from over 760 companies, including:
254 million account records
579 million contact entries
458 million case files
This data, collected over several years, comes from previous attack campaigns such as UNC6395 and UNC6040, showcasing the group’s systematic approach to data aggregation and monetization.
By compiling vast databases of stolen records, Trinity of Chaos is building a cybercrime empire with an unprecedented level of access to sensitive corporate and personal information.
Sophistication and Operational Security
What sets Trinity of Chaos apart is their operational security. The group is known to maintain persistent access within victim networks for extended periods of time, often remaining undetected for years.
This long-term, stealthy approach is indicative of a highly disciplined and experienced group, with extensive operational infrastructure that allows them to scale and evolve their methods over time.
The Rise of a Hybrid Cybercrime Syndicate
The Trinity of Chaos collective marks a significant evolution in the world of cybercrime. By blending ransomware tactics with data extortion and leveraging the TOR network for secure communications and leak sites, they are raising the stakes for both organizations and the cybersecurity industry at large. With an impressive track record, a global reach, and an ever-growing arsenal of attack methods, this group represents a formidable challenge to the cybersecurity landscape.
Organizations are urged to stay vigilant, fortify their defenses, and remain proactive in addressing any potential threats to prevent becoming the next victim of this highly skilled and resourceful group.
As part of its ongoing efforts to strengthen cloud security, Microsoft is introducing a major policy update that will require administrator approval for all new third-party applications seeking access to Exchange and Teams data.
This change, part of Microsoft’s broader Secure Future Initiative, is scheduled to roll out between late October and late November 2025. The update falls under Microsoft’s “Secure by Default” approach, designed to tighten access controls and protect organizational data across Microsoft 365 environments.
What’s Changing and Why It Matters
The core of this update involves changes to the default consent policy managed by Microsoft. Moving forward, any new third-party app requesting access to Exchange or Teams content via APIs such as Microsoft Graph, Exchange Web Services, Exchange ActiveSync, POP3, or IMAP4 will now require explicit administrator approval before access is granted.
This policy does not impact existing apps that users have already authorized. However, if an app requests new permissions or a new user tries to authorize it, the administrator consent process will be triggered.
Organizations that have already implemented custom user consent policies will remain unaffected by this change.
A Consistent Security Approach Across Microsoft 365
This move aligns with previous Microsoft efforts to improve baseline security, including earlier changes to SharePoint and OneDrive, where legacy protocol access was blocked and admin consent was required for file-level third-party access.
By expanding this model to Exchange and Teams, Microsoft continues to harden its platform against potential abuse and unauthorized data access, without requiring customers to purchase additional licenses.
What IT Teams Should Do Now
To prepare for the rollout, Microsoft recommends several key actions for IT administrators:
Review Existing Permissions Audit your current environment to identify third-party applications accessing mail, calendars, contacts, and Teams chat or meeting data.
Enable the Admin Consent Workflow Set up the admin consent request workflow in Azure AD (Entra ID). Without this, users won’t have a way to request access to blocked apps.
Create App Access Policies for Trusted Apps For critical third-party tools your organization relies on, preemptively create granular app access policies to avoid disruption.
Communicate the Changes Inform IT teams, app owners, and security personnel about the upcoming policy shift. Update on-boarding documentation and internal guidelines accordingly.
This policy update underscores Microsoft’s commitment to improving tenant security by default, giving administrators greater control and visibility into third-party integrations. With rising threats targeting collaboration platforms and messaging systems, this is a timely and necessary evolution in Microsoft’s security posture.
Red Hat, widely recognized as the world’s leading provider of enterprise open-source solutions, has confirmed a significant cybersecurity incident involving unauthorized access to an internal GitLab server used by its Consulting team.
The breach, now under active investigation, follows claims by the hacker group Crimson Collective, who allege they exfiltrated approximately 570GB of compressed data from over 28,000 private repositories. If accurate, this would mark one of the most substantial source code leaks in recent memory.
Red Hat Consulting GitLab Environment Is The Target
According to Red Hat’s official disclosure, the breach targeted a GitLab environment used for collaboration within Red Hat Consulting, supporting engagements with select clients. An unauthorized third party was able to access and extract data from the server before detection.
In response, Red Hat initiated a full-scale investigation, cut off attacker access, isolated the compromised system, and alerted the relevant law enforcement agencies. The company has since rolled out additional security hardening measures.
What Was Exposed?
Initial reports suggest the stolen data includes a vast trove of sensitive technical assets, such as:
CI/CD secrets and pipeline configurations
VPN profiles and infrastructure blueprints
Ansible playbooks and OpenShift deployment guides
Container registry configurations and Vault integration secrets
SSH keys, API tokens, and database credentials
Security researchers examining the data found references to thousands of organizations, spanning multiple critical sectors. These include major financial institutions like Citi, JPMC, and HSBC, telecom giants such as Verizon and Telefonica, industrial leaders like Siemens and Bosch, and even U.S. government entities, including the U.S. Senate.
Potential Supply Chain Risks
The breach is being described as a supply chain threat, as many of the exposed repositories contain Infrastructure-as-Code templates, automation scripts, and configuration files that could be weaponized in secondary attacks.
Particular concern are:
Kubernetes deployment manifests
Container registry credentials
GitLab CI/CD runner configurations
Privileged deployment pipelines
These components often carry elevated access within enterprise environments, making them prime targets for lateral movement or persistent backdoor access.
Red Hat’s Response & Ongoing Investigation
Red Hat has emphasized that its main software supply chain and official distribution channels remain unaffected. The breach is not linked to the recent CVE-2025-10725 vulnerability involving OpenShift AI services.
While forensic analysis is still ongoing, Red Hat has committed to notifying any Consulting clients directly affected by the breach. The company continues to work with cybersecurity experts and authorities to fully understand the incident’s impact.
The OpenSSL Project has issued a critical security advisory highlighting three major vulnerabilities that could enable remote code execution and the potential recovery of private cryptographic keys.
These security flaws affect various OpenSSL versions across multiple platforms, posing risks such as memory corruption, denial of service, and unauthorized access to sensitive cryptographic data.
The most serious of these issues is tracked as CVE-2025-9230, rated with moderate severity. It stems from out-of-bounds memory operations in the implementation of the RFC 3211 Key Encryption Key unwrap functionality.
This vulnerability is triggered when applications decrypt Cryptographic Message Syntax messages using password based encryption. Exploitation may result in out-of-bounds read and write operations, leading to memory corruption. If successfully exploited, attackers could execute arbitrary code or crash the affected system.
Memory Corruption Vulnerability
CVE-2025-9230 is a vulnerability in OpenSSL that stems from improper handling of Cryptographic Message Syntax message decryption. It affects a wide range of versions, including 3.5, 3.4, 3.3, 3.2, 3.0, 1.1.1, and 1.0.2.
The flaw is triggered when an application attempts to decrypt specially crafted messages that use password based encryption. This can lead to out-of-bounds memory access, including write operations that may corrupt memory. An attacker exploiting this could potentially overwrite critical memory regions, enabling the execution of shellcode or arbitrary commands.
Discovered by Stanislav Fort and the Aisle Research team on August 9, 2025, the vulnerability arises from insufficient bounds checking in the Key Encryption Key unwrap algorithm. Specifically, the code fails to properly validate buffer boundaries, making it possible for attackers to exploit integer overflows and trigger buffer overflows during decryption.
Although the exploit requires certain conditions, namely, the use of password based encryption in Cryptographic Message Syntax messages its impact is severe. Fortunately, password-based encryption is rarely used in real-world deployments, limiting the attack surface. Additionally, OpenSSL FIPS modules are not affected, as the Cryptographic Message Syntax implementation lies outside the FIPS boundary.
If exploited, this vulnerability could result in full remote code execution, leading to complete system compromise.
Timing Side-Channel Flaw
The second critical vulnerability, CVE-2025-9231, introduces a timing side-channel flaw in the SM2 cryptographic algorithm implementation on 64-bit ARM platforms.
According to the OpenSSL advisory, this vulnerability could allow remote attackers to recover private keys by analyzing timing variations during cryptographic operations specifically, during SM2 signature generation.
Although OpenSSL does not natively support SM2 certificates in TLS contexts, the risk arises in environments where custom cryptographic providers enable SM2. In such cases, the vulnerability may be exposed in production deployments.
Timing side-channel attacks exploit minute variations in how long cryptographic operations take to execute. In this case, discrepancies in SM2 signature computation create measurable timing patterns, which can be analyzed remotely to reconstruct private key material. These attacks typically require repeated observations over the network, but they are feasible under the right conditions.
This vulnerability specifically affects OpenSSL versions 3.5, 3.4, 3.3, and 3.2 on 64-bit ARM architectures. Earlier versions 3.1, 3.0, 1.1.1, and 1.0.2 are not affected due to differing implementations of the SM2 algorithm.
Another issue, CVE-2025-9232, involves an out-of-bounds read in the OpenSSL HTTP client when handling IPv6 addresses in the no_proxy configuration. This flaw is considered lower risk and is limited to potential denial-of-service outcomes.
Organizations using custom providers that support SM2 are strongly urged to apply patches immediately to mitigate the risk of private key exposure via timing analysis.
Patched versions include:
OpenSSL 3.5.4, 3.4.3, 3.3.5, 3.2.6
OpenSSL 3.0.18, 1.1.1zd (premium support)
OpenSSL 1.0.2zm
Shopping Basket
...
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
►
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
