On June 10th Oracle released a security advisory impacting the Environment Management component within Oracle’s PeopleSoft application. The vulnerability, now publicly tracked as CVE-2026-35273, has been reportedly actively exploited as early as May 27th 2026.
Threat actors associated with Shiny Hunters have reportedly leveraged this vulnerability in a campaign targeting over 100 organizations worldwide. The vulnerability is remotely exploitable without authentication with potential to achieve remote code execution on exposed Oracle PeopleSoft instances.
Oracle released security updates to address the vulnerability on June 10th, but provided limited technical details at the time of disclosure. No public proof-of-concept exploit code has been released at the time of this writing.
Given the sensitive business and personnel data commonly stored within PeopleSoft environments and reports of active exploitation by a prolific threat actor, Beazley Security strongly recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Product | Affected Versions |
PeopleSoft Enterprise PeopleTools | 8.61, 8.62 |
No official mitigations or workarounds aside from the software updates were publicly provided by Oracle at the time of disclosure. However, GTIC published a detailed report on the attacker infrastructure used by ShinyHunters for their campaign leveraging this CVE, and helpfully included the following hardening recommendations:
Disable the Environment Management Hub (EMHub) Service in Multi-Server configurations or completely remove the PSEMHUB application in Single-Server configurations, as advised by Oracle's security alert guidance.
If you cannot disable the EMHub Service, block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the network perimeter or firewall level.
Official security fixes were made available by Oracle here. Users must have an account to access the patches and documentation.
Active exploitation of this vulnerability has been confirmed in the wild. Mandiant and Google Threat intelligence Group (GTIG) identified an active campaign attributed to ShinyHunters with activity predating Oracle’s June 10th advisory and released the following indicators of compromise:
IP Address | Role |
142.11.200.186 | Staging / C2 |
142.11.200.187 | Staging / C2 |
142.11.200.188 | Staging / C2 |
142.11.200.189 | Staging / C2 |
142.11.200.190 | Staging / C2 |
azurenetfiles.net | C2 Domain |
176.120.22.24 | ShinyHunters DLS Mirror |
Payloads & Files:
File Name | Description | SHA-256 |
.bash_history | Attacker command history | 2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35 |
meshagent64-azure-ops.exe | Pre-configured Windows agent | f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc |
meshagent64-v2.exe | Pre-configured Windows agent | d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f |
meshagent32-azure-ops.exe | Pre-configured Windows agent | c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f |
meshagent | Unconfigured Linux agent | 68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309 |
Dropped Filenames:
File Name |
README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT |
[victim_abbreviation]_fanout.sh |
As previously noted, Oracle has not released technical details regarding this vulnerability, and no public proof-of-concept exploits are currently available. However, a threat report published by GITC includes indicators associated with the exploitation of CVE-2026-35273.
According to the report, observed activity targeted PeopleSoft Environment Management Hub (PSEMHUB) components through malicious HTTP POST requests directedat the /PSEMHUB/hub and /PSIGW/HttpListeningConnector endpoints.
GITC also observed post exploitation activity resulting in suspicious .jsp files within /webserv/applications/peoplesoft/PSEMHUB.war/, and unexpectedfiles or directories within the /PSEMHUB.war/envmetadata/transactions/, logs, persistantstorage, or scratchpad in PSEMHUB paths.
The combination of suspicious HTTP POST traffic followed by the presence of unexpected files suggests the vulnerability may enable unauthenticated file uploads, arbitrary file write, up to remote command execution capabilities. At the time of writing, the exact root cause and exploitation mechanism remain unconfirmed.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On June 9th, Ivanti published two advisories concerning four vulnerabilities (tracked as CVE-2026-6973, CVE-2026-10727, CVE-2026-10520, CVE-2026-10523) in their Endpoint Manager Mobile (EPMM) and Ivanti Sentry products. The vulnerabilities range from authentication bypass and control plane modification to complete remote code execution (RCE) across the product lines. Detailed descriptions of the specific CVEs are listed in the Affected Systems and Products below.
As of the time of writing, technical details of the vulnerabilities are limited. However, Ivanti has released patches and updates to EPMM and Sentry documented in the Patches section below. Ivanti has stated that it has not observed attacks in the wild leveraging these vulnerabilities. However, KEV has already identified CVE-2026-6973 as being actively exploited in the wild. Beazley Security expects threat actors who are not already in possession of private weaponized exploits to study these patches and deploy their own exploits in the coming days. Beazley Security strongly recommends affected organizations apply the vendor supplied security fixes as soon as possible.
Product | Affected Version | Fixed Version |
|---|---|---|
Ivanti Endpoint Manager Mobile (EPMM) | 12.9.0 and prior 12.8.0.2 and prior 12.7.0.1 and prior | 12.9.0.1 12.8.0.3 12.7.0.2 |
Ivanti Sentry | 10.7.0 and prior 10.6.1 and prior 10.5.1 and prior | 10.7.1 10.6.2 10.5.1 |
CVE Number | Product Line | Description | CVSS Vector & Base Score |
|---|---|---|---|
CVE-2026-6973 | EPMM | A configuration control vulnerability that allows an authenticated attacker to inject arbitrary Apache directives that enable RCE | CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Base Score: 7.2 |
CVE-2026-10727 | EPMM | An OS command injection vulnerability that allows an authenticated attacker to execute arbitrary commands as root | CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Base Score: 7.2 |
CVE-2026-10520 | Sentry | An OS command injection that allows a remote unauthenticated user to achieve RCE as root | CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Base Score: 10 |
CVE-2026-10523 | Sentry | An authentication bypass vulnerability that allows a remote unauthenticated user to create administrative accounts and obtain full administrative access to the Sentry Instance | CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Base Score: 9.9 |
No mitigations or workarounds aside from the available security patches have been provided from Ivanti.
Ivanti provided software patches at the time of disclosure for the affected versions listed above. The patches are in RPM package format for upgrades and require authenticated access to the Ivanti Download Portal. Short instructions for where to get the patches and how to install the patch packages can be found in the advisories for EPMM and Sentry.
At the time of the disclosure, no in-depth technical details were provided by Ivanti; however, given the nature of the exploits resulting in administrative access to the host machine, any logs that could be used to identify a compromised host may be altered or removed. It is for this reason that timely updates to the affected systems are applied before these vulnerabilities are weaponized and used in the wild.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On June 8th 2026, Check Point Research identified two CVEs (CVE-2026-50751, CVE-2026-50752) which can be abused to bypass Checkpoint VPN Authentication services, allowing threat actors to access network devices and traffic behind the VPN. These vulnerabilities were found under active exploitation in the wild by attackers that Check Point research attributed with medium confidence to be Qilin ransomware affiliates.
This vulnerability affects Check Point Remote Access VPN, and Mobile Access endpoints that are configured to use IKEv1 for their key exchange. At the time of writing, the control plane is unaffected by attackers who have exploited this vulnerability, however resources behind the VPN would be accessible to attackers who successfully exploit the vulnerability.
Product | Affected Version | Fixed Version |
|---|---|---|
Mobile Access / SSL VPN, Remote Access VPN, Spark Firewall | R80.20.X (EOS), R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.10.X, R81.20, R82, R82.00.X, R82.10 | sk185033 |
Security Gateways, Spark Firewall | R80.20.X (EOS), R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.10.X, R81.20, R82, R82.00.X, R82.10 | sk185035 |
A given device will be affected if the following configurations are applied:
VPN Remote Access or Mobile Access is enabled
VPN site-to-site is enabled
IKEv1 is enabled for remote access
Gateways accept legacy Remote Access clients
Gateways do not demand a machine certificate for connections
Gateways participating in the VPN community use certificate-based authentication
Pre-shared key authentication remains unaffected
Gateways are not dynamic
The community is not a Large Scale VPN (LSV) community.
It should be noted that IKEv1 is deprecated.
Active exploitation has been confirmed in the wild, and Check Point has released hotfixes for the two vulnerabilities, sk185003 and sk185035. Affected organizations should apply these patches as soon as possible.
If applying the hotfix is not an immediate option, Check Point Research has advised disabling the IKEv1 for all Check Point Security Gateways and Remote Access communities, which is possible within the Check Point SmartConsole under VPN Community, Encryption > General > Encryption Method and ensuring IKEv2 is the only accepted key exchange.
Doubly so, Check Point also advises that users remove support for legacy Remote Access client connections for Check Point VPNs by accessing the Check Point SmartConsole and opening the Security Gateway object properties, selecting VPN Clients > Authentication, and unchecking the “Allow older clients to connect to this gateway" on any affected devices.
Finally, Check Point also recommends configuring mandatory certificate authentication also in the SmartConsole, under Security Gateway properties. Once there, selecting VPN Clients > Authentication, and selecting Mandatory under Machine Certificate Authentication.
Check Point recommends updating all affected Security Gateways to the released subsequent hotfix. They offer hotfixes for versions R81.20, R82, and R82.10. The hotfix versions are as follows:
Hotfix Version Numbers |
|---|
R82.10 Jumbo Hotfix Accumulator Take 19 |
R82.10 Jumbo Hotfix Accumulator Take 6 |
R82 Jumbo Hotfix Accumulator Take 103 |
R82 Jumbo Hotfix Accumulator Take 91 |
R81.20 Jumbo Hotfix Accumulator Take 141 |
R81.20 Jumbo Hotfix Accumulator Take 127 |
R81.20 Jumbo Hotfix Accumulator Take 120 |
R81.20 Jumbo Hotfix Accumulator Take 113 |
Check Point Research has medium confidence that the attacker is affiliated with Qilin as they use the Qilin ransomware toolkit. Qilin is financially motivated and may be exploiting other VPN vulnerabilities, including the ones published recently by Palo Alto, Fortinet, and F5. Check Point Research reported the use of TOX Protocol for communications. They also found that the actor was using a dedicated VPS to orchestrate the attacks, finding that the IPs led back to Kaupo Cloud HK, Shock Hosting, and Vultr Holdings. The following IoCs are associated with Qilin Linux Ransomware Binaries, and the servers from which the TA tried to download malicious second stage payloads from:
IP Addresses |
|---|
45.77.149[.]152 |
209.182.225[.]136 |
38.60.157[.]139 |
162.33.177[.]101 |
45.76.26[.]42 |
144.208.127[.]155 |
38.54.88[.]201 |
38.54.107[.]167 |
66.42.99[.]200 |
File Hashes |
|---|
52fda5c1b9704544f32ee98d9060e689 |
51d39aa39478beeac94f2d12f682ecce |
No in-depth technical details or public proof of concept exploit code samples were available at time of writing. Official documentation from Checkpoint describes the root flaw as a “logic flow weakness in the Remote Access and Mobile Access certificate validation.”
It should be noted that the vulnerability would grant threat actors network access to VPN connected resources, and that follow-up exploitation would vary greatly on what a given organization has internally connected to the VPN.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
Update May 20th, 2026: Drupal recently updated their security advisory with additional technical details and an official CVE to reference a critical vulnerability in Drupal Core. Tracked as CVE-2026-9082, the flaw is due to an SQL injection vulnerability that can be reached through Drupal Core’s database extraction API and only affects deployments using PostgreSQL databases.
Successful exploitation of the flaw can lead to sensitive information disclosure, privilege escalation, and up to remote code execution on certain configurations. Relevant sections of this advisory have been updated accordingly.
While the critical SQL injection vulnerability itself is limited to PostgreSQL-backend environments, the released updates include additional upstream security fixes and Drupal recommends applying across all deployment types.
On May 18th, the Drupal Security team disclosed a highly critical vulnerability currently tracked by the vendor as PSA-2026-05-18, affecting supported branches of Drupal core.
The flaw requires no authentication or special access conditions to exploit, allowing unauthenticated attackers with network access potential to weaponize exploits on affected installations. End of support versions of Drupal Core 8 and 9 have been provided emergency patches due to the severity of this flaw, however, must be applied manually. Please see the Affected Systems and Products section of this advisory for more information.
Drupal security teams believe that exploits have potential to be developed within hours or days of disclosure. Given the critical severity of this vulnerability and the potential for exploitation, Beazley Security strongly recommends all organizations running affected versions patch immediately.
Affected Versions | Fixed / Patch Available |
Drupal Core 11.3.x | Drupal 11.3.10 |
Drupal Core 11.2.x | Drupal 11.2.12 |
Drupal Core 11.1.x, 11.0.x | Drupal 11.1.10 |
Drupal Core 10.6.x | Drupal 10.6.9 |
Drupal Core 10.5.x | Drupal 10.5.10 |
Drupal Core 10.4.x or earlier | Drupal 10.4.10 |
Drupal Core 9.5.x | |
Drupal Core 8.9.x | |
Drupal Core 7.x | Not affected |
Note: Major versions of Drupal 8 and 9 are considered end of life by the vendor and official branch releases will not be created. However given the severity of the issue, the vendor is providing emergency patches for Drupal 8.9 and 9.5 that must be applied manually. The vendor also advises they are not guaranteed to work correctly. Upgrading to supported versions is strongly encouraged.
Given advanced disclosure and criticality of this vulnerability, patching is strongly encouraged. Drupal has released emergency patches to remediate the flaws in Drupal Core, please see the “patches” section for more information.
If patching cannot be immediately applied, the following mitigations may temporarily reduce the risk of exposure:
Sites running Drupal Steward have received advanced signature protection against known attack vectors from Drupal, however Steward customers are strongly encouraged to still apply upstream patching in event additional exploit methods are identified post publication.
If possible, restrict public network access or consider temporarily isolation of affected Drupal Core implementations until patches can be applied
Updated branches have been made available by Drupal’s security team for supported versions as indicated in the “Affected Systems and Products” table above. Releases for Drupal core can be found from their official releases site. Vulnerability updates for Drupal products are available at drupal.org/security.
As of May 20th, Drupal released additional technical details and publicly assigned CVE-2026-9082 to this flaw. The vulnerability exists within Drupal Core’s database abstraction API, which functionality exists to prevent direct database access and sanitize queries.
According to the updated advisory, a remote, unauthenticated attacker can send specially crafted requests to the API endpoint that could result in arbitrary SQL injection against affected PostgreSQL-backed deployments. Successful exploitation allows attackers to dump sensitive database information, and depending on configuration, achieve privilege escalation up to remote code execution.
While CVE-2026-9082 only affects Drupal systems using PostgreSQL, the company noted that there are other fixes in this security update that fix flaws that were found in related software products Symfony and Twig. If affected organizations do not use PostgreSQL but use either of these modules, they should still apply the provided updates.
Prior to official disclosure Drupal security teams warned that exploit development could occur rapidly following public release of the technical details, signaling the vulnerability may be trivial to exploit. Given the critical severity of this vulnerability and enhanced potential for exploitation, Beazley Security expects attackers will soon weaponize the flaw and recommend affected organizations patch immediately.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
06/05/2026 Update: Cisco has issued an update to their initial post identifying several more CVEs that affect Cisco Catalyst SD-WAN and Manager systems (CVE-2026-20187). This vulnerability has been seen exploited in the wild in conjunction with the previously disclosed vulnerability. The CVE initially released with a High severity, but can be leveraged with CVE-2026-20182 to gain or persist access to the edge-facing management plane. This vulnerability requires access to an authenticated user with netadmin privileges. Updates that resolve this specific issue have not been released at the time of writing, but due to the concern of chaining exploits, Beazley Security recommends applying the patches below for affected devices.
On May 14th, Cisco published an advisory detailing a critical authentication bypass vulnerability affecting Cisco Catalyst SD-WAN controller infrastructure. The vulnerability, tracked as CVE-2026-20182, is a peering authentication bypass between SD-WAN infrastructure components and is similar to a vulnerability discovered 3 months prior.
Active exploitation has been confirmed in the wild, and CISA has added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog. Line the vulnerability reported in late February, this flaw allows an unauthenticated attacker the ability to bypass authentication and create a rogue peer to a victim’s SD-WAN controller. Through creating a rogue peer, an attacker can advance to gain high privileged access into the ecosystem and manipulate configurations via NETCONF.
Beazley Security recommends that affected organizations check for signs of compromise, and upgrade to fixed versions of SD-WAN software immediately.
Cisco Catalyst SD-WAN Version | Affected Version | Fixed Version |
|---|---|---|
20.9 | < 20.9.9.1 | |
20.12 | < 20.12.5.4 < 20.12.6.2 < 20.12.7.1 | |
20.15 | < 20.15.4.4 < 20.15.5.2 | |
20.16, 20.17, 20.18 | < 20.18.2.2 |
Please note that 20.10, 20.11, 20.13, 20.15, and 20.16 are EOL, and affected clients are recommended to upgrade to a supported release.
Cisco has released software updates addressing CVE-2026-20182 and applying the vendor provided patches is the recommended course of action to reduce risk.
Beyond patching, organizations should consider reviewing Cisco’s SD-WAN hardening guide including steps to:
Inventory and audit expected peer networks within SD-WAN infrastructure
Reduce internet exposure by locking SD-WAN controller peering services down to known and authorized peer networks.
Restrict access to SD-WAN controller and management planes to a dedicated administrative network
Affected organizations that are unable to immediately patch should ensure strict network access controls are in place around SD-WAN controllers and check audit logs for any signs of compromise.
At the time of writing, Cisco has released fixes for all supported versions of their Catalyst SD-Wan solutions. Please see the Affected System and Products section above in this report for additional information on affected versions and fixes.
Cisco has produced a remediation guide that includes links to fixed software for the identified vulnerabilities. The vendor also hosts a software download center requiring login.
Alternatively, customers can contact Cisco’s Technical Assistance Center (TAC) to request additional response and software upgrade support.
06/05/2026 Update: Cisco Talos has indicated users with exposed systems should monitor their /var/log/scripts.log file for additions and updates to the Tenant list with the following example:
Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0
Noting that these logs are often legitimate commands, and the onus is on the maintainers to discern between legitimate usage of the script and malicious use modifying the tenant list. Cisco Talos is tracking this campaign through an official threat advisory and are attributing attacks to threat actor UAT-8616, describing the group as a “highly sophisticated cyber threat actor”. The same group is believed to be responsible for peering attacks performed against CVE-2026-20127 in February. Beazley Security recommends affected organizations review the Talos threat advisory for continuous updates regarding in the wild exploitation and observed IoCs in the community.
Cisco also released a remediation guide containing upgrade instructions and verification checks, importantly including the below command to search /var/log vsyslog* (exampled), messages*, and vdebug* files for unauthorized peers:
awk '{
match($0, /peer-type:([a-zA-Z0-9]+)[^ ]* peer-system-ip:([0-9.:]+)/, arr);
if(arr[1] && arr[2]) print "(" arr[1] ", " arr[2] ")";
}' vsyslog* | sort | uniq
Cisco’s remediation guide contains other helpful hunting tips and verification checks and can be accessed at this link.
CVE-2026-20182 was found by Rapid7 while they were studying CVE-2026-20127. Both vulnerabilities affect the same “vdaemon” service.
The Rapid7 analysis article is meticulously detailed and deserves a read-through, however we will summarize high level details of the flaw below. The specific section of code where the bug is located assists with peer certificate validation for SD-WAN implementations. Within the code exists function logic for explicitly noted pairing combos (i.e. vSmart-to-vSmart or vManage-to-vSmart) but critically, the function:
has no defined logic or authentication checks if the remote device claims it is a vHub, and
the function does not “fail closed”
This means all a threat actor needs to do is initiate a peering session with the target and masquerade as a vHub. The bug will cause the targeted appliance to skip verifying certificates for the incoming request and log the attacker-controlled device as a legitimate peer.
A device peer has a lot of power within Cisco’s SD-WAN fabric, and Rapid7 included details on how to inject an attacker-controlled SSH key onto compromised devices.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
06/05/2026 Update: The newly disclosed CVEs are listed below with their associated CVE scores and details:
Cisco: Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability
Rapid7: CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED)
Talos: Ongoing exploitation of Cisco Catalyst SD-WAN vulnerabilities
CISA KEV: Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability
Cisco: Remediate Catalyst SD-WAN Security Advisory - May 2026
Cisco Catalyst SD-WAN Manager Authenticated Privilege Escalation Vulnerability
05/26/26 Update: On May 22nd, F5 published another advisory for an additional but different vulnerability found in the same ‘ngx_http_rewrite_module’ system. The new vulnerability (tracked as CVE-2026-9256) can allow an unauthenticated attacker to corrupt system memory and potentially achieve RCE. Discovery of the bug was credited to various research groups, and there were no reports of active exploitation in the wild at time of writing.
On May 13th, 2026, F5 released an advisory regarding a flaw that under specific non-default conditions, could allow unauthenticated remote code execution (RCE) in NGINX Open Source and NGINX Plus. Tracked as CVE-2026-42945 and nicknamed “NGINX Rift”, the vulnerability stems from a heap buffer overflow in the ‘ngx_http_rewrite_module’ that has been present in the codebase since 2008.
Beyond potential for remote code execution, the flaw can also be exploited to cause a Denial of Service (DoS) condition and is easily weaponized due to its lower complexity to trigger. A public proof of concept (POC) exploit was released with the disclosure.
Due to the widespread usage of NGINX across the internet and the lower effort DoS attack vector, the vulnerability is likely to be targeted by opportunistic threat actors. Beazley Security recommends patching to a fixed version of NGINX to reduce risk of service disruption or exploitation.
Product | Affected Version | Fixed Version |
|---|---|---|
NGINX Open Source | 0.6.27 through 1.30.1 | 1.30.2 / 1.31.1 |
NGINX Plus | R32 through R36 | R32 P7 / R36 P5 / 37.0.1.1 |
NGINX Instance Manager | 2.16.0 through 2.22.0 | Fixed by NGINX Open Source update |
F5 WAF for NGINX | 5.9.0 through 5.13.0 | Fixed by NGINX Plus update |
NGINX App Protect WAF | 4.9.0 through 4.16.0 & 5.1.0 through 5.8.0 | Fixed by NGINX Plus update |
NGINX App Protect DoS | 4.3.0 through 4.7.0 | Fixed by NGINX Plus update |
NGINX Gateway Fabric | 1.3.0 through 1.6.2 & 2.0.0 through 2.6.1 | Fixed by NGINX Plus and Open Source updates |
NGINX Ingress Controller | 3.5.0 through 3.7.2 & 4.0.0 through 4.0.1 & 5.0.0 through 5.4.2 | Fixed by NGINX Plus and Open Source updates |
05/26/26 Update: The table above has been updated to cover patching for both CVE-2026-42945 and CVE-2026-9256.
Fixes have been made available by F5, and additional information on upgrade paths can be found in the official F5 advisory and on the NGINX downloads page.
Fixes for the later reported CVE-2026-9256 were detailed in the corresponding advisory.
05/26/26 Update: The additional vulnerability (CVE-2026-9256) reported on May 22nd is in the same ‘ngx_http_rewrite_module’ package and is very similar in context. Like CVE-2026-42945, it is a bug in the Perl-Compatible Regular Expression engine that can cause a heap overflow leading to RCE if Address Space Layout Randomization is disabled or bypassed.
The flaw is a heap buffer overflow in NGINX’s internal scripts engine, which processes the ‘rewrite’, ‘if’ and ‘set’ directives. According to researchers at depthfirst who discovered and reported the vulnerability, the engine uses a two-pass procedure to handle rewrite logic, the first pass calculates the required destination buffer size, and the second pass copies the rewritten data into the allocated buffer.
The potential RCE attack path is driven by a state mismatch between these two passes. When a ‘rewrite’ replacement contains a question mark, an internal ‘is_args’ flag is set on the main script engine, but the length-calculation pass runs against a zeroed sub-engine where the flag is unset. The result is that the copy pass, which performs URI escaping that can expand each escapable byte from one to three bytes, writes substantially more data into the buffer than was allocated. Because the overflowing bytes are attacker-controlled, overflow bytes can be carefully crafted to potentially lead to RCE.
At the time of writing, there is no evidence of RCE exploitation in the wild, and F5’s advisory notes that reliable code execution requires that the target system has Address Space Layout Randomizations (ASLR) disabled. This configuration is uncommon on modern general purpose Linux distributions but more plausible on embedded devices, appliances, and legacy systems. A lesser complexity DoS attack path exists regardless of ASLR status, whereby a single crafted request reliably crashes a NGINX workers process, and repeated requests can force a crash loop that degrades availability for every site served by the instance.
NGINX is one of the most widely deployed web servers and reverse proxies on the internet, and the vulnerable rewrite pattern is common in the real-world configuration including API gateway, PHP front controllers, and WordPress permalink handling.
While full exploitation leading to RCE is more complex, the widespread use of NGINX widens the attack surface and makes the lower-effort denial of service attack a valid target for opportunistic threat actors. Beazley Security recommends patching to a fixed version of NGINX to remediate the vulnerability and reduce risk of service disruption.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On May 12th, Fortinet publicly released a critical vulnerability affecting Fortinet FortiAuthenticator which handles Identity and Access Management (IAM) within some Fortinet architectures. The flaw is tracked as CVE-2026-44277 and classified as an improper access control vulnerability allowing unauthenticated attackers the ability to execute unauthorized code remotely.
Fortinet has released patched versions of software to address the issue, and at the time of writing no publicly confirmed proof-of-concept (PoC) exploits have been released. Given prior targeting of Fortinet products and affected identity components, Beazley Security recommends organizations apply patches as soon as possible.
Product | Affected Version | Fixed Version |
FortiAuthenticator 6.5 | 6.5.0 through 6.5.6 | 6.5.7 |
FortiAuthenticator 6.6 | 6.6.0 through 6.6.8 | 6.6.9 |
FortiAuthenticator 8.0 | 8.0.0 and 8.0.2 | 8.0.3 |
*According to the FortiGuard advisory, FortiAuthenticator Cloud is not affected by this vulnerability.
Patches have been released by the vendor and applying them is the recommended course of action. In the event patches cannot be immediately applied, the following mitigations may help to reduce risk:
Review and restrict network-level access to FortiAuthenticator interfaces and API endpoints to trusted networks only.
Evaluate migration to FortiAuthenticator Cloud if on-premises patching cannot be performed.
Fortinet has released a firmware upgrade for FortiAuthenticator to fix these issues. Registered users can grab the latest updates from the official FortiCloud website.
Fortinet provided limited technical details regarding the vulnerability in its initial advisory publication. The official PSIRT statement mentions that the flaw was internally discovered as part of a Fortinet audit and is classified as an Improper access control vulnerability on API endpoints. There are no reports of active exploitation or proof-of-concept (PoC) code at the time of writing.
FortiAuthenticator is a Fortinet Identity and Access Management (IAM) solutions designed to centralize authentication services and enforce identity-based security controls such as MFA across enterprise environments. The platform is commonly integrated with VPN infrastructure, administrative access, and other identity services.
Because FortiAuthenticator often serves as a core authentication component within organizations leveraging Fortinet, successful compromise could create substantial downstream risk to connected systems and user accounts. Given the history of threat actors targeting Fortinet systems, Beazley Security recommends affected organizations patch FortiAuthenticator deployments as soon as possible.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On May 11th between 19:20 and 19:26 UTC, an attacker published 42 malicious TanStack npm packages with multiple malicious versions per package. An aggregate download count of all the packages affected reaches in the tens of millions, increasing the severity of the attack substantially. These malicious package versions targeted Continuous Integration Continuous Delivery (CI/CD) systems to steal build and production environment credentials across multiple services and continue to publish additional malicious packages. Malicious payloads from this attack targeted credentials from AWS, GCP, Kubernetes, Vault, Github, npm, pip, SSH, commercial VPN configurations, messaging applications, and cryptocurrency wallets. At the time of writing, at least three other libraries were affected by similar malware, including Python pip and PHP Composer packages.
The initial malicious libraries published by TanStack to npm were identified as malware within the hour by Ashish Kurmi, an external researcher for StepSecurity. Tanstack removed and purged their Github cache entries within two hours of the initial compromise.
This malicious behavior mirrors many patterns within the recent Shai-Hulud attacks and is attributed to TeamPCP. The attack exacerbates the trend of the group targeting victim CI/CD dependencies to hit developers. This attack specifically targets the Github OpenID Connect (OIDC) federation mechanism, which mints a new valid npm publish token on the compromised CI identity. This ensures affected packages have a “verified provenance” badge in npm, commonly used to delineate rouge package deployments, and ensures that a CI/CD publish step does not need to complete for the worm to propagate.
Organizations that are affected should immediately audit installed packages to confirm whether any of the affected libraries were installed. If so, treat the machine as compromised and follow the Mitigations and Workarounds below.
Beazley Security will continue to monitor developments related to propagation of this worm as technical details emerge. An initial list of impacted packages is included in the Appendix of this advisory and is also being tracked by researchers at socket.dev.
If you believe that a machine has already been impacted, assume all secrets that are accessible on the affected host are compromised. We do not advise cleaning in place and instead recommend reimaging or rebuilding affected machines from known good images.
Any credentials related to AWS, GCP, Kubernetes, Vault, Github, NPM, Pip, or SSH on a host with an affected version should be rotated immediately. Any keys that match the following regex should be considered compromised and exfiled:
/npm_[A-Za-z0-9]{36,}/g
/gh[op]_[A-Za-z0-9]{36}/g
/hvs\.[A-Za-z0-9_-]{24,}/g
/eyJhbGciOiJSUzI1NiIsImtpZCI6[\w\-.]+/g
/AKIA[0-9A-Z]{16}/g
The following hard-coded paths for files are enumerated by the payload and any instances of these credentials are assumed to be compromised as well. These paths include credentials more commonly found on developer machines rather than purely CI/CD pipelines:
~/.azure/accessTokens.json
~/.config/gcloud/*
~/.kube/config
/var/run/secrets/kubernetes.io/serviceaccount/token
~/.terraform.d/credentials.tfrc.json
/etc/rancher/k3s/k3s.yaml
/var/lib/docker/containers/*/config.v2.json
~/.bash_history
~/.zsh_history
~/.python_history
~/.mysql_history
~/.ssh/id_rsa
~/.ssh/id_ed25519
~/.ssh/id_ecdsa
~/.git-credentials
~/.gitconfig
.vscode/tasks.json
.vscode/setup.mjs
~/.npmrc
~/.pypirc
~/.docker/config.json
~/.netrc
~/.yarnrc
~/.claude.json
~/.claude/mcp.json
~/.kiro/settings/mcp.json
~/.bitcoin/wallet.dat
~/.ethereum/keystore/*
~/.monero/*
~/.zcash/wallet.dat
~/.config/Signal/*
~/.config/Slack/Cookies,
~/.config/discord/*
~/.config/telegram-desktop/*
It’s been identified by Github user @carlini that revocation of Github tokens will trigger a wipe of the home directory of the current user via rm -rf ~/. This affects developer machines much more than CI/CD pipelines.
For endpoints and developer machines, ensure that the affected packaged are not installed on the host:
find / \( -name "package-lock.json" -o -name "pnpm-lock.yaml" -o -name "yarn.lock" \) -exec sh -c ' grep -E "@agentwork-cli|@beproduc|@cap-j|@dirigible-a|@draftaut|@draftla|@mesade|@mistrala|@ml-toolkit-t|@opensearch-projec|@squaw|@supersurkhe|@tallyu|@tanstac|@taskflow-cor|@tolk|@uipath|" "$1" | grep "node_modules" && echo " ^^ found in: $1" ' _ {} \; 2>/dev/null
Ensure that the payload is not installed on any suspected hosts:
find / ((-name "package-lock.json" -o -name "pnpm-lock.yaml" -o -name "yarn.lock") -o ( -path "/node_modules//router_init.js" -type f )) 2>/dev/null find / -path "*/node_modules/*/package.json" -type f -exec grep -l "@tanstack/setup" {} \; 2>/dev/null
Additionally, persistence mechanisms appear in Linux and macOS under the name gh-token-monitor within systemd and launchctl respectively. Using pinned versions of libraries is recommended to prevent this kind of attack if new malicious versions are released for any library.
Using pinned versions of libraries is recommended to help mitigate these attacks in the future. NPM specifically offers a configuration, npm config set min-release-age 3, that will enforce a 48-72 hour period on new package releases before installing them on your machine. This is advised for all developers using external npm packages. For machines running without human interaction, such as CI/CD pipelines, we advise not only version pinning of packages but disabling scripts on installs with the –ignore-scripts argument wherever possible. Python’s and PHP’s package managers don’t advise globally updating all packages regularly and therefore are less likely to be unpinned and installed each CI/CD invocation, so no such mechanism exists within the respective package managers.
While not strictly a patch, ensuring that any installed affected npm, pip, and conductor packages are removed and purged from your machines is recommended. This involves removing the affected packages and installing pinned versions of the unaffected packages.
Network Activity |
|---|
api[.]masscan[.]cloud |
filev2[.]getsession[.]org |
git-tanstack[.]com |
seed1[.]getsession[.]org |
filev2[.]getsession[.]org/file/ |
File Name | Hash |
|---|---|
router_init.js OR router_runtime.js | 12ed9a3c1f73617aefdb740480695c04405d7b4b |
router_init.js (sha256) |
|
tanstack_runner.js OR router_init.js | e7d582b98ca80690883175470e96f703ef6dc497 |
Beazley Security is conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On May 6th, Palo Alto Networks released an advisory for an authentication bypass vulnerability in their PAN-OS software related to their Captive Portal “User-ID™ Authentication Portal”. The vulnerability (CVE-2026-0300) allows an unauthenticated attacker to bypass authentication and remotely execute code as root on PAN-OS PA-Series and VM-Series firewalls. Palo Alto Networks has identified attacks against their systems in the wild, and at the time of writing has not released a patch for the affected systems.
Beazley Security and Palo Alto Networks advise either disabling or limiting access to the Captive Portal to trusted internal IP addresses as per their security guidelines updated on May 5th 2026.
This vulnerability was found on PAN-OS User-ID™ Authentication Portal web interfaces, affecting specific versions of the PAN-OS software. Palo Alto Networks has included estimated release dates for the patch releases for specific versions included in this table. Please reference the table below for additional details.
Product | Affected Version | Fixed Version |
|---|---|---|
PAN-OS 12.1 | < 12.1.4-h5 < 12.1.7 | >= 12.1.4-h5 (ETA: 05/13) >= 12.1.7 (ETA: 05/28) |
PAN-OS 11.2 | < 11.2.4-h17 < 11.2.7-h13 < 11.2.10-h6 < 11.2.12 | >= 11.2.4-h17 (ETA: 05/28) >= 11.2.7-h13 (ETA: 05/13) >= 11.2.10-h6 (ETA: 05/13) >= 11.2.12 (ETA: 05/28) |
PAN-OS 11.1 | < 11.1.4-h33 < 11.1.6-h32 < 11.1.7-h6 < 11.1.10-h25 < 11.1.13-h5 < 11.1.15 | >= 11.1.4-h33 (ETA: 05/13) >= 11.1.6-h32 (ETA: 05/13) >= 11.1.7-h6 (ETA: 05/28) >= 11.1.10-h25 (ETA: 05/13) >= 11.1.13-h5 (ETA: 05/13) >= 11.1.15 (ETA: 05/28) |
PAN-OS 10.2 | < 10.2.7-h34 < 10.2.10-h36 < 10.2.13-h21 < 10.2.16-h7 < 10.2.18-h6 | >= 10.2.7-h34 (ETA: 05/28) >= 10.2.10-h36 (ETA: 05/13) >= 10.2.13-h21 (ETA: 05/28) >= 10.2.16-h7 (ETA: 05/28) >= 10.2.18-h6 (ETA: 05/13) |
Prisma Access | None | All |
The highest risk exposure exists when the User-ID Authentication Portal is enabled and reachable from the public internet. Palo Alto advises that users running affected versions of PAN-OS either:
Restrict access to the Captive Portal to trusted zones, referencing their Captive Portal knowledge base article and their Live Community Article.
Disable the Captive Portal entirely if not required
Palo Alto networks released a threat prevention signature to help detect attacks. Administrators should ensure that threat prevention is enabled to help reduce risk.
At the time of writing, no patches exist for the vulnerable PAN-OS instances. We will update this advisory with updates as they are released.
Considering this vulnerability provides root access to a networking system which would provide logs indicating compromise; we can’t provide IoCs for users to determine if their system was previously attacked and compromised.
While details on the vulnerability are sparse, Palo Alto has indicated in their report that the attack involves a buffer overflow and out of bounds write. CVE-2026-0300 is a flaw that exists within Palo’s User-ID Authentication Portal, also referred to as the Captive Portal service.
Palo Alto has confirmed that the vulnerability is being actively exploited in the wild, however at the time of writing no attribution to a specific threat actor or campaign has been publicly released.
The flaw is pre-authentication and reachable by attackers from the network if the Captive Portal is enabled. The highest risk scenario exists if the portal is exposed directly to the internet. When access to the portal is restricted to internal zones, the attack vector narrows to adversaries that must be present on those network segments.
The published advisory from Palo Alto Networks states that successful exploitation of this vulnerability grants the attacker root access on the host. This implies that successful attacks could be used to modify the host to allow attacker control in the future, outside of existing PAN-OS features, including the deletion of logs that would be used to identify a breach took place.
Given active exploitation in the wild, Beazley Security strongly recommends either disabling the Captive Portal if not required, or restricting access to only trusted networks until patches are made available by Palo Alto.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On May 4th, 2026 Apache released an advisory regarding a flaw that under certain conditions, could allow unauthenticated remote code execution (RCE) in Apache HTTP Server version 2.4.66. Tracked as CVE-2026-23918, the vulnerability stems from a memory corruption bug within the version’s implementation.
Beyond potential for remote code execution, the flaw can also be exploited to cause a DoS condition and is considered weaponizable due to its lower complexity to exploit.
Due to the widespread usage of Apache HTTP server and the lower-effort denial of service attack vector, the vulnerability could become targeted by opportunistic threat actors. Beazley Security recommends patching to a fixed version (2.4.67) of Apache HTTP Server reduce risk of service disruption or future exploitation.
Product | Affected Version | Fixed Version |
Apache HTTP Server | 2.4.66 | 2.4.67 |
If upgrading Apache HTTP Server to version 2.4.67 is not immediately an option, the following temporary mitigations might help to reduce risk:
Temporarily disable HTTP/2 by removing it from Apache configurations, which could impact performance of the server.
Place Apache HTTP Servers behind a Web Application Firewall (WAF) to block malicious HTTP/2 requests and perform rate limiting to limit DoS potential.
Fixes have been made available by Apache and additional information on upgrade paths can be found here.
Limited technical details have been publicly released by Apache on the vulnerability, however the flaw is classified as a double-free vulnerability within Apache HTTP Server’s mod_http2 module. According to researchers that reported the vulnerability, the flaw exists specifically in part of the multiplexer component (h2_mplx.c) code.
The potential RCE attack path is driven by a race condition, where an attacker attempts to make the server process two related events on the same connection before the initial web request is fully completed. This timing issue can lead to memory being freed and then reused by the server in an unsafe way. If an attacker can control what data is placed into memory when reused, the server may execute arbitrary commands within. While technically possible, the attack is more difficult to perform reliably.
At the time of writing, there is no evidence of RCE exploitation in the wild and the RCE is complex to perform consistently in practice. Because of the same timing issue, a lesser complexity DoS attack path exists and repeatedly triggering the condition could force an affected server to crash or become unresponsive disrupting hosting services.
In many deployments, mod_http2 is built in and enabled by default. While full exploitation leading to remote code execution is theoretically more complex, the widespread use of Apache HTTP Server on the internet widens attack surface and makes a lower-effort denial of service attack a valid target for opportunistic threat actors. Beazley Security recommends patching to a fixed version (2.4.67) of Apache HTTP Server to remediate the vulnerability and reduce risk of service disruption or future exploitation.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.