Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Vulnerabilities and Exploits. Show all posts

CISA Adds Actively Exploited WSO2 and Adobe Commerce Flaws to KEV Catalog

 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two critical vulnerabilities affecting WSO2 and Adobe Commerce to its Known Exploited Vulnerabilities (KEV) catalog, citing clear evidence of active exploitation. These flaws, tracked as CVE-2026-5430 and CVE-2026-71362, carry CVSS scores of 9.8 and 9.1 respectively, and pose severe risks to enterprises relying on these platforms for API management and e-commerce operations. 

CVE-2026-5430 is a path traversal vulnerability impacting WSO2 API Control Plane, API Manager, Traffic Manager, and Universal Gateway. It enables unauthenticated attackers to upload arbitrary files and achieve remote code execution without user interaction. Security firm watchTowr reported observing in-the-wild exploitation since at least September 13, 2026, including forged JWT tokens targeting the flaw. Yordan Ganchev, a principal threat intelligence specialist at watchTowr, emphasized that WSO2 serves nearly 1,000 customers across banking, government, telecom, and logistics—sectors that cannot afford delayed patching. 

The second flaw, CVE-2026-71362, affects Adobe Commerce and Magento through an incorrect authorization bug that allows attackers to hijack customer sessions and switch accounts without interaction. This grants unauthorized access to private customer data and sensitive resources. Dutch e-commerce security company Sansec detected and blocked exploitation attempts in August 2026, while Previdian telemetry recorded a lone Australian IP targeting honeypots on September 10, 2026. Although Adobe has not yet confirmed active exploitation in its advisory, the evidence strongly suggests coordinated abuse of this vulnerability. 

CISA’s inclusion of both flaws in the KEV catalog triggers mandatory remediation timelines for Federal Civilian Executive Branch (FCEB) agencies, which must apply patches by September 27, 2026. This deadline underscores the urgency for all organizations using WSO2 or Adobe Commerce to prioritize updates immediately. With threat actors already weaponizing these vulnerabilities, waiting for formal advisories or public proof-of-concept code could leave networks exposed to data theft, account takeover, and full system compromise. 

Organizations should audit their deployments of WSO2 and Adobe Commerce without delay, ensuring all systems are patched to the latest secure versions. For WSO2, this means updating API Manager and related components to close the path traversal vector. Adobe Commerce and Magento users must apply authorization fixes to prevent session hijacking. Given the high CVSS scores, broad industry usage, and confirmed exploitation, treating these vulnerabilities as critical priorities is essential to safeguarding digital infrastructure and customer data from escalating cyber threats.

Critical Roundcube Flaw Under Active Exploitation in Code Injection Attacks

 

A high-severity vulnerability in Roundcube Webmail, patched in May 2026, is now being actively exploited in code injection attacks, according to the Canadian Centre for Cyber Security. The flaw, tracked as CVE-2026-48842, allows unauthenticated attackers to bypass security controls and execute malicious database commands, putting millions of email users at risk. 

Roundcube is a browser-based IMAP email client used as the default mail interface by thousands of services and is pre-installed with the widely adopted cPanel web hosting control panel. The vulnerability resides in the virtuser_query plugin, which handles database-driven user lookups and maps users to email addresses. Successful exploitation enables threat actors with no privileges to inject and execute malicious SQL commands, steal data from Roundcube's database, and compromise email systems without requiring any user interaction. 

The Roundcube security team addressed this issue in May by releasing patches in versions 1.6.16 and 1.7.1, strongly recommending that administrators update their servers immediately. For those unable to upgrade right away, disabling or removing the virtuser_query plugin eliminates the attack vector and reduces exposure. Despite the availability of fixes, Shadowserver currently tracks over 523,000 Roundcube instances exposed on the Internet, though it remains unclear how many are honeypots or already patched against this flaw. 

This is not the first time Roundcube has been targeted by sophisticated threat actors. The Russian Winter Vivern (TA473) group exploited a cross-site scripting zero-day (CVE-2023-5631) against European government entities, while APT28 abused multiple Roundcube flaws to breach Ukrainian government email systems. More recently, in February 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) flagged two other Roundcube vulnerabilities as actively exploited, ordering federal agencies to secure their networks within three weeks. Since May 2022, CISA has tagged 11 Roundcube Webmail vulnerabilities as exploited in the wild, underscoring the platform's persistent appeal to cybercriminals and state-backed hackers. 

Organizations relying on Roundcube should prioritize patching to versions 1.6.16 or 1.7.1 without delay, as the window for safe operation has closed. Administrators who cannot upgrade immediately must disable the vulnerable virtuser_query plugin and monitor logs for suspicious database queries or unauthorized access attempts. Given the scale of exposed instances and the history of active exploitation, treating this flaw as a critical priority is essential to prevent data theft, credential harvesting, and broader compromise of email infrastructure.

OnePlus Android Devices Face Root Access Risk From Unpatched Flaws


Unpatched vulnerabilities in OnePlus software can allow a malicious Android application to gain root-level control of affected devices without requesting any special permissions. Security researcher Rasmus Moorats demonstrated the attack on a stock OnePlus 15 running the latest OxygenOS version, showing that an app installed on the device could escalate its privileges through two flaws in OnePlus-developed services. 

The vulnerabilities were found in AtlasService and olc2, two components that operate with elevated system privileges. OnePlus confirmed the issues in May and told Moorats that the flaws could affect additional OnePlus and OPPO devices, although no specific list of affected models has been released. As of the September 24 disclosure, the company had not published a security advisory, assigned CVE identifiers, or released a patch for the flaws. 

Two Flaws Form a Single Attack Chain

The first vulnerability affects AtlasService, a OnePlus service used for collecting debugging information. The service runs with root privileges and, according to the research, does not adequately verify which application is making a request. 

A specially crafted request can reach a debugging function that places attacker-controlled input into a system command. This allows a malicious application to execute commands with root privileges, although the initial access remains confined to the restricted dumpstate environment. The second vulnerability involves olc2, a hardware-related service that can execute shell commands. Its access control assumes that requests come from an already privileged process. 

Since the first flaw provides root execution within the restricted environment, the attacker can use that access to reach the second service. The resulting execution takes place in a less restricted system context, providing significantly broader Linux privileges. The research shows that the chain can ultimately allow kernel code to be loaded, moving the attack from application-level compromise to deep system control. 

No Special Permissions Required

The attack does not depend on a remote network connection. A malicious application must first be installed and running on the device, but the application does not need to request sensitive Android permissions or obtain an additional consent prompt. 

The demonstration was carried out on an unmodified OnePlus 15, indicating that the attack does not require an already rooted or specially configured device. Moorats also tested the chain against a OnePlus 12 Pro and expects the vulnerabilities to affect a wider range of devices running OxygenOS 16. 

OnePlus has indicated that the issues extend beyond its own devices to some OPPO products, reflecting the shared software components used across the two companies. However, the exact scope remains unclear because neither company has published an affected-device list. There is currently no evidence that the vulnerabilities have been exploited in real-world attacks. 

The immediate risk is tied to malicious applications being installed on affected devices, making application-source security an important defensive measure while a vendor fix remains unavailable.

Disclosure Followed Months of Vendor Coordination

Moorats reported the vulnerabilities to OnePlus on April 18, 2026. The company confirmed the issues on May 20 and said a fix was being prepared, while also asking the researcher not to disclose the technical details publicly. A further update arrived on June 22, when OnePlus requested additional time before disclosure. Moorats agreed to delay publication until September 17. 

Requests for further updates on July 20 and September 11 reportedly received no response. The technical details were eventually published on September 24, while the flaws remained unpatched. Until an official update becomes available, limiting application installations to trusted sources can reduce exposure to the attack path. A malicious application must be present on the device before the exploit chain can be triggered. 

Wider Impact Across OnePlus and OPPO Devices

The disclosure raises broader concerns because the affected components are part of the software layer added by the device manufacturer rather than stock Android. Mallory's analysis identifies the tested OnePlus 15 firmware as OxygenOS 16.0.3.503 and also records successful testing on the OnePlus 12 Pro. 

While OnePlus acknowledges that multiple products and software versions are vulnerable, it has not provided a comprehensive list of affected devices. There is also a significant connection between OnePlus and OPPO The two companies share software components, which means a flaw in an OEM service could affect more than just OnePlus smartphones. Information available does not establish the full impact of OPPO, however, and specific affected versions remain uncertain.

In the attack chain, two separate security weaknesses are exploited. AtlasService provides a path for untrusted applications to be able to communicate with privileged OnePlus processes, whereas the vendor component Olc2 allows another path for executing commands within privileged environments. These flaws allow initial restricted access to reach a much more powerful system environment through the use of their combined effects. 

OEM Software Remains a Key Android Attack Surface

OnePlus' disclosure follows another demonstration in which manufacturer-specific Android software was demonstrated in September. Security researcher Lukas Maar presented OEMPocalypse research, which demonstrated privilege-escalation chains against several major Android manufacturers, including OnePlus, Samsung, Xiaomi, OPPO, and Realme. This research involved a different technical approach, involving an OEM sandbox escape followed by a memory safety flaw in a vendor kernel driver. 

The overlap is in the attack surface: both cases depend on code added by smartphone manufacturers rather than a weakness in the core Android framework. In addition to hardware control and diagnostic functions, OEM components often require elevated privileges due to their device-specific features. 

As a result of these privileges, insufficient access checks are also particularly critical. The inclusion of a vulnerable service that accepts requests from ordinary applications can provide a path that circumvents Android's normal security controls. 

No Exploitation Reported So Far

The OnePlus flaws have not yet been exploited in the wild, according to information provided by OnePlus. Furthermore, the disclosed attack is not remotely exploitable, since a malicious application must already be installed on the device. Although the requirement is met, it does not eliminate the risk of an exploit. 

An application that is distributed through an unofficial store, a malicious APK, or another untrusted software channel may have the potential to provide an entry point for an exploit. A conventional permission-based screening method is less effective against this particular attack chain because the application does not require special Android permissions. 

Until OnePlus releases a security update, limiting application installations to trusted sources remains the primary practical precaution. Regular checks of OxygenOS updates are also relevant, since no public remediation timeline was available at the time of disclosure. 

Disclosure Raises Questions Over Patch Coordination

A vulnerability disclosure also emphasizes the extended coordination period between the researcher and OnePlus as a result of the issue being reported on April 18, OnePlus confirmed the issue in May, and provided a second fix status update in June. 

OnePlus argued during the disclosure process that vulnerability publication should remain within their control during the disclosure process. Publication ultimately took place on September 24 without a public patch. Although the researcher released their findings following the expiration of the agreed-upon disclosure period without any public remediation, no CVE identifier was assigned to the vulnerabilities as of publication, and no OnePlus advisory was publicly available describing the affected builds or recommending possible fixes. 

The absence of these details makes it difficult to determine the exact scope and makes the eventual security update particularly important for confirming which devices are affected. A similar case occurred in 2025 in which Rapid7 disclosed a separate OxygenOS vulnerability that could permit applications to access SMS data, adding to concerns about vulnerabilities in manufacturer-specific services rather than the core platform of Android.

F5 Fixes BIG-IP APM Zero-Day Enabling Unauthenticated RCE


BIG-IP Access Policy Manager (APM) vulnerabilities have been patched by F5 as a result of zero-day attacks utilizing this vulnerability, which allows unauthenticated attackers to execute code on the system. As a result of this flaw, CVE-2026-94127 affects BIG-IP deployments with APM configured as an OAuth Authorization Server. 

F5 disclosed the flaw on September 22 and assigned it a CVSS v3.1 score of 9.8. There is a vulnerability resulting from a heap-based buffer overflow that can be triggered by specially crafted traffic sent to a vulnerable virtual server. For the affected configuration to be effective, it is necessary to associate an APM access policy with an OAuth Authorization Server profile. 

The BIG-IP data plane can potentially be compromised without prior authentication due to malicious network traffic reaching it. A F5 spokesperson confirmed that systems running in Appliance mode are also affected. As the vulnerable traffic is directed towards the virtual server handling OAuth requests, the BIG-IP management interface is not restricted by restrictions. 

As of September 22nd, CISA added CVE-2026-94127 to its catalog of Known Exploited Vulnerabilities. This vulnerability does not affect deployments using APM solely as an OAuth Client or Resource Server. Civilian agencies were given a deadline of September 25 to apply the mitigations, while F5 has provided engineering hotfixes for BIG-IP branches that have been affected. 

F5 has not released any information on how many systems have been compromised or identified the threat actors behind the exploit. CISA's KEV entry, as well as the company's vulnerability record, do not include any information about which organizations were targeted for attack. 

F5 Releases Mitigation and Detection Guidance

F5 has released engineering hotfixes for the affected BIG-IP branches, whereas an iRule has been created as a temporary mitigation for systems that cannot be patched immediately. F5 Support provides the iRule as a temporary measure, intended to provide protection until a permanent fix has been deployed. In order to ensure a successful deployment of the vendor hotfix, CISA has advised applying the temporary measure during forensic checks. 

A number of indicators have been provided by F5 to assist in identifying possible exploitations. A repeated OAuth authentication failure, particularly one or more invalid token requests from the same IP in a short period of time, should be investigated further. An unpredicted increase in the total_failed OAuth statistic that correlates with other activity can serve as another indication. 

The security team should review /var/log/audit for suspicious commands which occurred at the same time as unusual OAuth activity. TMM core files and unexpected TMM terminations with the SIGABRT signal may also be relevant, since F5 observed that the vulnerable process entered a loop and crashed while performing malicious activity. All of these signs alone do not indicate exploitation, so the timing and combination of events are crucial when analyzing the situation.

It is essential that organizations that have BIG-IP APM systems that are interconnected with the internet preserve relevant logs and forensic evidence before undertaking major changes to potentially compromised appliances. Patching the system closes the vulnerable code path, but does not prove whether an attacker gained access to the system prior to remediation. 

At the time of this publication, F5 has not yet disclosed whether installing the hotfix removes access obtained in the past. As well, the vendor has not publicly identified the attackers or disclosed the number of systems affected. Watchtowr researchers published a technical analysis on September 24 of CVE-2026-94127, which adds more information to this vulnerability as exploitation continues. 

The affected BIG-IP APM configurations should be prioritized for F5 hotfix distribution, the recommended indicators of compromise should be reviewed, and systems should be investigated for signs of prior exploitation.

Arista Warns of Critical Actively Exploited VCO Vulnerability

 

Arista has published Security Advisory 0183 warning of a critical vulnerability in on-premises VeloCloud Orchestrator (VCO), tracked as CVE-2026-93952. The advisory, dated September 22, 2026, assigns the flaw a CVSS 3.1 base score of 10.0, indicating the highest level of severity. The issue is caused by improper input validation and is already being actively exploited, making immediate assessment and remediation essential for affected organisations. 

The vulnerability could allow a remote, unauthenticated attacker to access privileged internal functionality and compromise the VCO host. Successful exploitation may affect the confidentiality, integrity and availability of the orchestrator, including data managed by it. Arista said the issue affects on-premises VCO deployments, while hosted and dedicated VCO versions have already been patched. The affected software includes VCO 5.2.3.15 and earlier in the 5.2.x series, 6.1.3.7 and earlier in the 6.1.x series, 6.4.2.7 and earlier in the 6.4.x series, and 7.0.0.2 and earlier in the 7.0.x series. 

An affected deployment requires certificate-based authentication between a VeloCloud Edge and VCO, access to the public portion of the Edge authentication certificate, and network access to the VCO web interface. Tenant or operator credentials are not required. Organisations that limit the VCO web interface to trusted administrative networks can reduce exposure, although this should be treated as a temporary defensive measure rather than a complete solution. Arista’s EOS-based networking products and several other listed Arista platforms are not affected by this vulnerability. 

Administrators should inspect VCO web-access, backend application and system logs for unusual requests, encoded URL components, references to internal services or unusually high request rates. Other warning signs include unexpected outbound traffic, unauthorized configuration changes, unexplained maintenance actions, command execution, file creation, database exports or access to credentials and certificates. Arista specifically identified suspicious files, the x-vc-opt HTTP header and connections from 142.93.149.77 and 104.248.126.159 as indicators requiring investigation. 

Arista recommends upgrading to a remediated VCO release as soon as possible. Fixes are available in VCO 5.2.3.16 and later within the 5.2.3 train, and VCO 6.4.2.8 and later within the 6.4.2 train; fixes for other release trains will be added. Until then, organisations should restrict web access, monitor inbound and outbound activity, review administrator actions and watch for backdoors or webshells. If compromise is suspected, operators should preserve relevant logs and file timestamps before remediation, contact Arista TAC, rotate credentials, validate managed Edge devices and consider rebuilding the orchestrator from trusted sources.

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host


In OpenAI Codex, security researchers have identified two sandbox escape vulnerabilities, one of which allows developers to execute commands on their machine without prompting them. The vulnerabilities, Heapjack and Overpatch, affect different parts of the coding agent's security boundary. 

The vulnerability was reported to OpenAI by Accomplish AI on August 12. According to the researcher, Codex fixed both issues within eight days. The more serious Heapjack vulnerability demonstrated that malicious code could move beyond the restrictions imposed by Codex's sandbox, even when the agent was running as a read-only application. 

Heapjack Breaks the Sandbox Boundary

The node_repl component installed with Codex Desktop is targeted by heapjack. Although both OpenAI and untrusted agent code are run in separate JavaScript contexts, both operate within the same Node.js process and share the same memory heap, the separation was not sufficiently effective in preventing a security token from coming into contact with an untrusted environment. 

By inspecting the process heap, it was possible to obtain the token generated for the trusted context that remained in shared memory. When the token was obtained, the untrusted code could interact with a native parent process outside the sandbox using the communication channel used by the trusted context. As part of the demonstration of the technique, the researchers launched an application outside of Codex's process tree by utilizing the open command. 

A Unix socket as well as other system-level interfaces could also be reached through this access. This demonstration was especially important since it occurred while Codex was running in a strict read-only sandbox mode, where the agent was not expected to have any writing access to the wider system. 

The attack could be triggered by a seemingly routine development process. The researchers demonstrated a scenario in which malicious content contained in a repository, created by a third party, could exploit the vulnerability after the repository was opened in Codex and a query about its code was made. 

Overpatch Expands Write Access

Second, a vulnerability known as Overpatch affects the open-source Codex command line utility, and it takes an alternative route outside the sandbox. The vulnerability affects the application_patch tool used by Codex to modify files. 

In workspace-write mode, Codex is intended to limit file changes to the project directory. Researchers discovered that apply_patch, instead of expanding write permissions, could expand them based on paths included in patches. By using a path such as /tmp, the tool was able to treat the root of the file system as an accessible parent directory. In addition to the permission extension, researchers modified .zshrc by creating a symbolic link to the user's home directory so that it would be modified as well.

A successful write was not required for the /tmp entry; its presence extended the permissions granted to the patch operation. A modified shell configuration resulted in a file modification outside of the permitted workspace without an approval prompt. When a new terminal session was launched, attacker-controlled content ran. 

Two Flaws, One Security Boundary Problem

It is important to note that though Heapjack and Overpatch affect different parts of the Codex, both expose weaknesses in the way in which the security boundary of the agent was enforced. In the case of Overpatch, the tool responsible for applying changes also determined the scope from which it had access to data. 

In heapjack, trust boundaries were similarly compromised, as the token separating trusted and untrusted execution remained accessible in the same Node.js process and memory space as the untrusted code. The findings suggest that AI coding agents can be restricted in other ways than just controlling their abilities to execute commands. 

Untrusted agent activity must also be prevented from influencing the mechanisms that enforce those restrictions by the tools, processes and interfaces surrounding the model. On August 12, 2026, OpenAI was notified of the issues, and they were both addressed within eight days by Accomplish, who stated that Overpatch was addressed in Codex CLI 0.149.0, while Heapjack had been addressed in Codex Desktop build 26.818.21641.

A later statement by OpenAI confirmed that both issues had been resolved in August, and that additional measures were being taken to strengthen file-write controls and expand sandbox testing across platforms. These findings emphasize the security challenges associated with maintaining strong isolation in AI coding environments. Codex Desktop and Codex CLI have been updated to address both vulnerabilities.

Unauthenticated RCE Bug Fixed in SolarWinds Access Rights Manager

 

SolarWinds has issued an urgent security advisory for a high-severity vulnerability in its Access Rights Manager (ARM) product, tracked as CVE-2026-28326. The flaw enables unauthenticated attackers to execute arbitrary code remotely on affected systems, posing a serious risk to organizations using the identity and access governance platform. 

The vulnerability arises from a hardcoded static key embedded in SolarWinds Access Rights Manager 2026.2 and all earlier releases. Because the key is static and known, an attacker within adjacent network access can exploit it to bypass authentication entirely and run malicious code with high privileges. SolarWinds rates the issue 8.8 (High) under CVSS v3.1, reflecting severe impacts on confidentiality, integrity, and availability. 

Patch availability and upgrade path 

SolarWinds has released a fixed version, Access Rights Manager 2026.2.1, which removes the hardcoded key and mitigates the remote code execution risk. Customers are advised to upgrade immediately to 2026.2.1 or later. The advisory, first published on September 17, 2026, includes a downloadable PDF with technical details and recommends that administrators verify their current version and schedule emergency patching where ARM is deployed. 

Given the “unauthenticated” and “remote code execution” characteristics, this bug is especially dangerous in environments where ARM is exposed to internal networks or poorly segmented zones. An attacker who gains adjacent network access—such as via a compromised workstation or rogue device—could leverage the static key to take control of the ARM server, potentially escalating to broader identity management systems. The CVSS vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates low attack complexity and no need for user interaction, amplifying the urgency for remediation. 

Safety tips 

Organizations using SolarWinds Access Rights Manager should treat CVE-2026-28326 as a priority patching target. Immediate steps include: confirming the installed ARM version; isolating ARM servers from untrusted network segments; applying the 2026.2.1 update; and monitoring logs for suspicious authentication bypass attempts. Security teams should also review network access controls and consider threat-hunting activities focused on ARM-related processes. As with any identity management platform compromise, the downstream risk to Active Directory and other directories is significant, making rapid mitigation essential.

Unbound 1.26.1 Patches Critical RCE, DoS, and DNSSEC Flaws

 

A major security update has been issued for Unbound, the widely used validating DNS resolver developed by NLnet Labs. On September 16, 2026, the project disclosed a batch of high-severity vulnerabilities affecting versions up to and including 1.26.0, with fixes released in version 1.26.1. These flaws range from heap buffer overflows and use-after-free bugs to DNSSEC validation bypasses, any of which could allow attackers to crash servers or, in some cases, achieve remote code execution. 

RCE and denial-of-service risks 

Among the most serious issues is a heap buffer overflow in Unbound’s DNSSEC validator that can be triggered by a malicious DNSKEY record containing a self-referential compression pointer. This bug, credited to researchers from Nankai University, can lead to denial of service and potential remote code execution because the digest buffer overflows when processing such crafted records. Two additional memory-corruption bugs were also reported: one in DNSSEC canonicalization that affects long query names over TCP, and another in CNAME synthesis that can progressively corrupt heap memory and, under specific conditions, allow code execution. All three vulnerabilities are fixed in the 1.26.1 release, and manual patches are available for administrators who cannot immediately upgrade. 

Unbound’s support for encrypted DNS transports is also affected. A use-after-free bug in the DNS-over-QUIC (DoQ) implementation can be triggered by a malicious client that sends a RESET_STREAM and withholds ACKs, eventually causing the server to exit abnormally after as few as 20 queries. Similarly, a use-after-free in the DNS-over-HTTPS (DoH) cleanup path can be exploited when RPZ drops queries or under heavy traffic, potentially leading to process termination on hardened allocators. In addition, a degradation-of-service flaw in TCP/DoT handling allows an attacker to monopolize a worker’s event loop by streaming distinct uncached queries over a single connection, with no limit on consecutive reads. Fixes for these issues adjust stream shutdown behavior, correct DoH mesh accounting, and introduce read limits similar to those already used for UDP. 

Beyond memory safety, several logic errors undermine Unbound’s security guarantees. A ZONEMD verification bypass creates a window where tampered zone data can be served or written to disk before integrity checks complete, affecting zones below a trust anchor. A cross-zone cache-poisoning bug allows a malicious actor controlling one delegated zone under an NSEC-signed parent to inject insecure wildcard DS records for unrelated sibling domains, effectively forging delegations. Another flaw lets the “serve-expired” feature bypass the wait-limit counter introduced for the DNSBomb mitigation (CVE-2024-33655), enabling pulsing DoS amplification attacks from a single IP. The “ReTrap” family of algorithmic-complexity attacks (TagTrap, DelegationTrap, NsecTrap, AdditionalTrap) can also degrade service by forcing excessive DNSSEC validation work; Unbound 1.26.1 adds throttles and disables validation of the additional section by default to mitigate this. 

Role of administrators 

All users running Unbound 1.26.0 or earlier are urged to upgrade to version 1.26.1 as soon as possible, especially on internet-facing resolvers or those handling DNSSEC-validated traffic. If immediate upgrade is not feasible, NLnet Labs provides individual patches for each CVE that can be applied manually to the source tree. Operators should also review configurations for features like DNS-over-QUIC, DNS-over-HTTPS, DNSCrypt, response-ip/RPZ, and serve-expired, since several vulnerabilities require these options to be enabled. Given Unbound’s role in the DNS infrastructure of countless networks, prompt patching is critical to prevent outages and exploitation in the wild.

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.

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.

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.

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.

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.

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.

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.

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.