CISA red teams fully compromised two critical infrastructure orgs. One SOC isolated hosts in minutes; the other never detected the breach. CISA published an advisory (AA26-237A) documenting two simultaneous red team assessments at critical infrastructure organizations. Both organizations lost full domain control and had their cloud environments compromised. One of them didn’t know until CISA told them afterward. “The Cybersecurity and Infrastructure Security Agency (CISA) conducted simultaneous red team assessments at two organizations and observed different defensive outcomes. In both environments, the red team achieved full domain compromise and accessed sensitive business systems (SBSs) and cloud resources.” states CISA. “Organization A failed to detect or contain the activity, but Organization B rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model.” Organization A is a Government Services and Facilities Sector entity. Organization B operates in the Water and Wastewater Systems Sector. The red team used comparable techniques against both. The difference in outcome was entirely about detection and response, not the sophistication of the attack. At Organization A, the red team found a web application that still used default credentials. They used it to send phishing emails from a trusted internal address and gained access to four workstations. From there, they exploited a misconfigured Active Directory Certificate Services template with the ESC1 flaw. This allowed a low-privileged user to request certificates for other users, including administrators. They then reached all the targeted sensitive business systems without anyone noticing. After moving into the cloud, they even read SOC staff emails to see if the attack had been detected. It hadn’t. “Without well-defined baselines and alert filtering, false positives and routine alerts overwhelm defenders, obscuring real threats.” CISA continues. “Organizations that tune alerts to highlight anomalies and filter out normal business activity enable defenders to focus on genuine incidents and respond rapidly.” Organization A’s SOC was receiving thousands of false positive alerts, many at higher severity than the actual intrusion alerts the red team was generating. Staff eventually reviewed SCCM-related alerts from real red team activity, couldn’t identify the system’s owner or function, and marked it a false positive. The red team confirmed the miss by reading SOC email. Then they used keyloggers and screenshot capture on SOC workstations to make sure nothing was coming. Nothing was. The organization had multiple separate SOCs with different EDR solutions and no cross-team visibility, which meant that even if one team noticed something, there was no mechanism to act on it across the relevant systems. “Detection tools are only as effective as the people, processes, and procedures supporting them. SOC staff should not operate in silos and should have clear authority unhindered by bureaucracy to effectively contain and resolve incidents.” add CISA. At Organization A, SOC analysts were managing systems they didn’t fully understand and had no written escalation procedures, so their default response to ambiguity was to wait. At Organization B, staff triaged, investigated, coordinated with engineering, and reimaged machines before handing them back to users. At Organization B, the red team still found important security gaps. They discovered a password stored in plain text inside an XML file on an SCCM distribution point. They used the related service account to gain powerful rights over a domain controller and then performed a DCSync attack, obtaining the krbtgt hash. This allowed them to create Golden Tickets and impersonate users across the domain. They also found a path into the OT network through RDP files pointing to a bastion host. Using FTP credentials found on a jump server, they connected to the bastion through SSH. The bastion had no outbound internet access, so their payload could not run, and the SOC quarantined the host. Still, the access path was there. Both organizations also had the same cloud security problem: neither had enabled Conditional Access for workload identities. This Microsoft feature applies access controls to applications and service accounts, not just human users. Without it, applications with broad Microsoft Graph permissions can bypass normal Conditional Access rules. CISA’s red team used this gap in both organizations to access emails across the companies. In Organization A, the team also found AWS IAM credentials stored in users’ home directories with no expiration date. Those credentials could remain valid indefinitely, creating another long-term risk. In Organization B’s cloud environment, the red team abused Seamless SSO by using Kerberos tickets obtained via DCSync to authenticate to Azure without needing any user’s cleartext password. They found a disabled AD-synced account that owned an application with permission to read, write, and send emails for every user in the tenant. They re-enabled the account, DCSynced its credentials, added a client secret to the application, and could then access the full mailbox of every employee from the public internet. Organization B’s detections flagged the AzureHound tool by user agent and caught anomalous Microsoft Graph API request volumes, but those controls arrived after the initial cloud access was already established. CISA recommends several practical steps to improve security. These include hardening ADCS by disabling CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT on templates and limiting who can enroll, setting the Machine Account Quota to zero when there is no operational need, and removing cleartext credentials from workstations and network shares. Organizations should also enable Conditional Access for workload identities, create procedures to revoke tokens, and treat SCCM and similar endpoint management platforms as Tier 0 assets, giving them the same level of protection as domain controllers. The full advisory also maps each red team technique to its MITRE ATT&CK identifier and compares how well the two organizations detected the different stages of the attacks. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
Snowflake is ending password authentication for legacy service accounts, forcing organizations to migrate them to passwordless methods. Token Security explains why the harder challenge is identifying what uses each account, who owns it, and how much access it still needs.
Attackers are actively exploiting a critical-severity vulnerability in the Gitea self-hosted Git service, according to the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Like cloud-hosted GitHub or GitLab SaaS (Software as a Service) platforms, Gitea provides a full suite of DevOps tools, but it is designed to be used as a self-hosted software development platform. Tracked as CVE-2026-60004 and reported by Salesforce security researcher Shai Rod, this code injection security flaw allows an authenticated user with repository write access to repositories hosted on vulnerable servers to execute arbitrary shell commands with the privileges of the Gitea service account by submitting malicious patches via the diffpatch API endpoint. However, default-configured Gitea instances have self-registration enabled, allowing unauthenticated attackers to register an account, create a new repository, and trigger the vulnerability without prior credentials.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Gitea flaw to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added an Oracle HTTP Server and Oracle Weblogic Server Proxy Plug-in flaw, tracked as CVE-2026-60004 (CVSS score of 9,8), to its Known Exploited Vulnerabilities (KEV) catalog. Gitea is an open-source platform for hosting and managing Git repositories. Think of it as a self-hosted alternative to GitHub or GitLab. CVE-2026-60004 is a critical remote code execution flaw that allows an attacker with write access to a repository to execute arbitrary shell commands as the Gitea service user. The flaw affects Gitea versions from 1.17 and was fixed in 1.27.1. The vulnerable diffpatch API can be abused to plant and execute a malicious Git hook. Because Gitea enables open registration by default, an unauthenticated attacker can create an account, create a repository, and exploit the flaw without existing credentials. A reported attack used the vulnerability to deploy a cryptocurrency-miner-like payload after an exposed Gitea instance allowed open registration and anonymous access to its web interface. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaw by August 28, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
Cybersecurity researchers have disclosed details of a phishing-as-a-service (PhaaS) platform built to strip Apple's Activation Lock from stolen devices, using rented AI voice agents that call theft victims posing as Apple Support and ask for their device passcode. SOCRadar Threat Research Unit (STRU) said the platform, which it tracks as AnonyMousKIT, is credit-metered and drives lures across
A newly uncovered phishing-as-a-service (PhaaS) platform called AnonyMousKIT automates the retrieval of codes used to unlock stolen Apple devices and disable the Activation Lock feature. The illegal service has been active since early 2024 and is powering a structured ecosystem that sells stolen iPhones, harvests Apple IDs, accesses iCloud backups, and Keychain credentials. Researchers at threat intelligence platform SOCRadar took advantage of the platform operator's use of bare relative paths to gather information on how the service works, its operators, and infrastructure. SOCRadar found that AnonyMousKIT is connected to 506 domains and is fueling a sprawling business with 168 storefront brands acting as resellers. The researchers recovered records of 200 calls made to victims between August 2025 and May 2026, using 55 distinct interaction transcripts handled by a voice AI agent operating under five personas.
Two CVSS 9.8 miniOrange SAML WordPress plugin auth bypasses were exploited while paid editions never appeared in any vulnerability database. Manual patch required. Two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign On WordPress plugin, both rated CVSS 9.8, are under active exploitation. Both CVE-2026-61979 and CVE-2026-15981 allow an unauthenticated attacker to forge a SAML authentication response and arrive in /wp-admin as any existing user, including administrators. The bugs are independent and both have been confirmed exploited in the wild. CVE-2026-61979 is an algorithm confusion flaw. The plugin trusts the incoming SAML response to declare its own signature algorithm. An attacker sets that algorithm to HMAC-SHA1, which causes the plugin to use the identity provider’s RSA public key as the HMAC secret. The RSA public key is, by definition, public. That’s the whole attack: fetch the key from the metadata endpoint, sign your own forged assertion with it, and the plugin verifies it as genuine. CVE-2026-15981 is a PHP bug caused by incorrectly handling different types of values. The openssl_verify() function can return three results: 1 when a signature is valid, 0 when it is invalid, and -1 when OpenSSL encounters an error. The plugin treated the result like a simple true-or-false value. In PHP, -1 counts as true. An attacker can send a specially crafted signature that causes an OpenSSL error, making the function return -1. The plugin then treats it as a valid signature and allows the attacker to log in. It is a basic coding mistake, but particularly serious because the plugin handles authentication for WordPress admin accounts. The technical root cause is interesting. What happened around the bugs afterward is more interesting. The miniOrange SAML plugin ships under one WordPress slug, miniorange-saml-20-single-sign-on, but that one listing actually contains seven completely separate product editions, each with its own independent version numbering. Free runs from 3.x to 5.x. Premium runs 11.x to 13.x. Standard runs 15.x to 17.x. VIP editions start at 32.x and 35.x. No two editions share a version range. When the public advisories were written, they covered only the Free edition, which is the one anyone can download from WordPress.org. The fix for the Free edition landed at 5.4.5. “While that record is correct, when you apply it to the slug, every paid install carries a higher version number than 5.4.5, so every paid install reads as already patched.” reads Patchstack analysis. “Therefore, any WordPress site that was running a vulnerable version like 16.1.9 reported it as patched, along with every other (13.x, 20.x, 26.x, 32.x, and 35.x) vulnerable version.” Every database, scanner, and dashboard in the WordPress security ecosystem was telling paid-edition administrators their sites were safe when the exploitable code was still running on their servers. The update prompt problem makes it worse. Sites running a vulnerable Standard edition 16.x see no available updates in their WordPress admin panel because the fix is on the 17.x line, and WordPress’s built-in update mechanism doesn’t offer cross-line jumps automatically. The path from vulnerable to patched requires a manual plugin upload, which site owners can’t do if they don’t know they’re affected, and every system they rely on was telling them they weren’t. “There was no advisory to read and no vulnerability database entry flagged the paid edition for these vulnerabilities. The plugin reported itself as fully up to date. In other words, every signal that normally warns of a problem suggested that everything was fine.” continues the report. “So, how did DigitalOcean catch the exploit? It had nothing to do with plugins or versions. An anomalous WordPress administrator session attempt appeared from outside their trusted network and was blocked. The attacker had already used the bypass to obtain a WordPress admin session cookie, but was stalled because the admin panel operations themselves sat restricted behind the trusted network. “ DigitalOcean, the team that found all of this, caught the exploit not through any of those systems but through a network anomaly: an authenticated WordPress administrator session arriving from outside their trusted network perimeter. The attacker had already used one of the auth bypasses to generate a valid admin session cookie. The cookie worked. The session was blocked because the admin panel itself was restricted to trusted network ranges. Defense in depth, doing exactly what it exists to do, on a system where every other detection layer had already failed. DigitalOcean then traced both bugs to specific lines of code in the plugin and its bundled XML security library, confirmed the affected version ranges across all seven paid editions (which miniOrange had not published anywhere), wrote two narrowly scoped hotfixes to buy time, and handed the full analysis to Patchstack for publication. Patchstack worked with miniOrange to get the complete edition and version matrix, then updated its database with all seven affected ranges, the first time any public database held that information. Attackers are actively scanning miniOrange SSO endpoints from six IP addresses in Belgium, Nigeria, the U.S. and Germany. The activity appears opportunistic, with attackers checking websites that use the plugin without first identifying the specific version or edition. That makes the silent patch especially concerning. Attackers can probe systems without knowing what version they run, while website owners may not realize whether their plugin has received the fix. “Vulnerability databases are only as good as the version data vendors publish publicly. When a vendor runs seven independently numbered editions under one slug and patches six of them without a public advisory, the entire ecosystem downstream of them goes blind at once: databases, scanners, dashboards, and the site admins relying on all three.” concludes the report. For anyone running this plugin, the full version table per edition is in the Patchstack article. The short version: find your edition, compare your version against the patched column, and expect to do the upgrade as a manual upload rather than through the WordPress dashboard. If you can’t update immediately, two narrowly scoped hotfixes covering both CVEs are published there alongside the IPs to check in your logs for prior exploitation attempts. Check the passkey and admin account list while you’re in there. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, miniOrange SAML WordPress Plugin)
Healthcare and services provider Nutex is investigating a data breach incident where an unauthorized third party exfiltrated information from company servers. The organization has disclosed the cyberattack in a filing with the U.S. Securities and Exchange Commission (SEC), noting that the stolen data includes details that may be private or confidential. “Based on preliminary findings from the Company’s ongoing investigation, the Company believes that certain information maintained on the Company’s servers was accessed and exfiltrated by an unauthorized third party, including some information that may be private and/or confidential,” Nutex says. Nutex Health is a for-profit healthcare company that operates 28 facilities across 12 states, including the Bayou City ER & Hospital in Texas and Green Bay ER & Hospital in Wisconsin.
Attackers are increasingly targeting the processes used to establish or recover identity rather than attacking the login itself. Specops explains how stronger identity verification can help organizations prevent fake workers and social engineering attacks from gaining legitimate access.
Explore Unit 42 research on AI-enabled malware. Learn how existing behavioral detection and endpoint analytics stop AI-authored code before execution. The post The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution appeared first on Unit 42.
Confirm this action.
Leaving now will discard your changes.