Australian police charged two men linked to TeamPCP over malware hidden in open-source code that stole 500,000+ credentials from 1,000+ organizations. Australian police have charged two men from Western Australia over a global cybercrime operation that allegedly hid malicious code in open-source software and used it to steal data from thousands of organisations. “Two West Australian men have been charged following a joint investigation between the AFP and Western Australia Police Force (WAPF), working in parallel with the Federal Bureau of Investigation (FBI), into a sophisticated cybercrime syndicate that allegedly created malicious open-source software to rob thousands of global businesses.” states AFP. “The AFP charged the men yesterday (26 August, 2026) with a combined total of 14 offences after executing search warrants in Perth with WAPF, and the assistance of the FBI.” The Australian Federal Police, the Western Australia Police Force and the FBI executed search warrants in Perth on 26 August 2026 and arrested a 21-year-old from Cottesloe and a 23-year-old from Mandurah. They face a combined total of 14 charges covering unauthorised data modification, possession and supply of data for computer offences, and dealing with proceeds of crime. Police say the pair were principal participants in a syndicate known as TeamPCP, which allegedly inserted malicious code into software hosted on public repositories and then let other developers pull it in without knowing. Infected components ended up in systems across government, academia and the private sector, giving the group a way to steal credentials and other sensitive material at scale. “Parallel investigations started in April, 2026, after the AFP and FBI received information from multiple cyber threat assessment companies regarding a syndicate that allegedly inserted malicious code into software available on an open-source repository, which was then unwittingly used by other developers.” continues AFP. “Police will allege infected software was then distributed into computer systems at other organisations across government, academia and the private sector. The software allegedly enabled the syndicate to infiltrate those organisations to steal or harvest sensitive data, including user credentials and authentication materials.” The numbers are not small. Investigators estimate the malicious code potentially compromised more than 1,000 organisations worldwide, enabling the theft of over 500,000 credentials and the exfiltration of at least 300 gigabytes of data. Remediation costs so far run into the hundreds of millions of dollars. TeamPCP is behind multiple supply chain attacks, in the past, they targeted PyPI packages and NPM repositories, and most recently the “Mini Shai-Hulud” campaign also caught two OpenAI employees. The pattern is consistent: go after the tools developers trust, poison the supply chain, and let the downstream damage multiply. The confirmed list of modified tools includes Trivy, a widely used container vulnerability scanner; KICS, a static analysis tool for infrastructure-as-code; LiteLLM, a popular library for routing requests across AI model APIs; and the Telnyx Python SDK. These aren’t niche utilities. They’re commonly integrated into enterprise CI/CD pipelines, cloud infrastructure workflows, and security scanning processes. Hitting them means hitting a large number of organizations simultaneously through a single poisoned update. The group also deployed four distinct malware families. CanisterWorm harvested cloud access tokens, credentials, and API keys for AWS, GCP, and Azure. SANDCLOCK extracted AWS credentials, Kubernetes ServiceAccount tokens, local environment variables, and cryptocurrency wallet data. Mini Shai-Hulud was a self-replicating worm designed to spread across both npm and PyPI registries. Miasma was a variant of Mini Shai-Hulud that propagated across those same open-source registries while harvesting credentials and poisoning configuration files. The worm component is the part that deserves particular attention. Mini Shai-Hulud and its Miasma variant didn’t just infect the initial target and stop. They spread across open-source package registries autonomously, harvesting credentials and poisoning configuration files as they went. The FBI confirmed two GitHub repository names used for exfiltration: tpcp-docs and docs-tpcp. If either of those repository names appears in your GitHub organization, the worm created it using stolen credentials. TeamPCP’s method was straightforward and effective: inject malicious code into legitimate software packages, push the trojanized versions through normal distribution channels, and wait for CI/CD pipelines to pull them in automatically. The modified tools installed credential-stealing malware and persistent backdoors without any visible sign that anything had changed. “These men are allegedly members of the cybercriminal group TeamPCP, whose malicious code potentially compromised more than a thousand organizations worldwide,” Assistant Director Leatherman said. “We are proud to work with the Australian Federal Police and the Western Australia Police Force to impose cost on criminal actors and combat the growing threat of software supply-chain attacks.” The charges show how serious the alleged operation was. The 21-year-old faces several charges, including changing data without authorization, possessing and supplying data for computer crimes, failing to comply with a production order, and handling at least A$100,000 in criminal proceeds. The 23-year-old faces similar hacking charges, with maximum penalties ranging from three to 20 years. Police seized electronic devices and other items from properties in Cottesloe, Hamilton Hill and Mandurah. Investigators are now examining a large amount of data and have not ruled out further arrests or charges. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Australian authorities have arrested and charged two young men accused of being part of the TeamPCP hacking group linked to a string of far-reaching developer supply chain attacks. TeamPCP is a hacking group known for widespread supply-chain attacks over the past year that targeted open-source software and developer platforms to steal credentials, authentication secrets, and source code. High-profile attacks attributed to TeamPCP have impacted Trivy, LiteLLM, Telnyx, SAP, and TanStack packages, while the group has also breached the European Commission, Mistral AI, OpenAI, and GitHub. To carry out their attacks, the threat actors injected malicious code into software hosted on open-source repositories, which developers then unknowingly incorporated into their own applications on systems used by government, academic, and private-sector organizations.
Google Workspace breaches can begin with social engineering or forgotten third-party integrations rather than sophisticated exploits. This webinar examines real-world breaches, what happens during the critical first hours, and the security controls that can make the greatest difference.
The ShinyHunters extortion group has published sensitive data from nearly 13 million accounts stolen from clothing retailer giant Carhartt earlier this month, according to data breach notification service Have I Been Pwned. Founded in 1889, Carhartt is an American apparel company with workwear and streetwear manufacturing facilities in Kentucky and Tennessee and more than 3,000 employees in the United States and Europe. While Carhartt has yet to confirm the extortion group's claims or issue a statement about the breach, ShinyHunters claimed the attack on August 13 and said they allegedly stole more than 50GB of documents containing a wide range of customer, employee, and corporate data. "Millions of records of customer data and vast amount of sensitive information and PII containing employee, customer, customer metadata (royalty info), and other internal corporate data was compromised," the cybercrime gang said.
CISA urges water utilities to find and secure internet-exposed PLCs after July attacks showed how easily exposed industrial systems can be compromised. Over 100 internet-exposed systems in the US water and wastewater sector got hit by cyberattacks in July 2026, and CISA’s response wasn’t just an incident report, it was a how-to guide for making sure it doesn’t happen to you next. The agency’s exposure reduction guidance, published August 21, walks through exactly how organizations can find their own internet-facing weak points before an attacker does. The pattern behind the July attacks was surprisingly simple. Most of the affected systems were programmable logic controllers (PLCs), small industrial computers that control pumps and valves. Many connected directly to cellular modems and had no firewall or gateway between them and the internet. CISA warns that this type of setup can expose PLCs to serious security risks. “Directly connecting PLCs to the internet through cellular modems can create significant security risks. However, internet exposure reduction does not mean disabling necessary remote access; organizations should remove remote access when it is unnecessary and secure it when it is necessary.” states CISA. Hackers remotely accessed exposed PLCs, changed device IP addresses and passwords, and in some cases disabled shutdown processes and alarms, creating what CISA called unsafe conditions without notifying the operators running the actual equipment. Iran is the suspected actor behind much of this activity, likely tied to the ongoing war involving the US and Israel, though officials have stopped short of a formal attribution. CISA presents reconnaissance as an ongoing process. Organizations need to know which systems they expose to the internet and can use tools such as Shodan, Censys, or CISA’s Cyber Hygiene Vulnerability Scanning service to check their own IP ranges from the outside. The review should also cover ports used by industrial systems. Besides SSH, RDP, and HTTP, CISA highlights protocols such as Modbus, EtherNet/IP, DNP3, BACnet, and OPC UA. Finding one of these ports open does not automatically mean the system has been compromised, but it does indicate an exposure that needs to be investigated and addressed quickly. Where remote access is genuinely necessary, CISA’s advice is to route everything through a secure, centrally managed gateway rather than connecting straight to a PLC, HMI, or remote terminal unit. Pair that with phishing-resistant multi-factor authentication, unique credentials instead of shared defaults, and active monitoring of traffic in and out, and you’ve closed most of the gap that let this particular wave of attacks succeed in the first place. None of this is exotic security engineering; it’s the same basic hygiene that’s been recommended for years, just finally getting attention because attackers are actually using the gap. This isn’t an isolated incident CISA is responding to reactively, either. The water sector attacks sit inside a much larger pattern of nation-state interest in US and allied critical infrastructure, from China’s Volt Typhoon reportedly pre-positioning malware inside American infrastructure as a potential wartime disruption tool, to Russian-linked campaigns testing water and energy systems across Europe as part of broader pressure on NATO. If a foreign government is willing to spend years quietly waiting inside a power grid, an exposed PLC with a factory-default password isn’t a minor oversight, it’s an open invitation. “CISA urges all critical infrastructure organizations to route all necessary remote access through a secure gateway, firewall, VPN, or other centrally managed access solution, rather than connecting directly to a PLC, human-machine interface (HMI), or remote terminal unit (RTU).” concludes CISA. “The July 2026 malicious cyber activity targeting WWS Sector entities demonstrates the consequences of directly exposing PLCs to the internet. Threat actors remotely accessed internet-exposed PLCs, changed device IP addresses and passwords, and caused loss of monitoring and control functionality and, in some cases, operational disruptions.” If you run anything with the letters PLC, SCADA, ICS, or HMI in its job description, this guidance isn’t optional reading for next quarter. Go run the scan today, because the alternative is finding out the hard way that someone else already ran it for you. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Water Utilities)
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)
WhatsApp says 1 billion users now use passkeys, while stronger two-step verification and caller context add new layers of account protection. WhatsApp has reached a significant security milestone: more than one billion people now use passkeys to protect access to their accounts. At the same time, Meta is adding stronger two-step verification and more information about calls from people who aren’t in a user’s contacts. Passkeys let users sign back into WhatsApp with a fingerprint, Face ID or their device’s screen-lock code instead of relying on passwords, PINs or one-time codes. WhatsApp now also allows people who use both Android and iOS devices to add more than one passkey to the same account, which removes one of the practical limitations of the earlier implementation. “More than 1 billion people now use a passkey: A passkey lets you log back into WhatsApp with your fingerprint, face ID, or screen lock code. It’s the fastest and most secure way to verify it’s really you, with no codes or PINs.” reads the announcement published by WhatsApp. “More than a billion people have already set one up, and you can now add more than one passkey to your account if you use both Android and iOS devices. To get started, go to Settings > Account > Passkeys.” For people who move between platforms, the ability to register multiple passkeys should make account recovery less dependent on a single device. It is important to highlight that WhatsApp is moving account protection away from secrets that users have to remember or type. Passkeys rely on credentials stored on the device and protected by its existing biometric or screen-lock mechanism, which also makes phishing them much harder than a traditional password or verification code. WhatsApp is also changing its two-step verification system. Until now, the additional protection relied on a six-digit PIN. The company has now upgraded it to a full password that can be longer, use letters and numbers, and include special characters. “Two-step verification is an extra protection layer that helps prevent someone from taking over your account, even if they get hold of your one-time passcode.” continues the announcement. “Until now it was a six-digit PIN, we’ve now upgraded it to a full password: longer, alphanumeric, and even with special ch@racters to make it harder to guess. If you’ve been using “123456,” this is your sign to upgrade.” That’s a small interface change with a meaningful security consequence. A short numeric PIN has a limited number of possible combinations and encourages users to choose predictable values, while a longer password gives account owners a much stronger second factor. WhatsApp makes the point in unusually direct terms, even calling out the classic 123456 choice. If that’s still protecting an account, the app has just provided a fairly unambiguous hint. The change also addresses a specific account-takeover scenario. If an attacker manages to obtain a user’s one-time registration code, the additional password can still prevent the takeover from succeeding. The third change targets a different problem: social engineering. On Android, WhatsApp will now provide additional context when someone outside the user’s contacts calls. The information can include whether the number comes from another country and whether the caller shares any groups with the recipient. That gives users a little more information before they decide whether to answer. “When you get a call from someone not saved in your contacts, a little context can help you decide whether to pick up. On Android, you’ll now see more information about a non-contact caller, like whether the number is from a different country and if you have any groups in common.” concludes the announcement. “Scammers rely on urgency – now you can take a beat with some more info before answering.” It’s a simple addition, but it addresses a common weakness in fraud attempts: pressure. An unexpected call creates a sense of urgency, and attackers often use that moment to persuade someone to disclose information, click a link or continue the conversation on their terms. Giving the recipient more context doesn’t stop a scammer from calling. It gives the user a reason to pause before answering. Taken together, the three changes target different parts of the same account-security problem. Passkeys make authentication harder to steal, stronger two-step verification provides another barrier when a one-time code is compromised, and caller context gives users more information before a potentially suspicious interaction begins. The billion-user passkey figure is also worth watching beyond WhatsApp. It suggests that phishing-resistant authentication is no longer an experimental security feature limited to security-conscious users. At this scale, the challenge shifts from convincing people that passkeys are safer to making sure they understand when and how to use them. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, WhatsApp)
Confirm this action.
Leaving now will discard your changes.