Hackers are attempting to exploit two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin for WordPress that can be used to forge SAML responses and log in as administrators. The miniOrange SAML SSO plugin turns a WordPress site into a SAML service provider, letting users log in through corporate identity platforms such as Microsoft Entra ID, Okta, Google Workspace, or OneLogin instead of separate WordPress credentials. Created by Xecurify, miniOrange is a family of seven plugins, with a free version that has 10,000 downloads and 30,000 customers for the other six. The two vulnerabilities observed in exploitation attempts are tracked as CVE-2026-61979 and CVE-2026-15981 and can be chained together to bypass authentication. Because the miniOrange SAML SSO plugin accepts the signature algorithm from incoming SAML responses instead of enforcing the configured one, an attacker can leverage CVE-2026-61979 to select HMAC-SHA1. This causes the plugin to treat the RSA public key from the identity provider (IdP) as the shared secret.
The U.S. Department of Justice announced a $400 million settlement with TikTok, ByteDance, and affiliated companies over allegations that they violated the Children’s Online Privacy Protection Act (COPPA). The TikTok social media platform, owned by the Chinese technology company ByteDance, allows users to create, watch, and share short-form videos. In 2024, the U.S. Department of Justice filed a lawsuit against TikTok and its parent company, alleging violations of COPPA dating back to 2019. In 2019, Musical.ly, TikTok’s predecessor, agreed to a $5.7 million settlement with the Federal Trade Commission (FTC) over allegations of illegally collecting personal data from users under 13 without parental consent. Last year, the FTC referred a new investigation to the DoJ, claiming that TikTok continued to breach COPPA rules despite its 2019 commitment to comply with the rules.
Cybersecurity company ReliaQuest has confirmed that one of its employees was targeted in a social engineering attack after hackers impersonated a member of the security team. In a statement over the weekend, ReliaQuest said that an attacker called multiple employees and tried to trick them into accessing "a fake ReliaQuest single sign-on (SSO) page behind a content delivery network." Last week, ReliaQuest's Threat Research team shared in a now-deleted post, that the ShinyHunters extortion gang was registering .claims domains to impersonate company's help desks and IT teams. "ReliaQuest is tracking a widespread ShinyHunters campaign using domains that follow the company[.]claims pattern. These domains incorporate the targeted organization’s name or abbreviation under the .claims TLD," read the company's post on X.
A breach at South Korea's government-backed startup platform exposed encrypted personal data after an encryption key was included in an API. Penta Security explains why encryption keys must be securely managed and kept separate from the data they protect.
Slovakia warns that vulnerable speed cameras could expose vehicle data, enable remote access and provide attackers with a foothold into public networks. Slovakia’s National Security Authority, NBÚ, recently issued a warning about several road speed cameras, calling them a significant cyber threat. The alert is not about someone deleting a speeding ticket. It is about connected devices that collect vehicle data, communicate with other systems, and may contain remote-access functions that the operator cannot fully control. The Slovak authority examined a sample of the NERO R-ONE camera system at the request of the Interior Ministry. It named three product lines in its warning: NERO R-ONE devices sold by Cyprus-based SODASUS, Cordon-series speed cameras made by Russia’s Simicon, and Cordon-series products sold by Croatia’s NEROline. “The National Security Authority warns of a significant cyber threat associated with the use of several types of road speed cameras.” reads the alert. “A security analysis has identified several risks and recommends that affected entities identify the products in question in their infrastructure.” The problems went beyond a simple configuration issue. NBÚ found differences between the documented and actual communication settings, uncertainty about where the hardware and software came from, software that did not match the declared version, and weak security protections. “The security analysis identified several risks, including the true origin of the camera hardware and software, inconsistency between the documented and detected configuration of the product’s communication interfaces, and pre-configured remote access and product management mechanisms.” the agency wrote on LinkedIn. That last point deserves attention. A road camera should be managed by the organisation that owns it, under controls that it can inspect, configure and audit. If a device includes pre-set remote-access or management mechanisms outside the customer’s full control, it creates a blind spot in a system that may sit on a public-sector network or communicate with other operational services. Speed cameras do much more than take pictures and measure speed. They photograph vehicles, record timestamps, process licence-plate data, store evidence and send information to backend systems used by authorities. Depending on the setup, they may also connect to mobile networks, roadside equipment, police systems, municipal platforms or third-party maintenance services. If attackers compromise a camera, they could access data, change or delete records, manipulate how it measures or reports violations, or shut it down. If the network lacks proper segmentation, they could also use the camera as a foothold to reach other systems. The camera may not be the real target. It could simply be the unlocked door. The warning aims to alert essential-service operators and other organisations that these road cameras could pose a serious cybersecurity risk. In the wrong circumstances, attackers could use them to disrupt networks, systems or services. The Slovak Interior Ministry reportedly took the equipment out of its pilot deployment while the matter was investigated. Public reporting also says the ministry asked the supplier to remove the units and replace them with equipment meeting Slovak and EU legal, technical and security requirements. The Russian connection adds an obvious geopolitical dimension, but it should not become a substitute for technical analysis. NBÚ did not say that every device was actively spying on users or that the equipment contained a proven backdoor. Its warning is about identified security risks, limited operator control, uncertainty over hardware and software provenance, and remote-management mechanisms that could not be fully accounted for. That is enough reason to take action. Security checks for connected public devices cannot rely only on the brand, the country listed on the invoice or the vendor’s claims. Operators should know exactly what software and firmware the device runs, how remote access works and who controls it. They should also use independent security testing, secure updates and network segmentation. The same lesson applies beyond Slovakia. Smart cameras, licence-plate readers, parking sensors, environmental monitors, traffic lights and roadside communication systems are becoming part of public infrastructure. They are often cheap, easy to overlook and managed by public agencies, contractors and manufacturers. That makes them just as important to secure as other critical systems. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Speed Cameras)
iAuthFlow v2 phishing toolkit uses a phished Google session to enroll an attacker-controlled passkey that survives password resets. Abnormal Security researchers have published an analysis of iAuthFlow v2, a phishing toolkit sold on a Russian-language cybercrime forum for $10,000 base price. The author also offers for sale additional capability modules separately. The headline feature is not the phishing itself. It’s what happens after the phishing succeeds. “Once the target completes a phishable Google login, the toolkit uses the authenticated session to enroll a passkey controlled by the operator.” reads the report published by Abnormal Security. “In the seller’s recorded demonstration, the account owner later changes their password, invalidating the active session—but the operator authenticates with the newly enrolled passkey and returns to the mailbox.” That’s the architecture. The phishing flow gives the attacker a temporary window. iAuthFlow v2 uses that window to create a permanent key that doesn’t close when the window does. The toolkit uses a browser-in-the-middle attack. The victim sees what looks like a real Google login page, while iAuthFlow v2 runs another browser on the attacker’s server. Everything the victim types, including their email, password and two-factor code, is sent to that remote browser, which logs in to Google. The victim provides the credentials, while the attacker gets the authenticated session. In the demo, the fake login page used a trycloudflare.com subdomain, giving the link a valid TLS certificate and a more trustworthy appearance. Once the relay gives the attacker’s browser Google’s session cookies, iAuthFlow v2 holds the target on a “Verification, Processing” page while the toolkit works inside the account. This pause is a named state in the software, not a recording artifact. The session log timestamps tell the story precisely: login at 21:37:18, passkey created and saved at 21:37:24. Six seconds to establish persistent access. The passkey module navigates the target’s Google passkey settings through the authenticated browser and requests a new credential. Google may ask for identity re-verification before allowing the enrollment; the demo shows the toolkit handling this. The enrolled passkey is then stored on the attacker’s side, and the toolkit records “Passkey created and saved.” “The log records “Passkey created and saved.” At this point, the operator no longer has only the authenticated session created through the phishing flow.” continues the report. “The newly enrolled passkey is a separate authentication credential registered to the target’s Google account. The subsequent demonstration shows Google offering that passkey during a later sign-in, consistent with the operator retaining the credential needed to use it.” This is more serious than simply stealing a session cookie because a password reset does not remove a passkey. Changing a Google password ends active sessions, revokes app passwords and invalidates some OAuth tokens. A passkey is different: it is a separate cryptographic credential linked to the account and remains active until it is manually removed. The demo shows the risk clearly. After the victim changes their password, the attacker’s session stops working. But the attacker can choose “Try another way,” use the passkey they previously added and regain access to the mailbox. The victim may have no idea this happened. Abnormal notes a technically plausible mechanism for how iAuthFlow v2 stores and uses the passkey: Chromium’s software-based virtual authenticators, which support WebAuthn registration and retain private keys without requiring the target’s physical device. The researchers don’t confirm this is what the toolkit uses, since the demonstration doesn’t reveal the implementation. What they confirm is that the behavior shown is consistent with how passkeys work, and there’s an available path to produce it. The toolkit targets Google in the build Abnormal examined, but the seller advertises versions for Microsoft, iCloud, and LinkedIn. The same post-authentication persistence logic applies wherever passkeys can be enrolled. Containment after an iAuthFlow v2 compromise needs to go further than incident response teams are often used to going. “That cleanup is particularly important with iAuthFlow v2 because neither a password reset nor session revocation removes an attacker-enrolled passkey.” states the report. “Restore the account only after unauthorized authentication methods and other persistence mechanisms have been removed.” The full sweep should cover unauthorized passkeys and security keys, malicious Gmail filters and forwarding rules, delegated access, OAuth grants and app permissions, and recovery settings. Organizations running Google Workspace can use the Security Investigation Tool to audit the account before declaring it clean. The best way to prevent these attacks is to rely on authentication methods that cannot be easily stolen through phishing. WebAuthn-based authentication is tied to the real website, so stolen passwords or codes cannot be used through a relay attack. Google Workspace can enforce this with the “Only security key” option for 2-Step Verification and through the Advanced Protection Program. These settings also disable app passwords, which the toolkit may target on less protected accounts. The toolkit’s price and professional sales channels suggest this is an ongoing business, not a one-time release. If a Google account is compromised but appears clean after a password reset, security teams should also check the account’s passkeys and security keys before closing the case. “iAuthFlow v2 illustrates how phishing has evolved beyond stealing credentials or even hijacking a single authenticated session. Once an attacker gains legitimate access to an account, that access can become a starting point for establishing new authentication methods, modifying account settings, and creating other forms of persistence.” concludes the report. “Response and recovery cannot end with a password reset or session revocation. Organizations must also examine what changed after authentication—especially newly enrolled credentials, recovery methods, OAuth grants, and mailbox settings—and remove anything the attacker left behind. “ Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, iAuthFlow v2 phishing toolkit)
Cybersecurity researchers have flagged two new malware families called WordlistLoader and SynkLoader that's used to deliver next-stage payloads and likely sell access to ransomware groups. According to findings from Gen Digital, WordlistLoader is being used to deliver Amatera Stealer (aka ACR Stealer or AcridRain Stealer) via ClearFake campaigns, which employ the ClickFix (aka FakeCaptcha)
Red Hat and the Keycloak project have released patches to address a critical security flaw in the open-source identity and access management server that could allow an unauthenticated remote attacker to take over any user account by forcing a password reset. The vulnerability, assigned the CVE identifier CVE-2026-18963, is rated 9.1 on the CVSS scoring system by Red Hat, which acts as
Security Affairs Malware newsletter includes a collection of the best articles and research on malware in the international landscape Malware Newsletter Akira Hits Safe Mode: Ransomware Rebooting Around EDR Multi-Functional Linux Botnet “Evooo1Bot” StubMaker RubyGems Campaign Delivers a Windows Infostealer Hunting MacSync Stealer infrastructure through behavioral pivots Manic: Blend between Banking Malware & Spyware Clop Returns with Custom Implant in Mass-Extortion Campaign The ToxicPanda Never Sleeps: ToxicPanda 2.0 Prepares its Next Strike on Mobile Striking gold: Inside the GoldDigger Android malware SilkParasite: Tracking a China-Nexus APT Across Central Asia Prompting the Payload: How an npm Supply Chain Attack Delivers the RedC2 AI-Powered Linux Implant The invisible passenger in your car Malware Crypting Services and the Threat Actors Who Sell Them Grandoreiro goes north: From Brazil to Mexico with a new DLL sideloading campaign Survival of~the~Stealthiest: Evolving Low-Entropy Ransomware via~Genetic Algorithms Malformer: A Multi-Modal Malware Detector Using Transformers XAI-Guided Graph-Based Feature Engineering and Heterogeneous Ensemble Learning for Android Malware Detection An Explainable Deep Learning Pipeline for Malware Family Classification: GAF Image Encoding and API-Grounded LLM Interpretation Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Iran-linked hackers shut down a UK power plant for four days in the first confirmed attack of its kind, concurrent with water infrastructure attacks across 12 US states. Iran-linked hackers shut down a British power plant for four days in what The Telegraph describes as the most successful cyberattack of its kind against UK energy infrastructure. “Iran shut down a British power plant for four days in an unprecedented cyber attack, The Telegraph can disclose.” reads the report published by The Telegraph. “It is thought to be the first time that hackers affiliated to the Iranian regime have succeeded in closing down such a facility in the UK, and is believed to be the most successful cyber attack of its kind.” British officials did not name the power plant because of security concerns. Staff worked for four days to restore it, but the plant was small and the outage did not affect the UK’s wider power supply. Still, the government warned power companies and businesses about the incident and provided guidance on how to respond. The attack was reported to the National Cyber Security Centre (NCSC), part of GCHQ, which helps protect the UK’s critical infrastructure. The NCSC did not comment on the specific incident. The US water infrastructure attacks hit dozens of wastewater treatment plants across 12 states, causing flooding and loss of pressure from taps. Authorities in affected areas told customers to boil water. The first reports came from Minnesota on July 26, followed by similar breaches in Michigan, Georgia, South Dakota, and New Jersey. The FBI attributed those incidents to “malicious cyber actors”; US government sources later confirmed the threat most likely originated in Tehran. The UK attack is not thought to have been designed to harm civilians. The more probable intent was to demonstrate that hackers linked to Iran’s Islamic Revolutionary Guard Corps could gain access to UK infrastructure and shut it down at will. A four-day outage at a small generator that nobody outside the industry noticed is, from that perspective, a successful proof of concept. Iran has accelerated its cyberattacks on Western countries since the US and Israel began air strikes in February. Suspected Iranian operations have been reported in Germany, Poland, Finland, Belgium, and Albania, with Israel and other Middle Eastern countries remaining the most frequent targets. In March, the NCSC advised British organisations to review their security posture in light of the wider conflict. NCSC chief executive Richard Horne said in June that the agency had handled more than 200 attacks on critical national infrastructure in the previous year alone. The timing is awkward for the intelligence and security committee, which oversees UK spying agencies. “Experts have long warned that the UK is unprepared for the scale of the threat of malicious cyber attacks from foreign adversaries, and the intelligence and security committee, which oversees spying agencies, reported last year that the chance of an Iranian cyber attack on British infrastructure was “unlikely”.” continues the report. A Cabinet Office risk assessment published last month placed the probability of a serious and successful cyberattack on domestic infrastructure at between five and twenty-five percent. The same document warned that AI is making attacks faster and cheaper to run, and is lowering the technical bar for anyone wanting to attempt them. The government’s public response leaned hard on the size of the target. A government source told The Telegraph: “We have thresholds for important generators to legally notify us of cyber activity, and this site is nowhere near. It’s a very small-scale site, less than a rounding error compared to grid capacity.” A government spokesman said the UK has a strong and resilient energy system and that the incident never threatened the wider power network. While both statements are technically true, they do not answer a key question: should it be considered acceptable for even a small power plant to remain offline for four days? Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Iran-Linked Hackers)
Confirm this action.
Leaving now will discard your changes.